XNET: How many sessions?

[Jason_S]

I'm working with XNET for the first time, and I have a rather general question. In my setup, I will be reading and writing several signals. The outputs go to cyclic frames, and the inputs come from cyclic frames. However, I will be reading and writing at random times under software control. In fact, different signals will be written and read at different times and rates.

For simplicity, let's consider just the outputs from my computer. Suppose I'm updating one signal "A" at rate X and one signal "B" at a rate of 0.25X. It may be that the signals are embedded in the same frame, or (for different signals, say "A" and "C") they may be in separate frames. Does it make sense to i) have two separate sessions, one for each signal? Or, ii) should I incorporate both signals into a single session? Or iii) Does it matter?

Thanks,

Jason

[Hooovahh · Accepted solution]

I'd recommend you have one session, which is a Single Single-Point, with all signals in it.  It would then look something like this.

http://zone.ni.com/reference/en-XX/help/372841L-01/nixnet/modesignaloutputsinglepoint/

Here you can write your signals at any time, and regardless of if signals are in the same frame or not, the API will schedule the writing of them to be at the rate specified by the database.  The only downside is on each write you need to write all signals, but that isn't so bad because you can keep in a shift register what the previous write was, and then replace the values with signals that change and keep the previous value for the ones that didn't.  You'd likely also need to read the defaults of all signals on the first write.

[Jason_S]

Hi Hooovahh,

Thanks for the input. Your suggestion makes sense, and was my first instinct. As I thought about it, it wasn't clear which method had less overhead. The problem with your recommended method is that we end up rewritting a lot of data and possibly sending messges that we don't need to. This would be even more true for event frames rather than cyclic frames. OTOH, having numerous sessions seems like it could have a bunch of overhead as well.

I think the question comes down to the exact behavior of the XNET driver and how it responds to the write command under different circumstances (a collection of signals that take whole frames, signals that are only part of a frame, signals that are part of multiple frames, cyclic frames vs. event frames, etc.) It didn't see a very sufficiently detailed description of this in the XNET manual. Perhaps it is elsewhere.

NI, I think this question could be cleared up succintly with a little more detail in the XNET manual.

Ultimately, I doubt it really matters for me and my application. I would simply like to do whatever is "normal," so I will follow your advice.

Thanks,

Jason

[Hooovahh]

---

@Jason_S wrote:

The problem with your recommended method is that we end up rewritting a lot of data and possibly sending messges that we don't need to. This would be even more true for event frames rather than cyclic frames.

---

I'm unsure how it handles event based frames, but as shown in the manual in regards to cyclic frames, they aren't necesarily written when you perform the write function, they are written on a timed basis as defined in the database.

You'd have to experiment with it, but having one sessions for all cyclic frames would work for sure.  If I ever wanted to write a single once, and never again, I'd usually use the frame API, with a conversion from signal to frame.  This is probably partially why I'm unfamiliar with how this mode will work.  If nothing else you can have a single session for signals which are cyclical, and a single session for raw frames, which get sent out once.

[Jason_S]

Hi Hooovahh,

I think the question comes down to the exact behavior of the XNET driver and how it responds to the write command under different circumstances (a collection of signals that take whole frames, signals that are only part of a frame, signals that are part of multiple frames, cyclic frames vs. event frames, etc.) This does a decent job of explaining, but what happens if I perform a write on signals in an event frame and none of the signals have changed? What if I have a lot of signals in my session and I change only one? Will that cause a whole bunch of frames to be unnecessarily written out to the network? I think yes, but it depends on whether or not XNET checks to see if a signal has changed before sending a frame. It seems like that behavior could be right or wrong, depending on the expectations of the ECU receiving the frame.

Regardless, this has become an academic discussion for me I will follow your advice. Mostly.

Jason