Disable/Enable Specific Frame On The Fly w/ Signal Output Single-point

[labviewman]

The solution to not being able to properly stop transmission of J1939 frames with a payload of greater than 8 bytes which uses a transport protocol (due to a XNET bug) is to call a property node "Frm.CAN.TxTime" on the Frame Single-point session (maybe works with a Signal Single-point session) and pass a high value like 4,000,000 (max value is (2^32/1000 - 1). To re-enable the frame, write to the same property node with the desired period of the frame.

[Hooovahh]

---

@labviewman wrote:

It's not supposed to do this and is a bug (confirmed by NI). I found this on XNET 20.5. The issue exists with "Frame Out Single-point" and "Signal Out Single-point" (I didn't try anything else).

---

Is there a Bug number associated with this?  It helps track issues like this by being able to search for the number in the release notes of new versions of XNet.

[labviewman]

Hi Hooovahh. No not yet, but I've never received a bug number for any that I've found. I'll ask (escalation is still in progress).

[labviewman]

NI R&D has confirmed the bug. The bug number is 2250040 and is (hopefully) to be fixed in January 2023

[labviewman]

Another bug that I found at the same time and has been confirmed by NI R&D is if a cyclic PGN (J1939) is configured for >8 bytes, using "Frm.SkipNCyclic" will return error 0xBFF6308D (The property ID you specified is not valid (or not valid for the current session mode or form factor). Check to make sure the installed XNET driver supports the specified property ID).

This is bug 2250189