labview timed loop not working for 1 microsecond period

[sku1988]

Hello all,

I am just a newbea to NI cRIO 9075 and started programming it recently.

NI cRIO - integrated chassis + controller it has 400 Mhz processor.

I am using LabVIEW RT module 

Case I: 

I have created a timed loop in my target VI and set a clock as 1KHz & period as 1 millisecond with my timed loop empty (i.e .no any other code like I/O placed) . I have made my VI to abort after 1 second.

The code works fine i.e my time loop ideally completes 1000 iteration in 1 sec.

When I select 1MHz clock source on my time loop and set period as 500 microsec. it still works fine giving me iteration count of 2000 in 1 sec.

But as I go on decreasing the period , the margin between ideal loop count and what I am getting actually is increasing.

and finally when I set this period as 1 microsecond the iteration count just shows any random value like 7000... where infact it should ideally give me a very larger number.

Case II: 

Now when I place an I/O shared variable to read temperature from NI 9211 ; my iteration count does get lowered than what I was getting with an empty time loop.....so is it like , inserting an I/O operation adds some extra time to my loop execution time?

and finally when I make period as 1 microsecond and run the vi it flashes a message as-  waiting for target to respond stop & disconnect.

My vi automatically stops running. 

So my questions are- 

1. If it says that it has a 400 Mhz processor it should  work at 1 microsecond period (rather in nanosecond range also).....where in fact my vi runs satisfactorily at upto 300 microsec.only...below that results are not accpetable

2. My target runs on VxWorks RTOS ....what is the least time resolution of this RTOS?...as for Windows OS it is 1ms (Clock 1KHz) so windows can't achieve microsecond resolution 

3. while selecting target under my project I checked a radio button saying Use scan Interface mode as I don't have FPGA module installed......so is it getting affected because of scan mode? .....But I don't use synchronize to scan mode option in timing source entity.....I select individual clocks as 1KHz & 1MHz as I have mentioned it earlier .

Kind request to help me in this regard a.s.a.p.

Best Regards,

Snehal Upadhye

Certified LabVIEW Associate Developer 

[Texas_Diaz]

Hey there.

With the timed loop, you can control the frequency the loop is *fired* - so long as the loop had completed already.  Think of it like this:  I have a loop running at 1Hz with a 1s period - meaning the loop is "fired" every second - and the execution blocks inside the loop take 130ms to execute.  That means there's 870ms of "dead time" for other things on the cRIO to use (such as other VI threads, OS threads including network and I/O, and so on) before the loop needs to fire again.  Then, I set my loop to run at 1kHz with a 1ms period - meaning my loop is fired once every millisecond - and the execution blocks inside the loop STILL take 130ms to execute.  This means the loop will fire at time t=0ms, and then the loop will be available to fire again at time t=131ms; the issue here is that the contents inside the loop MUST complete before the loop is allowed to be rescheduled.  If you look at the status blocks inside the loop, you can determine whether or not the loop "ran late" - meaning it took longer to execute than the period set for the loop.  However, realize that the Timed Loop runs at a priority HIGHER than anything else in the system - including networking, I/O, and others.  This means if your timed loop operations exceed the period of the loop, it's likely there's no CPU time available for other things in the system to run - including networking.  Now, your controller's VI will continue to run, you just may not be able to get any communication to/from the cRIO because you're eating all the CPU just processing your timed loop.  When you get down into the microsecond resolution for the timed loop, it doesn't surprise me at all that you're having hiccups on a cRIO with a 400MHz CPU - the overhead of running the scheduler for the Timed Loop is likely going to cause the loop to run late all by itself.  The 1MHz clock was designed to allow you to perform sub-millisecond resolution (if the system can handle it) but not necessarily 1us resolution - for example 250us resolution depending on what you're doing within the Timed Loop (at sub-millisecond resolution you have to be very careful about what you're doing so that your loop doesn't run late).

Hope this helps explain a few things.

-Danny