Possible Bug with XNET CAN signals in MuxID = 0 subframe

[bodypillow]

Hi All,

I'm working on an application with a 9862 card in which I'm reading and writing multiplexed CAN traffic to the bus.  I use a number of tactics to enhance the XNET's stock functionality with multiplexed signals, for example:

When performing a single point signal read of a multiplexed message, the system will not wait for a frame with correct mux ID to come in, it will just read whatever subframe happens to come in, and if it was not the right subframe for that signal it will return the default value.  Fixable enough, I can set the default value of all of my signals to something absurd and make my wrapper read VI wait until the read isn't that default one anymore.  It works swimmingly generally and I use it all the time.

However, this technique is not enough for what appears to be an actual bug I've just noticed.  When there is absolutely no traffic on the CAN bus (all devices literally unplugged), the deep insides of the XNET drivers will actually return a value for all signals in subframe with muxID = 0 which are NOT the default value for those signals, it is just the maximum possible value of that signal (all F's in binary).  Interestingly it also seems to do this for non-multiplexed signals?

How and why it does this I have no idea. With all of the rest of the contents of an actual CAN frame, including the SOF, message ID (which is not all 0's or F's in my application), data length code, data field, CRC, yada yada yada, there is no way that it is correct for the card read actual signals from a blank bus.

The workaround of waiting for non-all F-values for those signals is not suitable for me because those can be valid values of the signals I'm looking at.

Anyone have any ideas or reasons as to why I'm wrong about this?

[Hooovahh]

Yeah there are several things I don't agree with in XNet and Muxing issues is definitely one of them.  In my opinion a value shouldn't be default if it can't be read but instead NaN (not a number), but some might argue about the default value in the database.  Anyway I created my own conversion library here, which works with Mux signals a little differently.  I think NI should address this, but until then you can try my conversion library and see if it is able to take the raw frames and turn them into the signals you are looking for.

[bodypillow]

Yeah the default thing kind of makes sense, but that is an easy problem to get around.  Set all signals to have default of value, then repeat the signal single-point read until it gets something different.

Except that on Mux0, it does get something different from the very first instance, even when there is literally nothing plugged into the CAN bus! It gets a value of all F's, regardless of what the default value is! It's like some other internal default that I don't have a way of setting.  Only affects mux0 signals (and non-multiplexed signals).

I don't believe this specific issue with the mux0 signals occurs when you use the frame style but I have yet to try it.  Will try and report back.. but that doesn't make me feel better.  I don't want to use the Frame API every time.

[bodypillow]

This is still not really sitting well with me.  Can someone from NI chip in an explain why, with absolutely 0 bus traffic, the read signal single point returns a non-default value for signals in mux0 (and non-muxed) only? This really doesn't make sense to me.

[JefeL]

If you can post a unit test/reproducing example it would be extremely helpful. I will look into it with or without one but having a verified reproducing example makes sure we are on the same page from the start.

[JefeL]

Here is a quick unit test I put together to try and reproduce the issue. I do not see any unexpected values with this test VI and database. Can you help me to understand how my test VI differs from your reproducing case and/or post an example that reproduces it?

[bodypillow]

Hi Jeff,

Thanks for your followup.  I've slightly modified your supplied VI to demonstrate the behavior I'm talking about.  Please find the modified VI and some screenshotted results from my tests here attached.  The cliff's notes is that the mux 1 and 2 signals always give the expected result and the mux0 signal does only for a certain constrained set of possible default values.  Hopefully you can replicate my results.

Thanks,

[JefeL · Accepted solution]

I can reproduce the issue and have added it to our known issues list (703591).

Mode zero appears to truncate the value to the maximum allowed by the bit width of the signal, i.e. 65535 for a 16 bit integer signal, while the other modes do not. It isn't clear which behavior is the expected value but the devs will iron that out.

[bodypillow]

Excellent, thank you. Yes I think you're right; I definitely hope the behavior of the non-mux0 signals (i.e. allowing default to be anything in double float range) is the correct one because it allows much more flexibility, and seems to work fine for those signals.

So this could theoretically be fixed in a point release of XNET drivers?

Also, should I click your post as "accept solution" since it is now added to the known issues tracker?  Or should I wait until (hopefully) a followup post where the behavior is actually fixed?

[JefeL]

Unfortunately I cannot predict or disclose if/when the issue will get fixed. When it does get fixed, the number I provided should show up in the XNET readme for the release it is fixed in. You can accept the known issue as a solution for now since other users who find the issue have a way to determine if it has been resolved etc.