02-22-2018 11:25 AM
Using XNET database editor 17.5.1 (and a few earlier versions that I've tested), the default value for a multiplexer does not save and always goes back to zero.
I originally experienced this in XNET 16.0 and I attempted to mitigate it by fixing the default value in-memory using the XNET database API prior to creating my session. The default value (according to the property node) was being properly set by my code BUT when it got to actually transmitting, it was still using zero as the default. It wouldn't change until I performed an XNET Write.
Solved! Go to Solution.
02-22-2018 03:51 PM
Assuming a cyclic frame since the value updates after you call XNET Write. So the incorrect value is seen in between XNET start.vi and XNET Write.vi.
I would like to reproduce the issue on my end. There are two default value properties, one for signals and one for frames. Are you only changing the default signal value, the frame default, or both? Are you also using J1939 in this cluster as well? Is the frame larger than 8 bytes?
If it turns out to be incorrect behavior, one potential workaround would be to start the session in "session only" mode, setting auto start to false, and then call XNET write to update the values prior to starting the interface.
02-22-2018 05:33 PM - edited 02-22-2018 05:48 PM
@JefeL wrote:
Assuming a cyclic frame since the value updates after you call XNET Write. So the incorrect value is seen in between XNET start.vi and XNET Write.vi.
Correct.
@JefeL wrote:
one potential workaround would be to start the session in "session only" mode, setting auto start to false, and then call XNET write to update the values prior to starting the interface.
Yep, this is the workaround that I found last night when investigating this stuff.
@JefeL wrote:
I would like to reproduce the issue on my end. There are two default value properties, one for signals and one for frames. Are you only changing the default signal value, the frame default, or both? Are you also using J1939 in this cluster as well? Is the frame larger than 8 bytes?
In the XNET Database Editor, it is the Default Value for the signal configured as the Multiplexer (see attached image).
When doing it programmatically, I'm setting the Default Value for the signal (not the Default Payload for the frame which I believe only applies to unassigned bits in the frame). I've attached a snippet of my VI to "fix" all the multiplexer default values.
The cluster is configured for J1939 and all frames are configured using the J1939 PGN (though the saving of the default value for multiplexer doesn't work for a regular CAN cluster either).
02-22-2018 05:52 PM
@JefeL wrote:
Assuming a cyclic frame since the value updates after you call XNET Write. So the incorrect value is seen in between XNET start.vi and XNET Write.vi.
Correct.
@JefeL wrote:
one potential workaround would be to start the session in "session only" mode, setting auto start to false, and then call XNET write to update the values prior to starting the interface.
Yep, this is the workaround that I found last night when investigating this stuff.
@JefeL wrote:
I would like to reproduce the issue on my end. There are two default value properties, one for signals and one for frames. Are you only changing the default signal value, the frame default, or both? Are you also using J1939 in this cluster as well? Is the frame larger than 8 bytes?
In the XNET Database Editor, it is the Default Value for the signal configured as the Multiplexer (see attached image).
When doing it programmatically, I'm setting the Default Value for the signal (not the Default Payload for the frame which I believe only applies to unassigned bits in the frame). I've attached a snippet of my VI to "fix" all the multiplexer default values.
The cluster is configured for J1939 and all frames are configured using the J1939 PGN (though the saving of the default value for multiplexer doesn't work for a regular CAN cluster either). The frames that I was testing were configured for 8 bytes most of them didn't have all 8 bytes accounted for (meaning that the unassigned bytes would be 0xFF).
02-23-2018 02:16 PM
I'm reproducing the issues as described so I will file a bug report to get them fixed.
10-25-2018 09:05 PM
Hello, Sir.
I also meet same problem.
I am using a USB-8502 with XNET driver.