timed loop issues

[g_bress]

Stall dataflow.vim would cause the filter loop to run and then start the CCD loop when the filter loop is done. That is not what I am looking for, I want the CCD loop to start WHILE the filter loop is running, but just delay its execution by 1-2 seconds compared to the start of the filter loop. I hope this helps...

[Bob_Schor]

---

@g_bress wrote:

Stall dataflow.vim would cause the filter loop to run and then start the CCD loop when the filter loop is done. That is not what I am looking for, I want the CCD loop to start WHILE the filter loop is running, but just delay its execution by 1-2 seconds compared to the start of the filter loop. I hope this helps...

---

What you describe (above) is two parallel paths, started at the same time.

• Path 1 -- "The Filter Loop".
• Path 2 -- "The "CCD Loop", delayed by 2 seconds.

I assume you are using the Error Line judiciously (meaning that almost all of your functions, sub-VIs, While Loops, etc. have a single Error Line running through them).  Take the Error Line that goes into the Filter Loop and branch it (I tend to stack Parallel Loops vertically, similar to the way an Event Loop is placed above a State Machine Loop, with a branched Error Line going into both of them).  On the Branch, put your two-second Delay (the Stall VIM can be placed on the Error Line) on the Error Line just before the CCD Loop.  

Voilà.  You have two Loops, running in parallel, but with the second loop starting 2 seconds after the first.

[I didn't include Pictures nor Code, as I hope the verbal explanation is sufficient ...].

Bob Schor

[g_bress]

thanks for the suggestion, that was my frist guess as well, the CCD vi does not take a error cluster input/output tho...

[UliB]

---

@g_bress wrote:

thanks for the suggestion, that was my frist guess as well, the CCD vi does not take a error cluster input/output tho...

---

You can connect 'Stall Data Flow.vim' to every wire. So use a wire which goes to both VIs (e.g. wire from 'Pattern Repetition' or 'N CEP').

[g_bress]

I realised the lab PC uses labview 2013, stall data flow.vim was not introduced yet so not an option. I had to stick to the 2 timed loop structures (with the filter loop running just once, i know...) with a used defined delay between them. See attached. This does not crash anymore and produces data, altough...

The problem I am facing now is that despite the filter and the CCD being triggered by the same 1 kHz sq wave signal, The CCD loop runs much slower than the filter loop. The filter loop is programmed to play a sequence of 72000 waveforms and it displays a progress bar while it is running. the CCD loop is programmed to iterate 120 times and acquire a burst of 600 spectra at each iteration. 

What happens is that when the filter progress bar gets to 100% i.e. all 72k waveforms have been played by the filter, the CCD loop iteration counter is only at 73 whch means that is is running 40% slower! I would like to point out that the same thing happens if I don't append the CCD spectra bursts inside the CCD timed loop, it is maybe slightly faster but still does not keep pace at all with the filter loop. I don't see how a producer-consumer structure would help here as the signal modulator and the signal detector are running at different speeds, so the problem is before data processing.

Suggestions welcome, thanks a lot!

[Bob_Schor]

A key element in a Producer/Consumer Design is the "communication path", frequently implemented by a Queue.

Assume that the Consumer can process the data in the Queue at least as fast as the Producer.  It may take the Comsumer some time to "get going" (it may need, for example, to open some files), but during this time, the Queue acts as a "buffer" to hold data while getting ready.  Even if the Consumer is slower than the Producer, if the Queue has enough capacity, it can trade "space" for "time" and still get the job done.

For example, assume the Producer is twice as fast as the Consumer.  Assume that data are produced at 1000 items/second.  If the process runs for 1000 seconds, then a million items will be put into the Queue, the Consumer will have removed 500 thousand of them, and will remove ("process") the remainder of the Queue in another 1000 seconds.  No data are lost in such a transaction.  Queues are designed to handle memory efficiently, so allow you to collect data without missing anything, using the Queue to "buffer" the data and save all of it (depending on the difference in speed between Producer and Consumer, and the amount of memory available to expand the Queue, which LabVIEW handles for you).

Bob Schor 

[g_bress]

I tried to stuff the output of the CCD in a queue which is dequed in a separate while loop which appends the CCD data into a single large (60k x 2400) 2D array ready for the processing. So the previous timed loop for the CCD reading and array appending is now split into two, connected by a queue.

Unfortunately, the execution speed of the CCD loop did not improve at all. Again, when the filter loop has played all the 600x120 waveforms it is supposed to, the CCD loop has only iterated 73 (out of 120) times, recording 600x73 spectra. 

I am starting to wonder if the PC i am using to control the experiment and acquire the data is not capable of keeping pace with these two processes at the same time...

[GerdW]

Hi g,

---

@g_bress wrote:

I had to stick to the 2 timed loop structures (with the filter loop running just once, i know...) with a used defined delay between them.

---

Why do you need to stick to TimedWhileLoops when they iterate at 1000ms intervals???

An ordinary WHILE loop with a wait inside will do the same. When you know the number of iterations before calling the loop you should stick with a FOR loop…

---

@g_bress wrote:

The problem I am facing now is that despite the filter and the CCD being triggered by the same 1 kHz sq wave signal, The CCD loop runs much slower than the filter loop. The filter loop is programmed to play a sequence of 72000 waveforms and it displays a progress bar while it is running. the CCD loop is programmed to iterate 120 times and acquire a burst of 600 spectra at each iteration.

---

I don't see any "trigger" in your image. (Keep in mind: we cannot debug/run/edit images with LabVIEW!)

I don't see any "progress bar" in your image! (I guess this will be that "x+1" indicator…)

Why is there a FOR loop around your sequence frame iterating exactly once? That's Rube-Goldberg!

Why is one of those TWLs dependent on the "FirstCall" function?

What's the point of that FOR loop to the right iterating "number of samples" times with exactly the same constant input data?

How long does your CCD subVI need to execute? Is it even able to finish within 1000ms?

[g_bress]

Dear Gerd,

after your comment I realised that what I was looking for was a timed structure rather than a timed loop, so I replaced the timed loops with timed structures keeping the same 1300ms delay between the filter structure and the CCD structure and (it looks like) it is doing what i wanted it to do.

Even if I shared the code with you you would not be able to see any trigger (as they are BNC cables connected to the hw) or any progress bar (as the code will not show it unless the filter hw is connected to the PC) all the first call crap was to execute a loop just once when what i needed was, in fact, a timed structure.