XNET CAN Multiplexer Default Value Doesn't Work

[NathanJD]

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.

[JefeL]

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.

[NathanJD]

---

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

[NathanJD]

---

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

[JefeL · Accepted solution]

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

[oukai]

Hello, Sir.

I also meet same problem.

I am using a USB-8502 with XNET driver.

[NathanJD]

Hey Jeff, I don't see this issue being listed for 18.0 or 18.5 and it does not appear to be fixed in 18.5.

[JefeL]

Hi Nathan,

This issue didn't make the cut for 18.5 since the underlying problem is more complicated than saving the value in the DB editor. 

In a nutshell, the DBC file format handles default mode values differently than FIBEX / AUTOSAR which has no concept of default mode values at all. To work with both formats, the underlying XNET driver assumes a default mode value of zero regardless of what is saved in the DBC file.

For the time being, the expected behavior is that XNET assumes a default mode value of zero at session creation. We will be updating our documentation and utilities to reflect this in the near future. Additionally, we have added full support for default mode values to our list of most requested features for consideration in future releases.