LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Loop problem

I'm using 2 ordinary for loops 1 after the other to capture upper and lower voltage thresholds. The problem is the second loop won't continue past the number the first loop stopped at even when I hard code a larger number. 

0 Kudos
Message 1 of 6
(2,833 Views)

Hi RHutchings,

 

you really should take the beginner courses to learn LabVIEW…

(Learn about FOR loop behaviour. Also learn about all those different loop tunnel options!)

 

The problem is the second loop won't continue past the number the first loop stopped at even when I hard code a larger number. 

Where did you "hard code" that behaviour?

Infact LabVIEW works exactly as is described in the help: A FOR loop has more than just one condition to define the number of iterations!

It will stop when

- the max number of iterations is reached

- the stop condition in the loop is fulfilled

- an autoindexing input runs out of elements

The last item is killing you… 😄

 

On your VI:

- Learn about replacing stacked sequences by flat ones.

- Then replace all locals by wires.

- Then remove the sequences and use pure THINK DATAFLOW!

- Learn about the formatting codes for FormatIntoString to remove RubeGoldberg code here…

- Remove the Classic RubeGoldberg of "IF true THEN true ELSE false"… 😄

- Why do you need to round down an integer number???

- Learn about "race conditions" and how to avoid them…

Best regards,
GerdW


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

Youre indexing the two arrays into the second for loop - the array of VISA Refs and the array of errors. If a for loop has an array that is indexed as the input and a loop count wired, the number of times it executes will be equal to the smaller of the two inputs. 

 

Get rid of that VISA ref array anyways - right click on the output tunnel of the first loop and click replace with shift register. Then put a 'merge errors' node on the error output of the first loop. 

0 Kudos
Message 3 of 6
(2,824 Views)

Thanks all, I'll get back after I've digested all of this. I have another project to work on for the moment. I'll look into the training.

0 Kudos
Message 4 of 6
(2,802 Views)

@RHutchings wrote:

Thanks all, I'll get back after I've digested all of this. I have another project to work on for the moment. I'll look into the training.


Reading GerdW's message, it would seem that you should probably "look into the training" before "another project to work on for the moment".  You really don't want to continue coding the way you are doing right now.  Best to nip those bad LabVIEW practices in the bud.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 6
(2,783 Views)
  • All you need is a simple state machine with fours states, one for each of your stacked sequence frames.
  • You don't need any of the local variables.
  • Gerd already mentioned race conditions. The most blatant here is that you calculate hysteresis right after the program starts and before the loops have even executed. You'll always get the stale value from the previous run. (execution order is determined by dataflow, not by placement on the diagram!
  • There is an "=0" primitive and a "+1" primitive.
  • You can wire the DBLs directly to the formatting statement after adding a proper format statement. Since all your strings are constant, they could be added to the format statement. All the formatting operation needs is the two DBLs and a proper format to get exactly the same result. (see picture, DBL format should be %.06f)
  • Your two loops share a lot of duplicate code that could be combined.

 

FormatRube.png

0 Kudos
Message 6 of 6
(2,775 Views)