Automotive and Embedded Networks
LabVIEW 2017 XNET CAN Read issue
Solved!
I don't fully understand the design, but I tend to not open and close sessions all the time. I generally just open all the sessions I'm going to be needing for my application, then use them and close them all at once on application close. If you are worried about reading old data you can flush a session (or read everything waiting) then start reading again. There are also timestamps if needed. Single point reading is often for things that change quickly, but whos readings individually aren't important. Like an ECU may send out temperature every 20ms, but for displaying it on the UI it doesn't really matter if I read the single point once a second. Is that what you are using the single point read for? If you haven't found it yet I have a blog series on CAN and go over the XNet session types and when you might want to use one or another.
http://hooovahh.blogspot.com/2017/05/can-part-6-in-depth-xnet.html
For a request and response type of messaging a single point session isn't the best approach. Obviously a single point write will mean the request goes out periodically and timed by the hardware which isn't great. But even the single point read isn't what you want because NI's API doesn't allow for you to know when a new frame has came in without polling. And the data coming in for single point (at least signal) will be the default value when no data has been read which makes it hard to know if the device is sending the default, or if it has never communicated.
A better approach for a request/response would be to have a Stream session out, and a Stream session in, or a Stream session out and a Queued session in. I guess the out session could be Queued as well but that seems unnecessary. With the Queued session you must specific the Arbitration ID if the frames you want, but once you do that you can have it do a read with a timeout of say 1 second, trying to read 1 frame. If that frame comes in within one second the function returns immediately with that frame. Otherwise it times out because you never got your response.
Also this sounds an awful lot like ISO15765 for UDS, KWP2000, and a couple of other communication types. NI has the Automotive Diagnostic Command Set for doing these types of calls on NI hardware. And I also reimplemented the state machine and code in G so that it can be used with NI hardware or any other hardware. This is mentioned in Part 8 of the CAN blog. The code posted isn't a drop in solution for NI hardware, but it is meant to show how the protocol can work with any hardware that supports a streamed frame in and out.
Oh and there is a limit to the number of sessions that can be opened for an interface, and globally for the system at once. I don't remember what it is but it is larger than any application probably needs. And the limit was increased with some versions of XNet's API.
Still can't get it to work. I tried Frame Out Stream with Frame In Stream and I've tried the Frame Out Stream with Frame In Queued. Same Msg ID (0x0100) and Payload (0x0400) in both. Neither works. The bus monitor shows what I received when that ID and Payload are sent, so I know it's working. My XNET Read is not reading anything. My original Streaming code didn't have the while loop, I added that to try reading it for 5 seconds. There are five messages I can send that will give me streaming data, all of those work flawlessly. I've tried this with two USB-8502's, both have the same problem.
Streaming and queued with the bus monitor:
Streaming 04 payload
Queued 04 payload
But you are still creating a read session, after performing the write for a request. It is possible that you send the request, then the device replies, then you create the read session, only to find nothing because it has already sent the reply. The read will only return stuff that has occurred since the creation of the session.
What I was suggesting you do is create all of your sessions at once before ever performing a read or write. This could be outside of your loop entirely, or by using data flow to ensure both have started first. Then use those sessions in your loop as you need performing writes reads etc. Then outside of your loop once it stops running close all your sessions.
Also in your code you currently aren't closing your write sessions.
That's new to me. When I run bus monitor it is usually on another port that isn't being used, with a Y cable or ribbon splitting the bus so it can be read independently.
