Missed iterations of TTL triggered timed loop

Hello everyone,
I have a camera control VI that waits for TTL information from the camera shutter and uses it as a timing source for a timed loop. In this timed loop the camera is readout and analyzed. The program should react as soon a possible to a new image and therefore I set the timed loop to 'Discard missed items' so that it doesnt try to catch up (the events im trying to detect are quite rare and last several frames).
The problem is this: When I set the camera for a certain numebr of frames (for example 10.000 frames) sometimes due to the discarded frames the loop iteration number never reaches the expected last frame number and doesnt exit (it stays at 9.998 for instance). I noticed I can prevent this by deselecting 'maintain original phase' . However it is unclear to me what exactly happens with these settings in a TTL triggered situation like this.
Is it the case that the loop skips the new data but starts the next loop at the correct iteration number (+1)? Or is something else happening?
Im thankfull for any help!
Solved!
Go to Solution.

Dear j.win,
If you deselect "Maintain Original Phase", actually you will never discard any iteration, whatever the value of "Discard missed items". Instead, the loop will try to catch up with the late iterations.
Using an external timing source (your TTL for example) instead of an internal timing source does not change anything. You can use the "Period" (dt) input of the Timed Loop to specify when the loop is supposed to iterate (the unit is the "ticks" in the case of an external timing source). A value of "1" means that the Loop try to iterate at every ticks of the external timing source. If for some reason one iteration lasts longer than that, you will have a "late iteration". Also with a value of "1", it is not possible to modify the "phase", then the "Maintain Original Phase" parameter will just defined wether or not you skip the iteration. If "Maintain Original Phase" is false, the loop will execute immediatly after a late iteration to still execute it, but a bit latter. If the "Maintain Original Phase" is true, the loop will execute immediatly after a late iteraion if the "Discard missed item" is false otherwise the loop will skip the iteration.
Is it clearer now?
Regards,
Cédric | NI Belgium

Similar Messages

CVS-1458RT - ISO I/P triggered timed loop

Hi everyone,
I am developing a real-time machine vision application on a CVS-1458 RT.
What I am aiming is a timed loop that is triggered via external clock (in my case a photoelectric sensor connected to an ISO input). All examples I can find are related to DAQmx devices, nothing related to visionRIO.
Question 1: Is this the best way to construct the acquisition loop? I want it to be condition based as to free-up the CPU from continous polling. If not, wht is the best way ?
Question 2: If the above method is OK, how can I setup the input node of my timed loop in a way to implement this ?
Thank you,
Omar

Hi Omar,
I was able to find some Vision-RIO examples in the Example Finder of LabVIEW. If you open LabVIEW and navigate to Help>> Find Examples.
In the Example Finder in the Browse tab navigate to Hardware Input and Output>> Vision Acquisition>> Vision-RIO.

Boolean triggered timed loop

Good afternoon Labview board,
I'm building code that turns a mouse click into a 2sec boolean true (indicator). My requirements are that...
1. Once the 2sec passes the boolean switches back to false.
2. The user is unable to re-trigger the process until it returns false.
I have attached a LabView v8.6 VI. It works, but very poorly. It often misses the mouse click, and has an unwanted latency.
Any help improving or redesigning it would greatly appreciated!
Thanks,
super-neuron
Attachments:
Untitled 2.vi ‏21 KB

Hi Super,
Have modified a VI i used a while back to do something similar:
I have made this into a subvi so you can use it as shown below:
I have attached both the subvi and example vi below in 8.6.
Hope it is what you need.
Regards,
Lucither
"Everything should be made as simple as possible but no simpler"
Attachments:
Timed True Latch.vi ‏38 KB
Timed True Latch Example.vi ‏7 KB

Timed loop miss some items

Hi all,
I am using cRIO 9025 AND NI 9203 to sample from seven current channels at 1000 Hz. I wrote the data with timestamp into a file. However, it seems that the sampling is not continous.
As you can see from the text file attached, the time stamps for the fisrt sample and the second sample have a difference which is 3 ms. Then this would happen every 208 samples. If you open the file with Notepad++, you would see it clearly.
And I found that if I decrease the number of channels from 7 to 1, the problem would happen every 656 samples which is very wierd.
I try my best but still can't understand why this happens. Could you please help me have a look at the VI?
Thank you very much.
Attachments:
1KHzSample.vi ‏73 KB
7-Current Sep,27,2010 13h49m45sec.txt ‏1073 KB

From looking into the VI, i can only guess why the "time jumps" occur so "deterministic".
But it is quite obvious to me that some things can be optimized which maybe can already remove the issue:
- Eliminate redundant code (taking timestamp).
- Remove unnecessary computations (select function, feedback for dt and false-constants).
- Stick to one datatype (change the offset and scale to double).
- Never ever compare doubles as equal/not equal!
- Split up logging from acquisition into different loops. Use RT FIFOs instead of normal queues.
I assume that the "time jumps" are generated by finished late iterations and the setting to maintain the phase and to discard missed iterations....
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

LabVIEW RT, Timed loop, finished late, Call by reference

I have a timed loop triggered by the sample clock of a DAQ-Card. The sample Clock is 8 kHz and the loop will run with dt = 4. Normally the loop is running without finished late[i-1]. But from time to time it happens that the loop is running extremly longer which means instead of 0.5 millisec it needs 4 - 5 millisec. It seems this doesn't never occur while accessing DAQmx.
The application uses plugin technologies and some of the VIs in the timed loop are preloaded and called by Call by Reference.
Does those VIs inherit the priority, execution system and CPU of the timed loop?
The application is running on LV RT 2009 on a Dual core PXI-Controller. The timed loop is bound to CPU 1. There is no difference runinng the application from the development environment or as a startup application.
For the measuring test I modified the application in a way that I don't have:
disk access for storing the result file
TCP/IP communication
Controls on the front panel of the top level VI
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

To keep you informed:
I stripped the application and have left only the measurement storing module and the timed loop. The loop was using the microsecond timer running each 500 µsec. Additional all Non-Real-Time modules were loaded and only one module creates a XML string and sends it to the communication layer which will drop it because no TCP/IP port is open. The creation of the XML string is done each 300 ms.
In this case I don't have any finished late iterations
Next I added the DAQ Module. Now I get finished late again but with a lesser frequency as original.
I removed all unnesseccary tasks from the DAQ moulde leaving one task for a PXI-4204 for using as the clock source for the timed loop. No I get finished late seldom.
I removed the module which will send the XML string and I don't get finished late.
Next I was adding code to see memory allocation. I can when memory allocation is changing but it is not related to the finished late iterations.
Next time I have the chance to do more tests I will see which DAQ task triggers the finished late iterations. I have one AI task on a PXI-4204, 4 Counter tasks on a PXI-6602, 1 DI task on a PXI-6514, 1 DO task on a PXI-6514, 1 DI task on a PXI-6259, 1 DO task on a PXI-6259, 1 AO task on a PXI-6259 and 1 AO task on a PXI-6711.
The AI task on the PXI-4204 is running in Continous Sampling (Single Point HW Timed is not supported), all other tasks exept the DI and DO are Single Point HW Timed.
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Restarting counter in Timed Loop

I have a timed loop inside a state machine, used to start/stop a data acquisition sequence.
It works fine, but I'm monitoring the "i" count and Actual End [i-1] values and after the start/stop/start sequence
these values continue to grow and don't get reset to zero. I would expect a While Loop to reset the "i"
variable every time is is called, but I don't see any option for resetting the time looped.
I can get around it, but I would expect a reset method for this loop, so I'm just wondering if I'm missing something.
Maybe I need to use "Create Timing Source" instead of the setting it iin the dialog box?
Labview 2010f1 on Windows Vista SP2 PC

This might help. Here is a part of the png file you posted. I put in "Structure Name>" to point to the Structure Name input. Notice that the name "bob" is listed as the Structure Name. You must be on Win7 which uses different fonts than XP - that's probably why the name is only half visible.
Note that the Clock name is connected to the (timing) Source Name input.
I'm attaching an updated version of the file with the Timing Loop name wired directly.
Thanks for posting your timed loop interations3 program in 2009. When I run this code, the Iteration Count DOES reset when the Timed Loop is restarted.
steve
Help the forum when you get help. Click the "Solution?" icon on the reply that answers your
question. Give "Kudos" to replies that help.
Attachments:
New timed loop interations.vi ‏42 KB

What determines Finished Late? flag in timed loop?

I've monitored the Global Start Time (and Iteration Start) from iteration to iteration in a real-time loop. These delta time between iteration starts varies beyond my loop rate (e.g. 1680 usec between iteration starts with a 1666 usec period), yet the Finished Late? flag does not indicate true. Maintain Phase is TRUE, Discard Missed Periods is FALSE, Deadline and Timeout are default (-1). So why does Finished Late? not fire when all clocks tell me the loop was late?

A (very) rough example is below and some results (run on an RT controller). I guess the loop didn't "finish late" but it appears that they can (and usually do) start (significantly) late or early so am I missing something? This jitter is there even when the Chart and Stop button are removed from the timed loop (e.g. using RT FIFOs to send the data to a chart loop). To some extent I answered my own question - my loops are not "finishing late" so the flag isn't set, but apparently the jitter here is significant. In this simplistic example, I saw jitter of +/- 4 ticks (usec) when the CPU usage is at barely 1% per core (dual core) - so is the RT jitter just bad in general or is it the 1Mhz clock or ???
Attachments:
RT Loop Timing.png ‏8 KB
RT Loop Timing Graph.png ‏14 KB

Using Timed Loops

I am trying to use a timed loop in my application. The only timing source available is the 1Khz clock on the CPU. I am using a PXI-8176 CPU in a PXI-1045 Chassis. I have found that the timed loop using the 1 kHz clock is not very accurate. When comparing the loop time versus a reference clock it lags by approximately 6 seconds in a 12 hour period.
Is there a way to use the 10 Mhz reference clock available on the PXI bus?
I have also tried using the counter on a PXI-6031E card but have not had much success.

I am trying to configure the timed loop to utilize the counter on a DAQ Card in lieu of the 1Khz clock on the CPU. I have included a vi demonstrating how I plan to implement this strategy.
I have also found that if a timed loop configured to process missed iterations is stopped and placed in an idle case, it will continue to count iterations based on its period and when made active again will process the missed iterations. Is this normal?
Attachments:
DAQmx Config for Timed Loop.vi ‏94 KB

Can I run a fast timed loop?

It appears that a timed loop cannot run faster than 100 hz. In other words, the "period" input for a timed loop cannot be less than 10. Is this true? I am using the Elapsed Time VI to measure time increments. The time increments output from this VI are at least 0.01 secs regardless of how fast I attempt to run the time loop. Perhaps the limitation lies in the Elapsed Time VI, not in the Timed Loop. Should I try a different approach to measuring the delta time between iterations of a time loop? TIA.
-jlivermore

Here's the simple way to measure loop timing:
Actually, what else is running in your loop (e.g. property nodes, DAQ, etc.)? Can you show us your code? What is your LabVIEW version?
Message Edited by altenbach on 09-29-2008 11:22 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
MeasureLoopTiming.PNG ‏7 KB

Using timer/counter with PCI-6221/USB-6210 to control timed-loop VI

Dear all,
I need to ask about two devices and one of their functionalities, PCI-6221 and USB-6210. For our NI-based system, we need to control some timings in a Timed-Loop vi, for that currently we are using PCI-6221 and we give external TTL signal (at 1 kHz) to it,
recenntly we need to make some changes and for that we found USB 6210 DAQ to be more suitable, but we need to clear ourselves on some specific things.
Can the counter/timers functions available in the either PCI 6221 or USB 6210 can be used to control the Timed-loop VI by giving external clock or by using their own internal clock source?
Although we are using external clock with the PCI 6221 but we want to know about the usage of their internal clock, also are controlling timed-loop also possible for USB-6210
Also... What if we use the RTOS, are they still able to control the timed-loop VI without giving any 'EXTERNAL CLOCK' and using the internal clock sources of the DAQs
Waiting for reply,
Bests,
RaJaf
Solved!
Go to Solution.

Ben,
I having read previous email which I send earlier with general overview, we discussed in more detail within our team and I am giviing the specific answers.
Please check in RED the most recent answers. Blue are the questions/suggestions by your side.
1.    Using Internal hardware clock of PCI-6221 would enable us get rid of external clock, but how to divert the internal hardware clock to the current settings. Any idea (can you provide us with some reference manul for otherwise). I mean is there some flag-bit etc. or VI
2.       Is it also meant that with the installation of RTOS the timed-loop can directly get the timing source from the internal hardware clock PCI-6221? --- How???
3.       In order to make desktop to work as RT system, what is the hardware (motherboard, processor, etc..) requirement? What are the LabVIEW modules (specific name) that needed to be installed? Our platform is LabVIEW 8.6. (Currently we have windows-7 with i7 core processor)
What kind of application are you intending for this system? ---- high-speed laser scanning system.
Are you most concerned about accuracy, speed, or responsiveness? To control the laser mirror scanner to move at 1 kHz or 2 kHz speed. On the other hands, using PCI-5105 (128 MB memory) as a DAQ for real-time/on-the-fly data processing.
Bests,
RAJAF

Memory leak in Real-Time caused by VISA Read and Timed Loop data nodes? Doesn't make sense.

Working with LV 8.2.1 real-time to develop a host of applications that monitor or emulate computers on RS-422 busses. The following screen shots were taken from an application that monitors a 200Hz transmission. After a few hours, the PXI station would crash with an awesome array of angry messages...most implying something about a loss of memory. After much hair pulling and passing of the buck, my associate was able to discover while watching the available memory on the controller that memory loss was occurring with every loop containing a VISA read and error propogation using the data nodes (see Memory Leak.jpg). He found that if he switched the error propogation to regular old-fashioned shift registers, then the available memory was rock-solid. (a la No Memory Leak.jpg)
Any ideas what could be causing this? Do you see any problems with the way we code these sorts of loops? We are always attempting to optimize the way we use memory on our time-critical applications and VISA reads and DAQmx Reads give us the most heartache as we are never able to preallocate memory for these VIs. Any tips?
Dan Marlow
GDLS
Solved!
Go to Solution.
Attachments:
Memory Leak.JPG ‏136 KB
No Memory Leak.JPG ‏137 KB

Hi thisisnotadream,
This problem has been reported, and you seem to be exactly reproducing the conditions required to see this problem. This was reported to R&D (# 134314) for further investigation. There are multiple possible workarounds, one of which is the one that you have already found of wiring the error directly into the loop. Other situations that result in no memory leak are:
1. If the bytes at port property node is not there and a read just happens in every iteration and resulting timeouts are ignored.
2. If the case structure is gone and just blindly check the bytes at port and read every iteration.
3. If the Timed Loop is turned into a While loop.
Thanks for the feedback!
Regards,Stephen S.
National Instruments
Applications Engineering

Why do we lose counts through a timed loop?

I have written a program to count the rising edges of a square wave produced by a function generator using the DAQmx functions. The counter is read in a time loop with a period of 1 second, so we take a sample once every second. It appears that the program is working correctly accept for the fact the the counts are continuously 2% lower than they should be. We are guessing that this is due to the fact that the timed loop really isn't taking a full second to complete each iteration. Any suggestions on how to fix these timing errors? The counters are read from the NI 6608 Device if that is of any help.

Please post images of your code so that we can be off assistance.
Thank you,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Timed Loop in Shared Lib caused LabWindow program to NOT exit

I have a shared Lib created in LabView that I call from LabWindows. If I create a VI with nothing but a Timed Loop and no other code, my Labwindows program will not terminate. (Even if I don't call the library function (VI) containing the Timed Loop).

I have a conditional that after 3 iterations, the loop is terminated. (tied to stop)
The timed loop is empty.
The timed loop is definitely the cause of LabWindows not terminating.
I have attached a sample of the problem.
Attachments:
Timed Loop.zip ‏67 KB

Strange DAQmx Timing Source Timed Loop Error

I have a digital edge counter fed into a timed loop. Everything works fine until I stop the loop, and stop the DAQ task. Once I restart the loop it fails with "resource is reserved". Attached is my code.
Thanks
Solved!
Go to Solution.
Attachments:
daqloop.JPG ‏136 KB

Here is a piece of code to illustrate the issue. If the timing source is created in the loop (it will be created each loop iteration) the error occurs. If it is moved outside the loop, and only created once the issue is resolved. Is there a way to RELEASE the timing source so that it can be created again? If the VI is stopped, this "resource" is released. I want to programatically release it.
Note the error comes from the timed loop Error terminal that is Probed (50).
Message Edited by bkb on 10-08-2008 09:52 AM
Message Edited by bkb on 10-08-2008 09:53 AM
Attachments:
ts.jpg ‏57 KB

Timed loop in LabVIEW DLL does not exit nicely

Hello! I have what I think is a simple timed loop in LabVIEW that exits after 100 iterations by throwing an error, and letting the loop "stop on error". This works fine when run in the regular LabVIEW environment, however, when compiled as a Dynamic Linked Library (DLL) and called from LabWindows it forces me to terminate execution, rather than exiting nicely. What's more, it seems to quit the actual Virtual Instrument call just fine and proceed to the next line of code, but when my main() function in LabWindows completes there must still be something not cleaned up that is causing it to not exit nicely. Any ideas?   I've tried adding a call to QuitLabVIEW and that doesn't seem to do it.
Thanks in advance - hoping you'll point out some really easy mistake. )
Attached is a picture of the timed loop.
Below is an excerpt of code from LabWindows:
int main ()
CallMyLabVIEWDLL(); //This line successfully launches and closes the window for my LabVIEW virtual instrument
MessagePopup ("My Title:", "This happens after the call to your LabVIEW DLL");    //This popup shows up - indicating the call to the DLL has completed
//But after the code has completed LabWindows still says "Running", rather than shutting down.
    return 0;
Solved!
Go to Solution.
Attachments:
LabVIEWTimedLoopDoesntExit.png ‏103 KB

Update: I tried the simplest possible "While" loop and it works. If I replace it with the simplest possible Timed Loop, it doesn't. (See attachments.)
The only thing I could find in a search for why a time loop would break a dll is a patch for lvalarms from LabVIEW 8.5.1 .... I'm running LV 2010 so I don't believe that's an issue. Correct me if I'm wrong?
Thank you!
Attachments:
Doesnotwork.png ‏43 KB
DoesWork.png ‏9 KB

Missed iterations of TTL triggered timed loop

Similar Messages

Maybe you are looking for