Cyclic CAN Frame output and then updating signals

[AndyJD]

I think I have go 'back to basics' with what I've been doing/learnt with XNET and CAN. Sorry to ask this but my understanding of how things work was very wrong.

I currently have certain Cyclic Frames being output ok using Frame Out Queued mode. This starts the Frames being output continuously as per timings stated in database. I create a default Payload for each Frame using Signal's default values as also defined in my database.

If I then want to update a Signal value in one of these Frames I create a Signal Out Single-point session. After a 'XNET Write (Signal Single-point)' this creates another Frame being output on top of the already running Frame output, which I didn't want. I just want to update values in a Frame already being output continuously under timing control of XNET.

So, instead....if I want to have Frames (Cyclic) to be sent continuously, e.g. I have 10 Frames each with multiple signals to start transmitting with the default values in my database, and then have a VI that allows a specific Signal to be changed to a new value I would have to first create a 'Signal Out Single-point' session and pass it EVERY signal in my database, and then keep a track of all the Values (for all Signals), which are then passed each time I call 'XNET Write (Signal-point).vi' ?

Much appreciate any advice. I have searched and there are a coupe of previous posts stating the same dilema/confusion but am not clear still of how to do this.

[ZYOng]

Why would you need both Queued and Single-Point sessions on the same frames?

I think that only Single-Point session is sufficient. If you want to control the same session using both frame and signal values, you can use a conversion session to switch between frame and signal values.

[AndyJD]

Thank you for your reply.

To start Cyclic Frames continuous transfers going I see now I am not wanting to write a sequence of values for each Frame, so I can use 'Frame output Single Point' mode instead and just use 'build array' to pass it a single Frame (set with default payload). I am currently saving Frame name (String) plus session to a LabVIEW map as a lookup. This is to allow certain Cyclic Frames to be stopped which is a requirement. Interaction with my VIs needs to be Frame and Signal names as Strings.

I do have code I've written/copied to convert Signals (from passed Signal string names + Values) to Frames. After conversion, which produces an array of Frames (elements = "XNET Frame CAN.ctl" type) I would have to somehow work out the Frame name from the Arbitration ID within each XNET Frame CAN.ctl cluster, and then find the Frame Output Single Point session used for that frame previously (map lookup) to then perform the Write to update signals.

The other thing I've looked into is using the array of Frames (converted from Signals) and just use 'Frame output Stream' mode then perform a Write. This though won't use timings from the database and just outputs all the Frames immediately.

[AndyJD]

Another thing I've tried is to create a Signal Out session (tried both Single point and XY) for each and every Signal in my database. Each session is saved along with the Signal name in a map (key = Signal name, value = session ref.).

With a VI that has as input a Signal name and value, I perform a lookup to find the previsouly created session and call 'XNET Write (Signal single-point)', or 'XNET Write (Signal XY)' when I tried XY mode.

If I call this VI multiple times with the same signal, and different signal values I can see the Cyclic frame being transmitted at the correct rate, and the payload updating correctly with the signal value.

If I then call this same VI with a different signal in the SAME Frame (which uses a different session) then multiple Frames start to be transmitted, i.e. one Frame with the first signal value, and the next Frame with the other signal value...thus the Cyclic frame rate is totally wrong with alternate signals in each one trasnmitted.

XNET is not 'clever enough' to realise the signals are in the same Frame.

What I'll try next is to create a Frame output session for each Frame, and keep a track of all signal values myself, so that I perform a signal to Frame conversion each time a signal value changes, and write this Frame with the same Frame out session 😐

Should it really be this hard, or am I still not understanding something fundamental here ?

[Hooovahh · Accepted solution]

---

@AndyJD wrote:

So, instead....if I want to have Frames (Cyclic) to be sent continuously, e.g. I have 10 Frames each with multiple signals to start transmitting with the default values in my database, and then have a VI that allows a specific Signal to be changed to a new value I would have to first create a 'Signal Out Single-point' session and pass it EVERY signal in my database, and then keep a track of all the Values (for all Signals), which are then passed each time I call 'XNET Write (Signal-point).vi' ?

---

That's how I would do it.  The Single Point Output is useful for things that just need to be sent out periodically, but doesn't have any Request/Response communication.  Attached is an example that might be helpful.  You need to add the Interface, and update the constant of Signals with the ones you actually use.  But after that just run it, and it will write them.  Then from the UI you select the signal you want, change the value, then click Update and it will update that signal's value.

[ZYOng]

If I understand correctly, the requirements include:

1. Use the hardware timing hence you cannot use a stream out session with in memory database.
2. Able to stop any cyclic frames anytime, hence you would need a separate session for each frame
3. Able to update the value based on the frame and signal names, hence you would need to use a conversion session.

This would require a combination of workarounds for each requirement.

I think your next step of "create a Frame output session for each Frame, and keep a track of all signal values myself, so that I perform a signal to Frame conversion each time a signal value changes, and write this Frame with the same Frame out session" is exactly I would do and suggest.

On the comment of "XNET is not 'clever enough' to realise the signals are in the same Frame.".  I think all sessions work separately and communicate with the XNET firmware on their owns, even only with single hardware.

[AndyJD]

Thank you Hooovahh,

I tried your example, replaced the list of Signals with some of my own and set CAN interface and works perfectly.

Next task is to add ability for sequences of Values but I guess I can just change the Single Point Output session here to an XY one, and pass it arrays of values each time I do a write?

Am also interested if I can use your XNet CRC Counter scripts on top of this to get the hardware based counter signals and CRC calculations being performed per frame.

[AndyJD]

ZYOng, sorry only just seen your post.

I will also look into doing this now 

[Hooovahh]

Yeah those requirements do step up the complexity a bit.  At some point you also might want to think about doing this at a frame level instead of signal.  I don't use the signal sessions, only frame, and do the frame and signal conversion separately.

The example you probably already found here deals with the frame output on a single point frame session type.  You perform the frame write once, and then the XNet hardware takes care of sending it at the rate you specified, and updating the CRC and Counter without needing to do anything else.  To get to this point you obviously need to know the frame representation of what you want.  The Frame Signal conversion library mentioned in this post, or also discussed in the post on NI.com here can help with that.  There is currently a bug with some negative numbers, depending on the type used in the database, and CAN-FD isn't supported yet but I'm close to having an update for those cases.

If you do go the Frame writing route instead of Signal, you can also use the Bucket Filling Technique mentioned here for the Frame Queued session type.

Several ways to do what you want, each need some thought and testing for sure.  It starts to get really complicated when you are adding multiple hardware types, muxing signals, logging, XCP and UDS, and other communication methods.  I've been trying to update mine to support these things better but it is a time sink for sure.

[ZYOng]

Or you can try NI-VCOM. The API allows you to control individual signal values as well as the Tx_enable for each frame. It requires an additional license though.