CAN Multiplexer 32b

[petrz]

Hello,

Is there support for 32b multiplexer in the XNET? We have a tester that was using that size of the multiplexer, but after upgrade of the XNET driver (from 19.6 to 23) it doesn't work.
In the new XNET DB editor it shows error:
NI-XNET: (Hex 0x3FF63133) The multiplexer size exceeds 16 bits. This is not supported for Single Point sessions.

In classic editor it shows:
The multiplexer signal is too big. Currently no more than 16 bit wide signals are supported.

I don't know how/why it worked in older version, was the support removed? Or fixed some issue?

The LabVIEW code throws following error:

NI-XNET: (Hex 0xBFF63001) An internal error occurred in the NI-XNET driver. Solution: Contact National Instruments and provide the log files found in %LOCALAPPDATA%\National Instruments\NI-XNET\log. Note that this location might be hidden on your computer. For LabVIEW RT systems, log files are located in /ni-rt/nixnet/log or /var/lib/ni-xnet/log.

Any input appreciated, thanks.

[Hooovahh]

That does sound weird. But then again XNet has tweaked features in the past where things were working, to then no longer be working for seemingly no reason.  I'd love to hear from NI on this, not that I need this feature personally.  There might be ways to do this yourself, by doing the frame signal conversion library.  I have a set of tools to do this, but it relies on the XNet database for the Mux signals, and so it wouldn't work right away for you.  It would have to have custom code to specify signals as the muxing one, and then XNet might not allow you to have signals that over lap, and then that just is a whole snowball of additional work.

[petrz]

After more poking around I found that the MUX signals are part of the sessions (conversion and frame SP out), but never actually read/write via these sessions. Digging deeper in to old code, I've even found workaround code for sending of these frames. Looks like it builds the mux frame "manually" in way as the @Hooovahh described.

My conclusion is that the 32b MUX never worked in the XNET, but NI fixed/added some frame check which will not allow to use these signals in the session. After removing the MUX frame frame and signal from the session, everything seem to be working.

However it would be nice if the next version of the XNET included the 32b MUXes. Lets add it to never ending list of TODOs or let the source code be open:D:D

[rbenji23]

I have been requesting NI to implement this 32bit mode support in NI-XNET for over 10 years and they have yet to do it... so I doubt they ever will listen. We have instead started to use raw frame sessions and parse the frames using our own signal parsing libraries instead of using XNET. It also helps get away from the annoyingly unhelpful XNET error descriptions.

[Hooovahh]

---

@rbenji23 wrote:

We have instead started to use raw frame sessions and parse the frames using our own signal parsing libraries instead of using XNET. It also helps get away from the annoyingly unhelpful XNET error descriptions.

---

This sounds really useful. Is this posted online somewhere?  I am a big fan of XNet and all the things it does well.  There certainly are edge cases that make using it difficult, with various work arounds needed.  But an open source alternative would be welcome for sure.

[rbenji23]

XNET is a very powerful tool but too rigid in my opinion to fit with manufacturer specific CAN implementations. Unfortunately XNET is closed source so modifications are not possible for these manufacturer implementations.

I can't share our internal signal parsing libraries. But I can share this library which can be modified to support 32bit modes pretty easily and made to drop in place of the XNET convert function. It also has DBC parsing capabilities.
https://forums.ni.com/t5/Example-Code/Advanced-CAN-Frame-to-Channel-Conversion-Reference-Example/ta-...

[Hooovahh]

---

@rbenji23 wrote:

I can't share our internal signal parsing libraries. But I can share this library which can be modified to support 32bit modes pretty easily and made to drop in place of the XNET convert function. It also has DBC parsing capabilities.
https://forums.ni.com/t5/Example-Code/Advanced-CAN-Frame-to-Channel-Conversion-Reference-Example/ta-...

---

Wow this is pretty bonkers.  Parsing the DBC into the raw data is the heavy lifting XNet handles for me.  Being able to write this in pure G would be very handy. Also being able to just put the raw DBC file on an RT system and have it be imported and used, instead of having to rely on importing it from the host, then deploying it would be helpful. I asked for more RT support of XNet features on the Idea Exchange. I'm not sure if I'll ever get around to wrapping this code into a cleaned up class. But my Frame Signal conversion library could benefit from it for sure.  As it is there are already things that library has to do to get around XNets implementation. The scaling itself on that library is in G, and it really just is the scaling information that it uses XNet for.