20ms Peak PCAN transmission

[parkerfly]

We are using the Peak Systems PCAN-USB adapter to interface with our CAN network (see http://www.phytec.com/products/can/pc-can-interfaces/peakusb.html for Peak info) and need to set up the transmission of CAN messages at various rates.  We are using vi's from KDI (see http://www.phytec.com/products/can/can-software-development-tools/pcanaddon.html) that allow us to use the Peak adapters from labview.

I've tried many of the solutions I've seen in this forum for timing a loop, but don't seem to be able to get a stable loop time - it seems like there is always a variance in the transmission rate my loop sets up of around 30-40ms from the desired time.  I need to be able to transmit at rates as small as 20ms, but can't find a good solution.  Any suggestions?  I've tried:

* Wait until next ms multiple

* Timed loop

* Wait (ms)

and a couple other ways.  Is WinXP just not able to produce the level of accuracy we need, or is there a better way to do this?

Thank you....

[Xaq]

Parkeyfly-

Unfortunately, Windows is going to determine your loop rates. Your best bet to hit you desired loop rate is:

-Optimize the code inside the loop as best as possible
-Set the execution priority higher (in File>>Vi Properties>>Execution>>Priority)
-Get a faster computer

Beyond that, you are at the mercy of the Window sscheduler

Xaq
Applications Engineer
National Instruments

[parkerfly]

I can understand Windows causing >20ms times, but when I do a trace from PCAN Explorer, I'm seeing times between transmissions of anywhere from 0.6ms to 47.6ms.  Shouldn't LabVIEW make sure that the minimum time between execution is at least 20ms?

I also tried the same code set to 500ms, and a trace showed times of 497.4ms to 505.6ms.

Is it possible it is the way my code is written?  One of the ways I tried it is attached...

[Xaq]

Parkeyfly-

It looks like each time you loop you make two writes to the CAN bus (send fuel level and send road speed). These two writes will execute one directly after another each time the loop is called. Your wiat function will only determine the time between loop iterations. If you want a 20ms pause between each write, you need to use a sequence structure with waits after each write.

Xaq
Applications Engineer
National INstruments

[parkerfly]

Sorry for the confusion - I want both messages to be transmitted at a 20ms rate, so what you described "These two writes will execute one directly after another each time the loop is called. Your wiat function will only determine the time between loop iterations" is what I was trying to do.  I also tried it with a sequence structure (see attached), and I am still seeing times between transmissions as low as 8.2ms. 

It seems like either I am doing something wrong in how I'm trying to time this, or LabVIEW is for some reason not waiting the full 20ms.  Any ideas as to which it is and how it can be corrected?

Thanks...

[ArneVoigt]

hi parkerfly,

I think the measurement with the PCAN-Explorer may add some jitter. That could be the reason for your smaller than 20ms transmission rate. -- just an idea

bye

[parkerfly]

Just to be sure we measured the transmission rate using CANalyzer hardware/software, and it measured approximately the same variation in transmission time - good point though, my understanding is the PCAN Explorer program is not as accurate since it is depending on Windows for it's timing...

[Holt]

Parkerfly,

You should be able to use a while loop with a "wait until next millisecond multiple" to get more accurate timing than you are seeing for a 20ms loop rate.  I'm referring to a loop architecture without a sequence structure.

To debug the timing issues, I would suggest looking at one software component at a time.  I see LabVIEW as one component and the PCAN drivers from KDI as the other.  Ultimately the PCAN explorer will be the final timing test, but let's start out just looking at LabVIEW timing without the CAN calls.

I would suggest creating a LabVIEW app that simply has a while loop without the CAN VIs.  You can create a loop time indicator by using a shift register and the Tick Count VI from the timing pallet.  Wire 20 ms into the "wait until next millisecond multiple".  Run the VI and notice that you only get a slight 1-2 ms jitter on the indicator.  This jitter is due to Windows.  Leave this loop time indicator in the code even after you add the CAN calls.

Now add the CAN VIs into the loop.  What do you see on the loop time indicator?  Hopefully the CAN VIs aren't taking more than 20ms to execute.  They shouldn't unless there is some resource conflict occurring.  Also use LabVIEW's profiling capabilities to see how long the CAN VIs are taking to execute.  You can find this under "Tools >> Profile >> Performance and Memory".  This will tell you how long it takes each VI in your loop to execute.

Check the timing on your PCAN Explorer.  Is it consistent with the loop timing on the indicator.  If no then there may be an issue with the rate at which the CAN VIs can be called.  If yes then we have some more debugging to do.  Let me know.

Thanks,

Todd Holthaus

From a debugging perspective, I would recommend looking at one component at a time to see what is causing the problem.  Ultimately the PCAN Explorer is the