XNET CAN (frame in)single point issue

[JoVMo]

Hi guys,

I have a problem reading a frame in a single point session. I have this issue now in two different (labview)vi's. In the first a device sends a single frame and I catch it in labview. In the second I send a single point frame from the same vi through another CAN tranceiver and catch this frame in the same vi.

Sometimes the payload get catched and sometimes(like 5 executions) it's like nothing is received? How can I check raw frame data to know my payload is received?

[ThiCop]

Hello,

Can you post the code you're currently using?

[JoVMo]

Thierry,

U can see in my GetStatusInfo.vi that I try to catch a frame everytime there is a new TimeStamp read. This works, but sometimes it detects a new TimeStamp and give me an empty frame??

I got the same behavior in single point and queued frames too. It's like LV don't fetch all the frames.

[GPIB_Guru]

You are actually not doing single-point, instead, you are doing Stream Input. This will read into a queue of frames.

In your while loop, you are doing a Frame CAN read w/o a timeout and a quantity of -1. This means, "return all frames that are currently available". Note, if there are no frames available, this will return an empty array.

Here is where it gets tricky and you may need to know more about LabVIEW. You have an empty array, and you are then passing that into "index array". If you index an ampty array, you will get get a valid element (since an element cannot be empty) that contains the values of all zeros. This means that the timestamp will have a value of 0 and the payload will be an empty array.

In the next frame, you are just checking for new timestamp to be different from the old timestamp. If the old timestamp was Feb 8th, 2011 @ 07:03 and the new timestamp is '0', that is indeed different and you will capture that as a frame detection.

The simple fix would probably be to make frame detection only trigger on "(old != new) && (new != 0)". Note you need to also skip "old = new" in the last frame if you did NOT detect a frame.

Other possible fixes:

1. Read for 1 frame with a timeout. This will pause the VI until a frame is actually read.

2. Since this is a queue (and not single-point), you can read and "frame detect" would just be if the array is not empty. With queues, old data is not repeated, so there would be no frames in this case. This dramatically simplifies your VI.

[JoVMo]

tnx GPIB, but single point have the same issue then a stream that it doesn't read the frame out of one itteration. It take sometimes 4 read itterations before the timestamp change.

When I use the timeout, would it make a difference in how LV fills the frames? What time I use for the timeout? Or is it just on or off?

[GPIB_Guru]

For single-point, you could just look for a different timestamp. It may take multiple loops, but you shouldn't get a zero timestamp (after one frame has been read, the default timestamp would be 0 for no data at all being read). You overall algorithm seems somewhat appropriate for a single-point case. I don't know about the "frame->table" portion of it. I would tend to just work on the frame that came from the read VI.

If you want to post your single-point version that is failing, I can take a look at it.

[GPIB_Guru]

Sorry, you asked some questions that I didn't answer.

Timeout makes no difference to how frames are received, but it changes the behavior of the Read VI. Instead of returning instantly, it would wait up to X seconds before returning. In this case, you need to specify a number of frames you want to wait for. For example, you can say I want to read 5 frames, and wait up to 3 seconds. So, the XNET read would return as soon as 5 frames are available OR 3 seconds has elapsed (whichever comes first).

The time would be whatever makes sense for your application.

It may take multiple iterations if the frame has not actually been transmitted on the bus. The computer/LV loop rate will be much faster than the CAN bus.

[JoVMo]

yep, the LV's read cycles are much faster then the bus. Thats' why I need many read cycles before I get an update from the bus. Tnx!

[JoVMo]

Ah, and why the old=new statement is not valid? I set them equal, so this wouldn't stop the itteration?

[GPIB_Guru]

It is okay due to how the rest of your algorithm is, but I was thinking if:

old = X

new becomes 0, then your new test for is new frame is ((old != new) && (new != 0)), so there is no new frame.  If you then just blindly copy old = new, then you have..

old = 0.

This is weird and wrong, however, since you are really waiting for new != 0, the fact that the next time through the loop old == new (both 0) that is okay. If you depended on anything else based on old, then this setting could be wrong/buggy.

But, in your case, it would not cause any failures.