Timing problems with CAN write in a For loop

[Sima]

Hello,

I'm having a timing issue in a CAN application that I wrote. The application takes a list of CAN messages selected by the user and writes them to a PCI-CAN/XS2 card at specified rates, also selected by the user. The CAN code is running on an RT system. The hardware timing looks like it's working great when I monitor is using MAX Bus Monitor, but I noticed that the write loop, which I have set to run at 10ms, doesn't always run at 10ms. It alternates between 10ms and another number, which depends on how many messages I'm currently writing. For example, if you've selected 3 messages, the loop timer will alternate between 10 ms and 1510 ms back and forth. If you select to write 2 messages, it alternates between 10 ms and 160 ms. Sending 1 message, it will run at 10 ms. So even though the hardware is doing its job and sending out the messages each at their specified rates, the software loop will be slowed down occasionally and the user values will not go out to the hardware as fast as I'd like them to.

I do have a few other things going on inside my write loop, but I've tried disabling everything but the CAN Write VI supposedly to lighten it up, but I still get the same behavior. So, I did the opposite - I disabled just the CAN Write VI, and the loop runs nicely at 10 ms.

Previously I had written the CAN application to send out all the messages at the same rate of 100Hz, but I had never had such a problem. I'm thinking that the CAN Write VI doesn't like to be called this way. I had been trying to follow an example by NI, except I need to always update the write values. I've posted images of my two CAN applications and the NI example I started with.

I hope someone can shed some light for me!

Thanks,

Sima

[DirkW]

Hi,

Perhaps you could post a simplified example VI showing the behavior you mentioned. This application is to complex to debug it with a picture.
It seems it is related to the timing which is different for the tasks.

DirkW

[Sima]

Hello, I finally got back to working on my CAN application and managed to get it working.

My objective was pretty simple. I just wanted to send out a bunch of CAN channels, which the user can select out of the list loaded in MAX, at the rates that the user specifies. The example I posted from NI does this but the "write array" is only sent out once. I wanted it inside a loop so that it could be updated continuously. It seems like the CAN Write VI didn't like being inside a For loop inside a While loop - but I realized that that wasn't necessary at all!

Since after all, once the CAN Write VI is told to send at a certain rate, it will continue to do so. So, why should I keep looping around it if the values I'm writing haven't changed? Which brings me to the moral of the story; I put a case structure around the whole part of that code so that I only call the CAN Write VI when the values I'm writing change. Problem solved. 🙂

The other option is to have another little dummy loop inside a bigger loop. Either way, there's no reason to call the CAN Write VI so often. The hardware will continue to take care of the writing once the VI is called.

Message Edited by Sima on 11-01-2006 10:28 AM

[Bob L]

So no need loop the CAN write... but the example comes withe NI-CAN 2.3.2 "Single Sample Periodic Output.Vi" does put the CAN write inside a loop with a 1ms wait. before goes into the loop, a sample rate is specidied for the task. How to expain this? 

[biker2000]

Hi Bob,

This is just done to provide an option to interactively change the values written to the bus, while the VI runs. If you move the CAN Write VI out of the loop, the provided values will be written to the bus at the specified rate (until the CAN Close is called), but you won't be able to modify the values anymore as LabVIEW advanced past the CAN Write VI.

-B2k

[Bob L]

thank you b2k

can you explian more detail: with the example I mentioned, will the actual write out rate the "sample rate" or the 1ms (plus some execution time)? --- I hope it is the "sample rate", and the 1ms doesn't realy matter if it is far less than the sample time (1/sample rate).

[Sima]

The sample rate will be the sample rate specified when the channels were initialized. The 1ms timer inside the loop is just used to give the CPU a break while the loop is running. Another thing the 1ms timer will affect is how fast the values in the numeric controls Channel 0 and Channel 1 get sent out to the CAN Write VI. But it's got nothing to do with how fast the CAN hardware timing will occur. That, again, is specified by the sample rate at the CAN Init Start VI.