LabVIEW
How to use NI CAN feature for extracting DBC information without a CAN Interface?
Solved!
Are you using a Series 2 CAN card? Or are you using an XNET device using the old CAN drivers? If you are using XNET hardware please use the XNET drivers. They are newer and better and do a whole bunch of cool stuff. One sign that you should use the new drivers is the article you linked to is almost 5 years old.
Okay with that out of the way, if you are using a Series 2 CAN card then you can't use XNET and you are moving down the right path. If you don't have the hardware, just use one of the two virtual CAN ports, CAN 256, or 257. The driver routes one to the other so you can write on one, and you should see the same values read back on the other. But for you it doesn't matter because all you are trying to do is read the DBC.
@Nelval wrote:
It seems that no matter the virtual port I am using, it does not work. Could you have a look at my sample.vi, I know it's poorly wired, especially since I'm more in .NET things than NI from my occupation ^^'. I also provided a dummy DBC file to simulate a very basic input.
And by the way is there any way then to get the Byte Array / Bit Array corresponding to a certain message (and how to set the signal values required to get the message)?
Your code isn't that bad, relativly easy to follow. In any case the problem had nothing to do with the CAN port being used. If you would probe the error wires around you would see that coming out of the CAN Init Start stated that the channel name didn't exist. Looking at how you had it wired you took the messages (or frames) and put them into the channels terminal, when I assume you wanted the channels. Then looking at your tree you were again trying to get the ID of a channel, but giving it the message name. I also added reading the Start Bit, Number of Bits, and Byte Order for all the channels read.
If you were to do this with XNET there would be completelly different functions, but the same operations can be done.
Hi Nelval,
If you try to open any dbc or ncd files,baically they are just xml files which have fields,sections,sub sections and items.You can use xml functions to parse them and extract the data without even using any of the CAN pallette functions.
Regards,
SrikrishnaNF
@srikrishnaNF wrote:
Hi Nelval,
If you try to open any dbc or ncd files,baically they are just xml files which have fields,sections,sub sections and items.You can use xml functions to parse them and extract the data without even using any of the CAN pallette functions.
Yeah you could reinvent the wheel, but these functions already exist for parsing DBC data.
I believe the information I posted answers your question. The Bit start and Bit Length will tell you which bits of a frame make up a signal. This with scaling, and byte order information tells you how to go from frame bits to signals.
But why are you needing to know this information? The purpose of a DBC is to obstract this information so you don't need to worry about it. Just give it a DBC and say write RPM to be 2000 and it handles the frame that needs to go out. You should not be doing this conversion yourself.
Okay you are close, just know that what you want to do can only be done with XNET not the normal series 2 CAN stuff.
Let me first explain why you got the error. You said give me all the signals within a frame and make a session with it for conversion, then you said read all frames on the CAN bus. You can't use a conversion session to read an interface.
What you want is to replace the XNET Read function with the XNet Convert function under the Advanced palette. It is a polymorphic VI and you will want to change it from Signal to Frame CAN. Then give it an array of doubles, where each value corresponds to each signal you made a session for. So if your particular frame has 3 signals you'll want to provide an array with three values. Then the output of the XNET Convert will be the an array of frames, but in your case it should only have one frame in it, because all signals you are converting are in the same frame. If you are doing crazy looping like this then ensure that you are closing interfaces before opening new ones.
