Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

XNET CAN Multiplexer Default Value Doesn't Work

Solved!
Go to solution

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.

 

 

 

 

0 Kudos
Message 1 of 8
(4,863 Views)

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.

Jeff L
National Instruments
0 Kudos
Message 2 of 8
(4,841 Views)

@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).

 

 

 

 

0 Kudos
Message 3 of 8
(4,825 Views)

@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).

0 Kudos
Message 4 of 8
(4,831 Views)
Solution
Accepted by topic author NathanJD

I'm reproducing the issues as described so I will file a bug report to get them fixed.

Jeff L
National Instruments
0 Kudos
Message 5 of 8
(4,792 Views)

Hello, Sir.

 

I also meet same problem.

I am using a USB-8502 with XNET driver.