LabVIEW
Populating an Array with measurements
- Do not maximize the front panel and diagram to the screen
- Your VI uses 100% of a CPU core when not doing anything, spinning the loop as fast as the computer allows (would drain the battery quickly on a laptop!).
- It would probably make more sense top open the VISA session once at the beginning outside the loop and close it after the program has completed. Creating and closing a VISA session every nanosecond (even in idle mode) seems ill advised.
- You have a lot of duplicate code (e.g. all the VISA "trains"). Once instance of that code is probably sufficient.
- Instead of stacks and stacks of case structures and while loops, use a proper state machine (one loop, one case structure)
- In the middle you build an array with two elements and immediately index out the second element. Wouldn't it make more sense to just branch from the scalar wire?
- There is an "in range?" function, that could replace both comparisons.
- You are way overusing local variables.
- What's the purpose of the last inner FOR loop with the uninitialized shift register?
- There are scenarios where your inner loops will never stop (e.g. if there is a VISA error).
- Which array are you trying to populate?
To append to an existing array with each iteration of the outer loop, the shift register containing the array needs to be anchored to the outer while loop and initialized with an empty array of the right type. Use "built array" to append the new value to the existing array. Don't use inner loops for that. Of course if you are just incrementally writing to an existing file, you don't need to build any array. Open the file once, keep appending whenever needed, and close the file at completion of the program.
If I open your VI on my system. both front panel and diagram fill my entire monitor. I prefer a defined size instead.
If you have unwired output tunnels, you need to make sure to wire the value across in the other case(s) unchanged.
altenbach,
Thanks for your reply. Just to be sure I am understanding you correctly, please see the following:
If I am understanding you correctly, this is what you were describing, correct?
This does pass the previous measurement to the next element in the array. However, with this configuration, the number of elements in the array is determined by how many elements the build array is stretched to. Is there any way to control the number of elements by an input of some sort? This size of this array should be determined by the number of parts on a given panel, which depends on the specific part.
The intention is to take measurements for one panels worth of parts, then write those values in a single row of a CSV. Panel 2 would be line 2 etc.
When it comes to a defined size, am I correct to think you are speaking of Window Appearance under VI Properties?
I expect what was meant is probably something more like this:
Here, the array is on the shift register (it is the thing passed from iteration to iteration) and each iteration, a new element (here a random number) is added to the end of the array.
@TAmbriole wrote:
Is there any way to control the number of elements by an input of some sort? This size of this array should be determined by the number of parts on a given panel, which depends on the specific part.
The intention is to take measurements for one panels worth of parts, then write those values in a single row of a CSV. Panel 2 would be line 2 etc.
In terms of controlling the number of elements, it sounds like you might prefer a For loop (rather than a While loop). A For loop has a specified number of iterations, either by autoindexing an array or wiring a constant to the N in the top left.
The problem you might run into is that an array has to have the same length in each row, when it is 2D. That is, you can't build a 2D array and have some rows be longer than others. You could work around this either by using a special value (like NaN), or alternatively, by instead recording an array of clusters of an array.
In the latter case, you place each 1D Array into a Bundle node when you have finished building it, which creates a Cluster containing a 1D array. Then, you use Build Array on each of your resulting clusters, to form a 1D array of clusters of 1D arrays of doubles (or whichever datatype). Since your arrays are all 1D, they can have varying lengths. The second array is of single element clusters, which are fine. It might make your later calculations more complicated however...
I'll throw in a few more comments - I can almost see what you're trying to do, and it looks quite clever, but I think there might be a couple of logical holes that your planned sequence is falling through.
- Why are you reading the CSV in the outer loop? Is this for multiple tests, and you don't want to restart the VI?
- In the For loop, you only need to do what you're doing with the shift register if you actually intent to use the values. If you only need a suitably sized array, you can just auto-index 'i'. If you only need the number of iterations, you can wire the result to 'N'
- Assuming everything starts nicely, you get a value for N that is number of sites. Then, your loop is checking against the "Less than 999999" node to start the measurement. You touch the measurement points to the resistor, and it jumps to the true case (on the next outer while loop iteration, which will have read the CSV again, and again, and again by this point 😉 ). The value settles to R. R is passed from shift register to the second While loop (inside the For loop). This loop keeps spinning until you remove the measurement points, at which point the VISA reads an open value, and R is passed to the outer shift register. The first value, as you noted, is the default 0 (on subsequent runs it would be whatever came last - this is from the uninitialized shift register).
- The For loop now restarts. Because the 999999 check is OUTSIDE the For loop, it determines that 999999 is a stable value (or whatever you measure is stable) and quickly finishes both For loops, pushing out a value of the open resistance.
- The last iteration repeats the open measurement, but the values output are the ones at the beginning, not the ends of the iterations - hence (0, R, open), rather than (R, open, open).
- You can instead just wire the value (from the top of the 3 wires, currently connected to the shift register) to the outside of the for loop - this will remove the 0. However, it won't solve your issue with near instantly finishing the For loop making open readings.
As has been mentioned before, a State Machine might be better for you here. I've attached a VI below giving some possible state transitions based on how I understood your process. It's possible I've horribly misunderstood, in which case, apologies. I haven't worked out if I can backsave snippets (I don't think so...) and many users aren't using 2017 yet (and I don't have 2016 on this computer), so I didn't attach a snippet.
@cbutcher
You should look into installing the Code Capture Tool via VIPM
You can automatically backsave snippets
