Kvaser CAN read labview example

[charis21]

HI,

I am using the kvCanStartExample.vi for reading and transmitting CAN messages throuhg kvaser USBcanii. I noticed that the value of the received messages don't update their value instantaneuously but you need to wait for aproximately 20 seconds in order to get the new values. Let's say I change the voltage of the motor from 14 V to 10V. Then 14V still exists in my CAN receiving packages for almost 20 seconds after the change is done.

Is there any way to minimise this delay?  Any ideas?

Attached is the kvCanStartExample 

Regards

Charis

[nyc_(is_out_of_here)]

---

@charis21 wrote:

HI,

I am using the kvCanStartExample.vi for reading and transmitting CAN messages throuhg kvaser USBcanii. I noticed that the value of the received messages don't update their value instantaneuously but you need to wait for aproximately 20 seconds in order to get the new values. Let's say I change the voltage of the motor from 14 V to 10V. Then 14V still exists in my CAN receiving packages for almost 20 seconds after the change is done.

Is there any way to minimise this delay?  Any ideas?

Attached is the kvCanStartExample 

Regards

Charis

---

It is the vendor's product and VI, go ask THEM.

[Hooovahh]

Sounds like some kind of buffer being filled and then taking longer to process the buffer then it does to fill it up.  As nyc said, this is neither NI software or hardware.  You are welcome to ask these questions here, but you will get more support from the vendor.

Still if you are interested in some NI hardware they have a couple CAN devices, some cheap some not so cheap with various features.

[Sam_Sharp]

We use the Kvaser devices (Leaf SemiPro HS) pretty heavily and I can say that they work fine - even for high throughput CAN traffic. I believe we had to slightly modify the LabVIEW drivers provided by Kvaser (mostly for error handling, that sort of thing) but we use them in lots of applications and don't have any issues with them so I'd suspect that the issue is due to something in your application/configuration.

I can't open your VI as I don't have LV2014 - if you save it to 2013 I can have a look.

[charis21]

Thanks for your help.

attached is the vi for labview 2013

I think there is an issue with the buffer because when I press the "Go Bus On" button off and then again on the values are updated instantaneuously. However I can't understand why.

If you have also a different example for reading CAN messages with this kid it should be helpful!

thanks again for your help

[Sam_Sharp]

Are the values always 20s out of date or do they start off being up-to-date and get further behind as it runs? I've run the VI with a virtual Kvaser port and simulated data from Kvaser CanKing (really useful program for generating CAN traffic and verifying CAN transmission if you're not using it) and I'm not getting any delays. I suggest you try playing with CanKing and a virtual port to help you find the cause of the problem - it rules out any hardware problems and can help you see what's going on.

What sort of CAN traffic/throughput do you have - how much data is on the CAN bus, how often does the motor send its CAN data etc?

You say you notice a delay in going from 10V to 14V...are you post-processing the CAN frames?

[yuri0801]

Hi,

Have you solved your problem? I met the same problem as you. Can you solve it now?

[rainfallmax]

I have also encountered this problem recently.

This is the official answer to me.

support@kvaser.com

1. You should not split the handle returned by the kvCanOpenChannel.vi. The handle returned by kvCanOpenChannel.vi is not thread safe. When you split a wire in LabView, you are telling LabView that it is ok to execute steps on either branch simultaneously (in separate threads). This can lead to strange behavior when performed on the returned handle.

2. In your read loop, a better design in modern LabView is to use the kvCanReadWait.vi and to not associate a Wait For Next ms Delay with the while loop. The kvCanReadWait.vi works the same as the kvCanRead.vi except it has one additional input called timeout. This function will return immediately if there is a message in the receive buffer. If the buffer is empty, the function will wait up to the timeout value before returning but returning immediately if a message is received during the timeout. This allows your read logic to be more event driven instead of polled.

[Al-amin]

Hello,

I am working on a similar project to read CAN bus messages. I got my messages successfully in hexadecimal but the challenge now is converting those messages to the engineering unit (human-readable form). I am preparing my *dbc file from kvaser database editor 3. I need a LabVIEW program that would solve that. Thank you

Aminu Babangida

[Hooovahh]

---

@Al-amin wrote:

Hello,

I got my messages successfully in hexadecimal but the challenge now is converting those messages to the engineering unit (human-readable form).

---

I created a Frame Signal Conversion tool that leverages NI-XNet for the DBC parsing, and then pure G to do the conversion.  XNet also can do this on its own but I've had some performance, and features that I'd consider bugs.  Part 5 of my CAN blog talks about the signal and frame conversion library, but the code posted on NI's forums is actually newer.