Possible XNET Conversion MUX Bug

[Hooovahh]

Okay I don't know if this is an intended feature, but I'm not a fan of it if it is.  Lets say I have a conversion session in XNet.  My session is converting muxed CAN signals.  So I have signals, I need them to become frames.  If I perform a conversion on one signal, giving the Multiplexer the value for one, then perform another conversion after it with the Multiplexer of the other value, then the other bytes will be kept from the previous conversion.

This is very hard to explain in words so let me try again (also code is attached so feel free to ignore this)

If I convert a signal "Speed" with a value of 10 (0xA), then convert a second signal of "Command" with a value of 1, my second conversion will result in 0xB instead of 1 because 0xA is 0b1010 and replacing the first bit with a 1 results in 0b01011.  I would want the result to be simply 1, not what ever my previous conversion was, with bits being replaced.

There is a workaround and it is in my VI.  If I perform a conversion after each conversion, setting all bits to 0 it works as expected.  I could also perform a bit mask on the output and replace all bits with 0 if they aren't part of the payload.  I don't like this because I will be dealing with lots of signals, and I would have to figure out with each frame, what bits should be cleared.

[Munna232]

Small observation,

1. If cmd Signal value is 0 then second conversion value is also A. Because there is no replacement in Bit.

2.Suppose, If Cmd signal length is 2bits then conversion will replace 2 bits? Example,

1. 1^st conversion frame is 0XA (1010) next Signal value 3 (11) then result will be 13 (1101)?

[Hooovahh]

I wouldn't expect a previous converted frame, to affect the next.  But even if previous conversions should affect the concurent conversions, I would argue that these two signals are of different multiplexers and shouldn't interact with eachother.

[Hooovahh]

Hey NI so a year and a half later I'm seeing an issue with frame conversion that I suspect is due to a separate conversion session.  I'm still investigating and trying to isolate it but it is part of a larger application.  Even so I suspect my error in conversion that I'm having today, could be related to a bug in conversion that I posted here.  Any update?  Any CAR?

[elcalverado]

Hooovahh,

I've definitely replicated the behavior you are seeing. I'm in the process of verifying if it is expected behavior or not. I'll let you know what I find!

[elcalverado]

The key to this issue is in the manual on page 4-45: Conversion Mode.

http://www.ni.com/pdf/manuals/372840k.pdf

Conversion sessions work similar to Single Point mode. That means that a frame object is over written when a new conversion takes place. When we first perform the speed conversion, any value that we do not explicitly have an input for is assigned the default value:

Notice that we ignore the command signal because this frame is multiplexed and we only care about the mode value that contains the speed signal.

Now that values have been assigned to all bits, the frame will no longer update with default values but instead overwrite the old values with the new values. So when we write the command frame:

We see that the conversion only updates the mode value and ignores the speed signal. The remaining bits of byte 6 already have values so they do not reset to the default values but retain the old. The cmd signal, which in this case equals bit 0 of the 6th byte is the only one that is changed:

All other bits in the signal remain unchanged.

[Hooovahh]

---

@Hooovahh wrote:

I wouldn't expect a previous converted frame, to affect the next.  

---

Thanks, it still sounds like a bug.  One conversion should not affect the next, I now understand why it is this way, but it should not be.