LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timing issues with parallel while loops

Hi,

 

For my project I need three while loops to run in parallel, but I'm having a timing issue.
One of my loops doesn't want to run most of the times. Sometimes it'll randomly work, which makes this problem so weird. It's about the Data Acquisition loop, it's like it almost doesn't get triggered. I thought I was maybe overloading the CPU, so I put a Wait function on the main loop, so it won't run as often. But that doesn't seem to have fixed anything.

So it must be a timing issue, that the loop never gets triggered to run. Could someone help me?

Thanks in advance!

 

EDIT: I should also add: Whenever I run the vi while highlighting execution the Data Acquisition loops works perfectly fine.

0 Kudos
Message 1 of 12
(3,206 Views)

hi there, you should have a wait-ms in every loop, wire at least a 0 so the thread yields the cpu

https://zone.ni.com/reference/en-XX/help/371361H-01/glang/wait_ms/

 

 should've looke at your vi beforehand ... seems you do already

 

also: it is bad to have VI terminal outputs on the left side! don't do that, it messes with the data flow (only visually, but nevertheless you should refrain from that) (Input Sensor.vi)

 


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 2 of 12
(3,198 Views)

I googled around and found that somewhere aswell, but that didn't help either.

0 Kudos
Message 3 of 12
(3,188 Views)

then i'd say the "Data Acquisition.vi" seems to be the culprit.

 

EDIT: also reduce the period of your timed loop, do you really need to execute every 10000ths of a second?

EDIT2: in fact get rid of that timed loop altogether, change it to a normal loop, and have a wait of 10ms in it, to troubleshoot it


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 4 of 12
(3,184 Views)

Hi,

Before I added that timed loop everything worked perfectly, so I can't imagine it's the Data Acquisition part.

And with that timed loop I need to measure frequencies of up to 150-200Hz, by measuring the amount of time inbetween each high pulse. So the faster it runs the more accurate it will be, but I reduced the timing on that timed loop and then nothing really changed.

 

EDIT: changed it into a normal loop, nothing changed. It's purely since there are 3 loops instead of 2 that the problem arised.

0 Kudos
Message 5 of 12
(3,171 Views)

strange.

 

try to build a mockup, 3 loops, instead of your subvis have some sensible wait function, see if the one of the loops still doesn't execute.


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 6 of 12
(3,157 Views)

That works perfectly fine, so that can't be the problem.

0 Kudos
Message 7 of 12
(3,154 Views)

I don't even see a reason to have 3 loops here.  Your two bottom loops take in data directly from the main loop.  So I would just combine it all into a single loop, eliminating those local variables which are likely causing race conditions.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 12
(3,148 Views)

You mean combine the two bottom loops?  I want the Data Acquisition loop to run once every half second, and I want to run the Counter loop as fast as possible, but i want to know the speed, so I can use it for my calculations. Would that be possible to put in one loop together?

0 Kudos
Message 9 of 12
(3,144 Views)

Your timed loop is configured with a 1 MHz clock, and your dt is set to 100, meaning that you are attempting to execute that loop with a period of 100 nanoseconds.  That is simply too fast to be polling controls (which incidentally, you should avoid doing at all).  Polling can work in very simple VIs, but I wouldn't attempt to do this at any rate faster than 100 ms.  Instead, use events to handle your front panel interactions, and instead of using local variables to share data between loops, use queues, channel wires, or functional global variables.  Every time you read from a local variable, you create a memory buffer to contain a copy of that data.  Local variables are a shared resource, and since your timed loop executes at a higher priority than your while loops, and is attempting to execute 10,000 times per second, it is monopolizing those resources and not permitting your while loop processor time to execute.

 

0 Kudos
Message 10 of 12
(3,114 Views)