Software-Injected CAN frames?

[azuther]

I have created a program to read data from a CAN bus and display numerous "signals" graphically.  Frames are read in via frame sessions and parsed with Signal Conversion sessions (ECU communication details prohibit Signal-base sessions directly, but that's really outside the scope of the question posed here).  This program, to be clear, gets it's CAN data by reading from an NI-9862 XNET module, from a CAN bus.

What I want to do now is utilize most of this existing code, except I need to get the CAN frames from an ECU over WiFi.  I can easily enough repackage these received CAN frames (received over a WiFi SSH session) into XNET-formatted CAN frames.  Then, however, is there a way to inject those CAN frames into the "system" such that CAN frame input sessions will read them (in other words, maybe I'm hoping for write-access to the NI-9862's read buffer, for example).  I've poked around all the property nodes and can't find anything to allow this.  Anybody know if this is possible?

My current solution is to use (2) NI-9862 XNET modules, whereby I actually transmit the WiFi-received frames on a real CAN bus with NI-9862 #1, then simply utilize the original software, read those frames with NI-9862 #2.  This, however, requires two NI-9862's and seems a bit silly.

[Hooovahh]

It isn't exactly clear, but what I think you are asking for is the Echo functionality.  On a XNet session you can turn on Echoing of frames.  This will mean that all frames that are written by your device, will be read back.  The frame will have the Echo boolean set so that you know what frames are from your XNet device write, or from the read from other devices on the bus.  I believe the only frames that will be read by as an Echo are ones actually acknowledge by other nodes on the bus.  If you try to write with no other devices your read will be empty even though you are technically writing frames.

[azuther]

Yeah I considered trying that and I think that would maybe work, but I didn't go down that path because it will still require a second CAN device on the CAN bus to ACK the transmitted frames.  However, using echo functionality at least wouldn't require that second device on the bus to be an NI-9862.

[Hooovahh]

---

@azuther wrote:

However, using echo functionality at least wouldn't require that second device on the bus to be an NI-9862.

---

Exactly.  If you are talking to any other device at all then this is already taken care of for you.  And if you aren't talking to anything...what's the point of a communication bus?  I think there is a property somewhere that might enable echo'ed frames for frames that haven't been ACK'ed yet but this can mean lots of data since CAN will continue to retransmit if no one is there to ACK.

[azuther]

---

@Hooovahh wrote:

---

  And if you aren't talking to anything...what's the point of a communication bus? 

---

Exactly, ideally I wouldn't need to use any physical CAN interface at all, since my frames are coming over WiFi.  My use of an NI-9862 thus far has only been as a way of getting the frames into the 'system' to then be processed (per the XNET database) and sent to my various XNET sessions.

[GPIB_Guru]

If you are getting the frames over WiFi, why not just use a frame to signal conversion session and create the frames yourself. You don't need hardware at all.

[azuther]

Because I'm trying to re-use an existing application which was intended to read frames from a vehicle's CAN bus.

[GPIB_Guru]

If you want to use an existing application for that, I would probably recommend getting a second CAN controller (of any type), connecting them together. Then create a small application to read from WiFi and write to the second controller. The first controller, running the existing application unmodified, should receive the frames and parse them correctly since they came from the CAN bus.

If you could break your program apart into two pieces it would be simpler though. The first part would use the CAN Frame APIs to receive data and then send the frames to a frame-to-signal conversion session to get the signal data. The code could then be modularized to receive CAN frames from any source but still follow the frame-to-signal conversion portion to get maximum code reuse. Essentially, you have a path for CAN bus data and for simulated data that get merged into the processing portion.

[azuther]

OK; Yeah your first comment there is exactly what I've done thus far, using two 9862 modules, and I'd really like to leave the application untouched unless absolutely necessary.

I might try out the echo functionality but I think there's a small snag I haven't figured out yet.  In the NI XNET Bus Monitor, there's a "Run Mode" setting that allows you to set the interface to "subordinate" such that, effectively, two applications can use the interface (albeit, I believe one needs to be read-only which is fine in my case).  Do you know if that can be accessed through property nodes?  I haven't had much luck finding it, maybe they call it something else?

[azuther]

Ah, alas I don't think subordinate mode will work either, since it would need to be my sessions in the original application that would need to be in subordinate mode in this case.  However, when used as originally intended (i.e. on the vehicle, without any of this emulated CAN frame business I'm trying to do), placing the session in subordinate mode would break the program.

Well, I think I'll stick with the messy solution I've been using of : WiFi_CAN_In -> CAN_frame_repackage -> CAN_frame_transmit -> CAN_frame_read

Thanks for your input.