Hello Labview coimmunity,
I've been working on a project where we need to convert CAN frames using a DBC to-from signals. I've been using the conversion session examples provided with the XNET API but it does not seem to support multiplexed signals. When I feed CAN frames into the conversion session what I receive is ALL of the signals from the DBC file (which has over a hundred signals) with the value changed on the respective signals but without what ID or signal it belongs to.
My goal is ultimately to make a bus monitor similar to the XNET but have the ability to use that data in other parts of the software easily and consistently. I've looked at both the XNET manual as well as the forums and found some good places to start such as Hooovah's post here (thanks Hooovah!). The issues I am having is that I need more than just the values to be returned, I need information such as the ID and the signal short name and unit for each signal converted.
My question to all of you is whether the CAN frame to single point signal conversion has ever been modified in your use cases? I'm under the impression that the function is locked so I could not add this functionality but I may be wrong. Attached is the Convert CAN Frame to-from Signal example provided by NI.
I am using XNET API version 19.6 and labview 2018 SP1.
Solved! Go to Solution.
Hey there, so the NI conversion session should support Muxed signals. It has a few features I would call bugs, which was one of the motivations for improving it. The library of mine you linked to rewrites the signal to frames and frames to signals using pure LabVIEW. XNet was only used for parsing the DBC but the conversion was done in G and gives a better performance.
So what beyond converting to double are you looking for? If you are looking to read the units and displaying that, you can use the Database palette in XNet to read signal details such as units, comments and any thing else. My conversion library for instance needs to read things like the bit offset, and scaling information. You can make a subVI that calls my conversion library, and then reads the other detailed information like ID and Units, and then returns those as separate outputs.
After a bit of tinkering with your code I've managed to get everything working as I wanted. Similar to what you said, I pulled out the properties of the signals I wanted and included them in the conversion settings - makes retrieving the signal properties much cleaner when converting the frames.
The problem I have with using the XNET database palette is that it introduces quite a bit of overhead at run-time in order to match the signals. Also, similar to XNET conversion sessions, any frame that is not defined in the DBC will still be output as the default signal value (in your case NaN, in NI XNET conversion session 0.0). This makes converting the signals much harder by simply using the output of the frame to signal conversion. The trick is that any signal that is not received is NaN instead of the NI XNET default 0.0 . Quite a few signals can be normally zero so trying to match your signals using zero could lead to inconsistent results (at least from my trials).
Thanks to your code I was able to solve that problem since I could manipulate the conversion settings as noted above to include any and all information I wanted from the DBC defined signals.
You are totally right that there is overhead with querying the database stuff. That's why I suggest trying to perform a read of all the information you need at the start, and then try to use this information again later. This can be done with a Worm (write once read many) functional global variable, or a set of DVRs, using variant attributes or maps if you are in 2019 or newer, or a whole slew of technologies. I think you can see some of this in my conversion API where it reads things like the Muxing attributes and then keeps that information around for later conversion without having to read from the database again. Glad you got something that you think is usable.