LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

parallel while loops don't launch

Hi !

 

I have to build a program for a sensor's calibration process. This process can only be done when the sensors are stabilized.

For each sensor the program check if the sensor is stabilized, then it records the data which are saved in a spreadsheet file.

 

I have four while loops running :

 

- The first one receives the data from each sensor and post them in the front panel. I only care about three data for my test : T, Q and F, which I put in an array.

 

- The second loop does the stability test. If, for example, the sensor's temperature does not variate more than 0.3°C in one minute, then the sensor is said stabilised in temperature, and a led is put on (same thing for Q and F).

 

- The third one records a fixed number of stable points which it saves in another .xls file (if the sensor is stable, of course)  

 

- The last loop puts the data in a graph.

 

My problem is that the third loop ("Enregistrement des points quand le capteur est stabilisé") is never read by Labview.
I tried to create a RendezVous but it's never played.

 

How can I fix it ?

 

I cannot send the VI since it calls a hole bunch of other VI's, so you couldn't launch it anyway, but I send you the part that troubles me (sorry for the size, I didn't know how to make it smaller...)

 

Thank you for your answers ! Smiley Happy

 

PS : Sorry for my language, and the name of the variables, I'm only a French student... Smiley Sad

 

0 Kudos
Message 1 of 9
(3,114 Views)

I'm not sure about your third loop not running, but your architecture certainly needs some help.  An Event Strucutre inside of another Event Structure is just asking for problems.  And long actions do not belong in an event case either.  Look into seperating your GUI from the other loops.  Maybe you can just have all of those other loops running in parallel but waiting for commands via queues or notifiers.


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 2 of 9
(3,101 Views)

Thank you Crossrulz, I will look into that !

 

I agree, the architecture is far from perfect... I may have to think again about the process and use some state machine.

But, even only for curiosity, I don't see the problem in my case... Why does this loop refuse to start, no matter the size of the RendezVous ? 

0 Kudos
Message 3 of 9
(3,078 Views)

Have you tried running your application with "highlight execution" set?  That can show you where the VI is hanging up and preventing the loop from running as desired.

0 Kudos
Message 4 of 9
(3,064 Views)

Some suggestions on Style (which will also help a whole lot in improving your code).

  • Limit your Block Diagram to a single screen.  On my 1280 x 1024 monitor, I can see only about a quarter of your Block Diagram, which means I can't see the whole thing at once (and can't easily "trace wires").  If you have "lots of stuff" to put on the Block Diagram, bundle large chunks of it up into sub-VIs (which only occupy 32 x 32 pixels).
  • Never (Jamais) use a Stacked Frame Structure.  Tracing wires across frames is an exercise in frustration, as is having the same wire appear multiple times, in different places, on the edges.  If you want to repeat things, use a While or For loop with a Case Structure inside to "count the loops" -- this will let you use Shift Registers and have single copies of wires running in level trajectories.
  • Especially when starting out with Event Structures, use only one, and restrict it to handling Front Panel controls that change.  If you want to do something under another particular circumstance, we can suggest mechanisms (which might include the Event structure), but try to simplify your code structure.
  • It is not necessary to put everything in a single loop.  Indeed, one of LabVIEW's main benefits is that you can have multiple loops running in parallel, doing things more-or-less simultaneously.  Sometimes loops wait for something to happen (like a While loop that only has an Event structure), sometimes loops wait for a timer (like a loop with a Timed Wait), sometimes they wait for some data (like a Dequeue), sometimes they are driven by data (DAQ functions come to mind).

When your Block Diagram is clear enough for a colleague or acquaintance (say, on the Forums) to easily understand it, you will also better understand it, and can probably find the problem, yourself.  Strive for a simpler, more concise, style.

 

Bob Schor

Message 5 of 9
(3,055 Views)

Hi !

 

So I tried to solve the problem with a State Machine, but that didn't help very much : I still can't get into the upper loop...

Parallel loops

0 Kudos
Message 6 of 9
(2,980 Views)

THINK DATAFLOW!

 

Your loops don't run in parallel as you can easily see using Highlight debugging…

 

(And what's the point in stopping the lower right loop immediatly after calling it?)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 9
(2,969 Views)

Wires between loops are data dependencies.  So two of your loops cannot start until your first one is complete.  You need to use Queues, Notifiers, or some type of variable to pass data between your loops.


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 9
(2,948 Views)

When Nothing Seems to Work, this is often a good sign that you should rethink the problem.  Consider your original description:


 

I have to build a program for a sensor's calibration process. This process can only be done when the sensors are stabilized.

For each sensor the program check if the sensor is stabilized, then it records the data which are saved in a spreadsheet file.


This suggests the following Big Picture Design:

 

Producer/Consumer architecture, with the Producer taking repetitive measurements of your sensor and the Consumer being a State Machine that does the calibration.

 

What States suggest themselves for your Callibration algorithm?  Well, "For each sensor, the program checks if the sensor is stabilized".  [For the purpose of this discussion, I'm going to assume just 1 sensor -- you can generalize it as it fits your problem, namely deciding whether the sensors must be stable as a group or individually).  So your initial State could be "Initial Sensor Unstable".  In this State, you "do something" with the incoming data and use it to determine when to change States to "Stable Sensor".  Once you are in Stable Sensor, you do whatever you need to do with the (now-stable) Sensor data, i.e. write to file, plot, etc.  Do you need to ensure that the Sensor remains stable during the Stable Sensor State?  If so, add the test, and decide what State you want if it fails (do you want to go back to Unstable Sensor, or have another "Bad Sensor" State?).

 

Note that the Producer/Consumer pattern has been pretty well documented, with examples available as Project Templates (I think) with recent versions of LabVIEW.  You can also find numerous examples here in the Forums over the past month or so.

 

Bob Schor

 

 

0 Kudos
Message 9 of 9
(2,944 Views)