Erratic Can behavior when in Real-Time

[dre99gsx]

I am using 7.1.1 RT, and a PXI-8176 controller with a PXI-8461 CAN card.

On my laptop, I am runing the single port Can PCMCIA card. I am sending CAN packets to some device that successfully parses them and moves motors without any issues. These packets are sent using the Frames vi.s. I wait for the CAN_receive to "hear" for CAN packets sent back by my device, which I use to determine if the motor move was successful or not. I can repeat this process very quickly, back and forth, many times, in sync.

As soon as I transfer this to my PXI chassis in Real-Time mode, I begin to get erratic CAN behavior. Late packets... long delays before I see any packets... I have even probed a while loop (which is included in your Can_Receive.vi), and notice the iterations count will sometimes stall for a few seconds, whilst my CAN packets are not updating on the screen.

Regardless, is there any known speed issues with sending/receiving CAN messages via Real time, or some general do's and don'ts? Thanks.

[dhuff]

It sound like there is some unusual activity going on inside the VI's. Try opening up the code to see if there are unusual wait states. Some of the CAN channel API's use a version of CAN read that will hold the VI from executing unless there is a CAN message received. You really probably want a CAN read that does a non-blocking read, so if there are NO CAN messages to read, it returns a 0 and moves on, and the rest of your code can continue executing.

[dre99gsx]

I have done some vi disabling and checking, and found a lead. Currently, every 10ms, I run ncRead to check for CAN packets. If it retuns datalength 0, I do not execute the CAN packet array parse vi. If I put a case structure over this ncRead (disabling it), the entire program runs very smoothly on my Real-Time PXI chassis. As soon as I enable the ncRead, that is when I get sparatic pauses and continues of my entire program.

You may be right, that this ncReadNetMult.vi function itself is causing some sort of delays in realtime.

My program essential packets CAN messages and sends them via the ncWrite function. Could it be possible that my ncWrite and ncRead, running in Real-Time, could have some latency issues? Can Labview CAN actually read and write at the same time? There may be a possibility that at the moment I am writing to CAN, a Read is occurring and delaying my Write?

Thanks.

[dhuff]

This is why I prefer using the CAN buffers, if you use a a read buffer, it actually speeds things up. Your VI only has to return the number of elements in the read buffer to do a read, if it is 0, you DO NOT decode the packets. If there are messages, they get returned in a buffer that is easy to search using a for loop, and the VI is not waiting on a CAN chip to get a command to return messages. The write buffer is helpful if only to keep the CAN chip busy, if there is a message in the CAN buffer, it will send it without being explicitly told all the time, and my VI is not forced to wait for hardware to become available.
You can configure the system to send and receive messages on 1 CAN port, it will work very well in Labview or Labview RT.

[dre99gsx]

Right, I am using the supplied CAN Receive.vi from Labview, with a buffer of 50. If no packets are received from the ncRead, then I do not "decode" those packets.

But, it seems that just running the ncRead, even with no packets coming back through the CAN (since when I send packets on Port0, they do not show up on Port0 using the ncRead... almost like echo is off), causes these delays... I may be wrong, but just curious if anyone else witnessed this.

[dre99gsx]

I think I've stumbled upon the culprite. The ncRead.vi, when it sees that it has CAN packets in its buffer, causes another .vi to run which gets the data from the buffer, and puts it into an array. This array than is displayed into an actual array container on the front panel.

By simply cutting the connection between the array shift register and the array display, I have gotten rid of most of the undeterminism while under Real Time! I also have a global vi. which was run as embedded. By changing it to normal (no embedded), the entire program actually got worse as far as speed is concerned. I then mistakenly closed the front panel of the vi, and my determinism improved drastically.

And, taking some advice I read beforehand, I made any arrays or "concatenate string" functions within my program, have an initialized array before hand, to reduce memory issues.

All three of these have made my program very stable, a bit faster, and deterministic. The program still runs 30% faster on my 2.8ghz laptop. could be the 1.3ghz PXI system can only do so much...