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

[NathanDII]

I'm working with J1939 in XNET using it to simulated ECUs (with Signal Output Single-point API) and I'm needing to be able to disable and re-enable specific frames from being transmitted on the bus.

Is this possible?  If so, how?

[JefeL]

Assuming your frames are of the cyclic type, you can try calling XNET Stop.vi with the session only scope.

Even frame types are only transmitted when XNET Write is called so for these you can simply stop calling XNET Write.vi.

[NathanDII]

The only way that I've been able to get things to work with J1939 is to use a signal output single-point session for each ECU that I'm simulating (with all of its signals associated to that session) but I need to stop transmitting only one of many frames that it transmits.  If I call XNET Stop for the session, the entire ECU will stop being simulated which is not what I need.

I am not using any of the frame modes.  All of my frames, at the moment, are purely cyclic but I can't guarantee that that will be the case in the long run (I might have event and cyclic/event frames also).

[JefeL · Accepted solution]

For this approach, you will need to break it down into multiple sessions instead of using a single session with all the signals. You can group all the signals for a specific frame into a single Signal Output session and then have a separate Signal Output session for each frame you wish to turn on/off. When you stop a session with these signals, that frame will no longer transmit but the others will continue to do so.

Then leave the "always on" signals in a Signal Output session that does not call XNET Stop.vi.

You can accomplish this with clever use of the database API, for loops, and state machines.

[Hooovahh]

Or something else I've tried and had successful in situations like this, is to set the Frame >> Skip N Cyclic Frames.  This allows the setup to have one session with several frames that get transmitted in it.  Then you can pick each frame from that session and suppress them for some amount of time (Using Frame >> Active first).  I just set the value to INF (which is actually coerced to 4294967295.  Then every every hour I suppress those frames again.  This allows me to have one session will all the periodic frames in it, and then selectively turn some off, or back on again.

[NathanJD]

In my test scenario, this worked for being able to disable frames but now all frames are being sent from the same source address (the one that address claims last) even though I have 2 ECUs defined in their own Frame Output Stream session.  This means that a simulated ECU consists of one Frame Output Stream session which is used for address claiming and one Signal Output Single-point per transmitted frame for the ECU (I've attached my test VI for creating the necessary sessions as described).  I'm not doing anything with the Frame Output Stream session at the moment but it does show the correct J1939.Address.

Why are these frames not associating with the correct ECU?  They are properly defined as being transmitted by the proper ECU in the database file.  How do I get multiple sessions to know that they are related to a specific ECU?

(FYI, I am the OP, I accidentally posted with my other account originally, sorry.)

[NathanJD]

So, I changed it such that I set the ECU property for all sessions that are created.  This seems to fix the correlation of message with ECU source address.  Is this the correct thing to do?

If yes, I'm confused as to when address arbitration actually occurs and how can I make it re-arbitrate (effectively, I would like to create an artificial power-down, power-up sequence).  It address claims after the first time I start the interface but doesn't do it again when I stop and then start the interface while the application is running.

[JefeL]

This is a interesting scenario and one that I have not yet run across. I'm looking at both this post and the other one to try and determine what the expected behavior is when multiple sessions on the same interface have different node addresses. Please bear with me as I do the research required to get an accurate answer.

The two posts have some overlap so to keep things organized by topic for future readers I will keep this post oriented more toward starting and stopping sessions. I will post updates on address claiming in the other thread.

[labviewman]

This works (stopping sessions where each session is for a single frame), even with frames using a J1939 transport protocol. However, once you enable frames using a transport protocol, the messages being sent via the transport protocol will come out at high-speed until all the frames that would have been sent if not paused...are sent. XNET will buffer "stopped" sessions with an active transport protocol. 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).

[labviewman]

Using "Frm.SkipNCyclic" doesn't seem to work with a J1939 msg that is configured to use >8 bytes in the database, even if 8 bytes was written using a Frame Single-point session. Error -1074384755 happens (NI-XNET: (Hex 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).