Automotive and Embedded Networks
What kind of write session should I use to efficiently handle Cyclic and Event frames ?
Hi, I'm not very familiar with XNET driver but here is what I'm trying to do.
In my setup, I will be writing several signals. These signals are embedded in cyclic or event frames.
I've tried to use a Frame Outout single-point session to handle all my frames : it works fine for cyclic frames, but even if I modify only one frame from the array of frames required by the write VI it physically writes all frames on the bus !
Same thing if I use Signal ouput session VIs, it writes all signals on the bus even if the value of only one of them changed.
What should I do to only write a speicif event frame without sending the value of the other frames on the bus ?
Should I create 1 Frame Outout single-point session per frame ? Is it possible to do this on the same CAN interface ?
@zyl7 wrote:
Should I create 1 Frame Outout single-point session per frame ? Is it possible to do this on the same CAN interface ?
You shouldn't have to do that. I haven't tested this functionality, but I assumed it worked the way you expected it. When you write a frame, it is the value that that frame should have and should write the next time that frame is written. And even the documentation states it shoiiuld work the way you expect. Can we see some code to see if there is something unexpected happening?
Hi Hooovah!
Thank you for the answer !
The example pointed by the link you've given is quite simple : only 2 frames, 1 is cyclic the other is event-based.
In my case, I've got 15 frames : 2 are cyclic, the others are event-based.
If I open a session Frame Output Single-Point over a table of these 15 frames, I've got to handle a table of 15 clusters describing the state of these frames. Each call to Write Frame VI is asking for the this table of 15 frames. Each call send the 15 frames on the bus.
What I want to do is send only the frames that have changed (x out of 15 frame that have their description different from previous loop) on the bus.
The code is for a military grade customer so I can't expose it clearly here. If you really need to see it, let me know and I can take some time to extract pertinent code to display it here.
@zyl7 wrote:
Hi Hooovah!
If I open a session Frame Output Single-Point over a table of these 15 frames, I've got to handle a table of 15 clusters describing the state of these frames. Each call to Write Frame VI is asking for the this table of 15 frames. Each call send the 15 frames on the bus.
That's what arrays and shift registers or feedback nodes are for. Don't bother with 15 clusters, use an array with 15 elements (it scales better when all the sudden there are 16 frames that need to be handled). Attached is an example. Call this instead of the XNet Write for the frames and it should take care of it for you. The only catch is you need to write all the frames the very first time in the order that they should be written. Then every time after that all you need to do is call it with the frames you want to update, and it keeps track of all the values of the previous frames that were written.
Hi Hooovah,
Your example is more or less what I'm doing in my application.
Except that I open a session as Frame Ouput Single Point (once) before calling the Write Frame VI.
If I write an array (and not table, sorry for my previous post) smaller than the array used in the Create Session VI, then the Write function returns an error saying that the array is not well sized.
Attached is a part of my code today : I opened a session for each single frame in my DB. Like this I can write only the frame I want when needed...
IMO, this not really efficient nor 'easy' to use...
@zyl7 wrote:
If I write an array (and not table, sorry for my previous post) smaller than the array used in the Create Session VI, then the Write function returns an error saying that the array is not well sized.
Then size it well. This was what I meant by stating you need to call the function the first time, writing the first value for all frames. Then the values will be replaced with the new ones when you write it. You can do as you please but one session with an array of frames seems easier to maintain than an array of sessions with one frame for each.
Hi Hooovah,
That's what I did before. The array is well sized, with all the frames I might send on event. And the session is initialized with that array.
I can handle a context and update it only with the frames which have changed. But calling Write Frame VI will send on the bus the 15 frames (and not only the ones which have changed)... This loads the bus for nothing.
@zyl7 wrote:
But calling Write Frame VI will send on the bus the 15 frames (and not only the ones which have changed)... This loads the bus for nothing.
That not how the API documentation says it should behave. Sorry I don't have any other suggestions.
Hi,
Thank you all ansers.
Finally had support from NI and the solution was to create one session per frame.
It works fine like that.
Thanks.
