Cyclic Remote mode in the XNET driver for CAN

[aglet]

I'm hoping someone can help me understand my options in using the XNET driver for a CAN interface.

I have an implmentation that has two devices communicating to each other through a CAN interface. I would like to remove one of the devices and simulate activities of this device (seems easy enough). As I review the XNET driver there are a few modes of operation that I would like to take advantage of:

Cyclic: Always send a status message

Event Remote: Send the approiate message (response) when asked (command)

Cyclic Remote: Send cyclic status messages when commanded

All of these seem to be easy enough to set-up in the database. However it appears that the event remote and cyclic remote modes require that the slot Id is the same. Is this the case? If so does someone have a recommendation on how to handle different slot IDs for the remote modes?

[muffin.vi]

aglet,

Just to clarify, by "slot ID" do you mean the CAN Arbitration ID? (Sometimes in our documentation, this is just called the "Identifier".) Slot ID is typically a term used in FlexRay applications. I wanted to check to make sure I wasn't misunderstanding you. 

[aglet]

Yes, I think.......

Let me expand on my original post.

I have a have a  CAN implementation that I am struggling with.

I have two devices that communicate to each other through the CAN interface and would like to simulate one of the devices. The device that I am simulating needs to:

• send a status message every 5ms
• respond to a given command the appropriate data
• send a secondary status message when in a particular mode of operation

From a database point of view each of these looks like:

• Cyclic
• Event remote
• Cyclic remote

Where I am struggling is in the setting up of the event remote and the cyclic remote sessions.

I've reviewed the "XNET Hardware and Software Manual" and came across this section.

I interpret this as saying that both messages are sent to the same arbitration ID but I cannot see how this would work.

[muffin.vi]

aglet,

I did some more research, and I don't think that remote frames are going to be the best for your application.

Remote frames operate on a lower level than most of the XNET API calls. I believe when a remote frame is sent by a CAN node, the receiving node will reply immediately with the data at the same arbitration ID as the frame that is sent. The sender must know this will occur and read the data despite the frame not being addressed to the sender. There does not appear to be a way to change this. However, since all messages are sent out on the whole bus, the data is still available. The arbitration ID just may not be what you want it to be. 

If your goal is to simulate a CAN device, the best way would be to do so programatically. That way, you would have full control over the interface. You can use LabVIEW and the XNET API to have nearly complete control over the behavior of the interface. The remote frame framework doesn't really work that way. 

[aglet]

Thank you for the feedback.

I thought that might be the answer so I started development on an application to take full control of the interface. Which led me to a different question on how to handle these command-response frames.

May plan is to open 4 sessions on the same port.

1. Session for reading the frame data from the bus and looking at the payload for one of ten potential commands. If a command is received respond with the appropriate frame data on session 2 (some of which are extended frames).

2. Session for writing the response data frames

3. Session for wrting the status data every cycle.

4. Session for writing the status data every cycle when in a particular mode of operation.

The questions are;  What happens if I open a session that utilizes multiple frames. On the read operation will the driver just return the frame that is on the bus at the time of the read or will it wait for all frames to be read? Also, on the write the XNET driver expects data for all frames in a session will the driver understand that from one write to the next that the data for only one of the frames has changed and is therefore the only frame that needs to be written?

I guess I'm wondering if I need to open two sessions for every command-response pair that I have, that would result in 20 sessions not including the status sessions that are required.

[muffin.vi]

aglet,

There are different types of frame session that handle multiple frames in different ways. In general, your options are: single-point, queued, and stream. 

You can chose the frame session that matches the functionality your're looking for. A single-point frame input, for instance, will read only the latest frame on the bus. Stream frame input, however, will store all frames received in an array.  

I recommend looking at pages 4-14 thru 4-28 of the XNET hardware and software manual. The link is here.

[aglet]

Kyle,

I'm still stuck. You say:

---

You can chose the frame session that matches the functionality your're looking for. A single-point frame input, for instance, will read only the latest frame on the bus. Stream frame input, however, will store all frames received in an array.  

---

This is kind of true. The read operation will return the most recent frame data for all frames that the session is initialized with. Because the remote event timing type will not work for me I now need to continually examine the CAN bus, look an event frame and if this occurs send the appropriate response. If every time I use the XNET read from the I get all frames returned I have no way of distinguishing if this is a new send of data or not.

[muffin.vi]

aglet,

You will most definitely have to continually examine the bus. There's really no way around that architecture. I'm not really sure what you mean by the last sentence, though. The array of frames returned is in order of when they are received. So, each new frame will be tacked on to the bottom of the array. 

[aglet]

Kyle,

That not quite what I am seeing. When I open a Frame In Single Point session and call the read frame VI I get an array of all of the frames that the session was initialized with and the payload is all zeros. Where this causes me trouble is the "Command" message that I am working with is really just a trigger to get the appropriate response and includes all zeros as the payload data.

I've attached a subset of the specification for the command / response mechanism.

BTW: I do appreciate your help.

[aglet]

For the sake of completeness I've attached the application software as it stands today.