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