Help with how to write a loop!

[laps682]

Hello, I tried looking through the forums but I wasn't sure how to word my problem.

I have attached a screenshot of a while loop; basically what I want is for that loop to write the "Temperature 1" double value into "String" and "Time 1" into "String 2" and then wait for the value of "Time 1" before the next iteration of the loop. In the next iteration of the loop, the same procedure should be performed but for Temperature 2 and Time 2 and so on and so forth until all the iterations are finished. What is the most efficient way to design such a loop? Do I make an array of these time values and somehow feed that into a "wait" function? Any help is appreciated, thank you!

[crossrulz]

1. Since you know the number of iterations, use a FOR loop.

2. I recommend making arrays with your iteration parameters and autoindex on the arrays.  This just makes things so much easier for everybody (the compiler, the coder, the one who will have to debug later).

3. If your waits are fairly short (a second or less), just use the Wait (ms) function.  If you are waiting longer, then you might want a wait within a loop that you can abort (and also abort the FOR loop).

[Bob_Schor]

 You attached a rather large VI, with a Front Panel of about 2200 x 1200 pixels and a Block Diagram of about 2500 x 2500 pixels.  In addition, several of your Front Panel items are "hidden" behind others.  Very difficult to "see" and understand what is going on.

The Block Diagram shows multiple parallel loops with no clear indication of how (or if) they interact.  There are also several "naked" Case Statements that will run once.

I didn't find the code referenced in the Original Post.

There are two parallel loops apparently "competing" for the same VISA Resource.

I have a colleague who describes his LabVIEW Coding Style as "Short-order Cook -- I just throw down LabVIEW code as fast as I can, not worrying about clarity or design".  My comment usually is "What do you want to do?  Don't worry about how to do it, but start with the Big Picture".

Learn about Sub-VIs and "hiding the Details" -- a 32 x 32 pixel sub-VI with an Icon that says "Open VISA Chan" saves Real Estate (and makes the Block Diagram much easier to read/understand).  Similarly, think about encapsulating your Tasks into sub-Tasks.

As you described what you wanted to do in your Original Post, it seemed (to me) easy to implement.  However, I couldn't find where this was in your code.

Bob Schor

[laps682]

Sorry I forgot to attach the screenshot: it is attached now. The case files only need to run once to initialize some values. I apologize about the messiness with the front panel I was just expecting help with the screenshot section I attached but of course I will utilize sub VI although I am still learning about it as I'm not that experienced. With the VISA Resource, I had no idea how I should be wiring them. I want one loop to continually write something to that resource while another loop writes another thing how should I organize that. Do you have any recommendation for a clear guide of actually how to save, where to store sub VI, how to make one? I see all these resources online but they are honestly not that clear about the start to finish process of making one...

[crossrulz]

---

@laps682 wrote:

I want one loop to continually write something to that resource while another loop writes another thing how should I organize that.

---

Not a good idea to have multiple loops have access to a resource.  You might want to look into a Queued Message Handler (QMH).  The idea is you use a queue to send messages to a loop that maintains the resource and reacts to the messages it is given in a FIFO.  This keeps conflicts from happening.

---

@laps682 wrote:

Do you have any recommendation for a clear guide of actually how to save, where to store sub VI, how to make one?

---

Go to the LabVIEW board.  Towards the top, there are several links for tutorials.  If you have a valid SSP, I highly recommend you go through the "Online Training" and go through LabVIEW Core I.  Then go through Core II.  Most of your questions will be answered in those two courses.

[laps682]

---

@crossrulz wrote:

1. Since you know the number of iterations, use a FOR loop.

2. I recommend making arrays with your iteration parameters and autoindex on the arrays.  This just makes things so much easier for everybody (the compiler, the coder, the one who will have to debug later).

3. If your waits are fairly short (a second or less), just use the Wait (ms) function.  If you are waiting longer, then you might want a wait within a loop that you can abort (and also abort the FOR loop).

---

Hello the autoindex with arrays sounds like a good idea. So for an example, there would be 5 iterations maybe about 45 minutes each. Why is it not ideal to use the Wait function for something longer than a second? Also could you explain a little more what you mean by "wait within a loop that you can abort", as I do not want any manual controller to tell when to switch to the next iteration; I want after 45 minutes for the next iteration to move on so would couldn't I just use autoindexing through an array and set Wait to 45 minutes?

[Bob_Schor]

Crossrulz can probably say this better, but suppose you decide after 2 minutes that "something isn't right" and want to stop the loop, abandon the remaining 43 minutes of waiting, and "do something else"?  You basically cannot, since the Wait function still has another 43 minutes to run.

However, you could set up a For Loop with a conditional Stop, set it for value of 45*60 = 2700 (seconds), and inside the For loop have a 1000-ms (1 second) Wait.  This loop will Exit when 45 minutes elapses or you push the Stop button (maybe you should label the button "Abort" or "Quit").

Bob Schor

[laps682]

Ah that makes a lot of sense from a good design perspective.. thank you!

[billko]

---

@Bob_Schor wrote:

 You attached a rather large VI, with a Front Panel of about 2200 x 1200 pixels and a Block Diagram of about 2500 x 2500 pixels.  In addition, several of your Front Panel items are "hidden" behind others.  Very difficult to "see" and understand what is going on.

The Block Diagram shows multiple parallel loops with no clear indication of how (or if) they interact.  There are also several "naked" Case Statements that will run once.

I didn't find the code referenced in the Original Post.

There are two parallel loops apparently "competing" for the same VISA Resource.

I have a colleague who describes his LabVIEW Coding Style as "Short-order Cook -- I just throw down LabVIEW code as fast as I can, not worrying about clarity or design".  My comment usually is "What do you want to do?  Don't worry about how to do it, but start with the Big Picture".

Learn about Sub-VIs and "hiding the Details" -- a 32 x 32 pixel sub-VI with an Icon that says "Open VISA Chan" saves Real Estate (and makes the Block Diagram much easier to read/understand).  Similarly, think about encapsulating your Tasks into sub-Tasks.

As you described what you wanted to do in your Original Post, it seemed (to me) easy to implement.  However, I couldn't find where this was in your code.

Bob Schor

---

This is an insult to short-order cooks  ;).  If you watch carefully, everything is extremely well-planned and organized.  It just happens with such efficiency that you can't really follow what's going on.  How else do you think they get everything to finish cooking at the same time?

[Bob_Schor]

---

@billko wrote:

---

@Bob_SchorThis is an insult to short-order cooks  ;).  If you watch carefully, everything is extremely well-planned and organized.  It just happens with such efficiency that you can't really follow what's going on.  How else do you think they get everything to finish cooking at the same time?

---

I'm sure my colleague did not mean to insult short-order cooks -- it was his metaphor (admittedly poorly chosen) for "don't think about what you are doing, just get it done as quickly as possible, no matter how messy or disorganized it is".  If you iterate this a few times ("Oops, I need to add this functionality, and then save it to disk, but I better make sure that the file name includes the date and time the file was written along with the initials of the User, oh, and let's do two other unrelated tasks"), you get that Ultimate Dish, Spaghetti Code (which, given LabVIEW's colored wires, can actually resemble spaghetti).  A little planning, judicious use of sub-VIs (with icons!) to encapsulate function and "hide messy details", and attention to good LabVIEW "Style" (see Peter Blume's "The LabVIEW Style Book") make for LabVIEW code that is much easier to comprehend, maintain, debug, and reuse.

Bob Schor