Using a boolean array to skip sections of code (expandable design).

[J.Mamakos]

I currently have four pieces of code (which could turn into 5, 6, or more pieces in months to come), which I want to execute or selectively skip according to a boolean array.  I have a typedef cluster of numbers, each of which refers to a VISA port number that a particular instrument is connected to.  This will be expanded upon in future as the software is required to control more instruments.  There is a boolean array (coming from the attached vi) that holds a TRUE for each instrument that has been detected (and so is connected).  In the case shown below, I want to initialize each instrument that is connected, but not try to do anything to those that aren't.

The cluster and boolean array is shown below:

Since someone will need to expand on this section of code in the future, I want to write it in a way that will be infinitely expandable without taking up more and more BD space.  At the moment I find myself unable to do this since I don't know how to pair up the boolean array with the cluster elements such that I can execute or skip code accordingly.

Please help!

- James

[Florian.Ludwig]

Hi,

why not make the cluster of Visa ports an Array of Visa ports instead - that should let you line up the Visa information and the Boolean information just fine.

Regards Florian

[Mark_Yedinak · Accepted solution]

Since you mention that you would like to expand I would be more inclined to define an instrument cluster which would contain the port number, instrument type and status of the instrument. When searching for your instruments you would iterate over the array. You could use an ini file to define which instruments must be present in the system. Others may be optional and actions associated with them could be skipped if necessary. The primary point I am trying to make though is to combine your status array with your instrument information. This way you eliminate the possibilty of an error trying to keep and array and a cluster synchronized. An array also makes it much easier to add or remove instruments in your system.

A few other notes, if you are checking for a stop condition then stop. Don't just continue execution of every loop iteration with a case structure that will skip execution if the stop consifition is met. Simply stop. Imagine if you had 1000 elements in your instrument cluster/array. Using your methodology you will always execute your loop 1000 times, even if the stop occured during the first iteration. Eliminate duplicate code and screwy logic to control it. You have two places prompting th euser if they wish to retry or stop. You should only have one place to do that code. Much easier to understand and maintain. Your code doesn't expand easily either because of the hardcoded error strings. Your case statement will get quite large if you build your error strings statically. Use a loop and a common format you build your missing instrument string. If you use the array of instruments clusters as I suggested you will be able to format the string using the instrument type. I would be much more inclined to use a single notifier that will support both the cancel and the stop messages. This scales much better when you have additional message types rather than using a notifier for each message type.

[J.Mamakos]

---

@Mark_Yedinak wrote:

Since you mention that you would like to expand I would be more inclined to define an instrument cluster which would contain the port number, instrument type and status of the instrument. When searching for your instruments you would iterate over the array. You could use an ini file to define which instruments must be present in the system. Others may be optional and actions associated with them could be skipped if necessary. The primary point I am trying to make though is to combine your status array with your instrument information. This way you eliminate the possibility of an error trying to keep and array and a cluster synchronized. An array also makes it much easier to add or remove instruments in your system. This is very true, and building the arrays/clusters this way round actually makes another part of my code easier too. 

A few other notes, if you are checking for a stop condition then stop. Don't just continue execution of every loop iteration with a case structure that will skip execution if the stop condition is met. Simply stop. Imagine if you had 1000 elements in your instrument cluster/array. Using your methodology you will always execute your loop 1000 times, even if the stop occurred during the first iteration. In LabVIEW 8.5 I don't think I have a robust way of terminating a FOR loop mid-execution. The rather messy solution of enclosing everything within the FOR loop in a case statement to stop anything happening in further iterations after the 'stop' command is given was the only solution I could come up with. Is there another way I can do this better?

[...] Your code doesn't expand easily either because of the hardcoded error strings. Your case statement will get quite large if you build your error strings statically. Use a loop and a common format you build your missing instrument string. If you use the array of instruments clusters as I suggested you will be able to format the string using the instrument type. Shameful admission: I've never quite managed to get my head around the string format syntax. Would you be able to provide an example of how to insert an array element (instrument name) into a string using them? 

I would be much more inclined to use a single notifier that will support both the cancel and the stop messages. This scales much better when you have additional message types rather than using a notifier for each message type. After having problems trying to use just one notifier, I settled for two. The "Stop?" notifier automatically feeds into the "Loading Bar.vi" whilst the "Cancelled?" notifier is from a user input and goes in the other direction. I was having interference trouble when I tried to combine them into a single two-way notifier. Is there a way to combine them?

---

[crossrulz]

---

@James Mamakos wrote:

[...] Your code doesn't expand easily either because of the hardcoded error strings. Your case statement will get quite large if you build your error strings statically. Use a loop and a common format you build your missing instrument string. If you use the array of instruments clusters as I suggested you will be able to format the string using the instrument type. Shameful admission: I've never quite managed to get my head around the string format syntax. Would you be able to provide an example of how to insert an array element (instrument name) into a string using them? 

---

They aren't really that hard if you stick to the basics.  %s is for a string.  So you can use the Format String with a format of "Error at %s".  And input string of "blah" will give you a result of "Error at blah".  Perform this inside of a for loop with a shift register to append all that you need.

As a sort of an asside, the other specifiers to really know are %d and %f, which are decimal number and floating-point number.  I also use %x a lot which is hexidecimal number, but stick to the simple 3 until you get more comfortable with it.

[Mark_Yedinak]

If you need to stop the loop early don't use the for loop. Use a while loop. The only down side there is that you need to put a single test before the loop to prevent execution if the array is empty.

[J.Mamakos]

Thank you for your suggestions.  I will get back to you if I have any further problems with this.  

[elset191]

---

@Mark_Yedinak wrote:

If you need to stop the loop early don't use the for loop. Use a while loop. The only down side there is that you need to put a single test before the loop to prevent execution if the array is empty.

---

Why not use the for loop with conditional terminal enabled?

Nevermind.  I should read the thread before replying.

[crossrulz]

---

James Mamakos wrote

In LabVIEW 8.5 I don't think I have a robust way of terminating a FOR loop mid-execution. The rather messy solution of enclosing everything within the FOR loop in a case statement to stop anything happening in further iterations after the 'stop' command is given was the only solution I could come up with. Is there another way I can do this better?

---

Lo and behold.  The Conditional Terminal for the FOR loop IS available in LV8.5!

http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/add_cond_to_for_loop/

EDIT:  After a little more searching, I found that the Conditional Terminal for the FOR loop was introduced in 8.5.  http://zone.ni.com/reference/en-XX/help/371361D-01/lvupgrade/labview_features/

[J.Mamakos]

---

crossrulz wrote:

Lo and behold.  The Conditional Terminal for the FOR loop IS available in LV8.5!

http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/add_cond_to_for_loop/

EDIT:  After a little more searching, I found that the Conditional Terminal for the FOR loop was introduced in 8.5.  http://zone.ni.com/reference/en-XX/help/371361D-01/lvupgrade/labview_features/

---

Thank you very much for discovering this!  I was using 6.1 before, and it wasn't immediately obvious that the Conditional Terminal (that I'd seen in later versions) had been added yet.  I've now reverted my FOR loop back to a FOR loop after modifying it to use a WHILE loop.  It was a nice little exercise none-the-less!

I've made the changes suggested in this thread, and have coded the result.  My main loop's "Instruments: Initialize" case now looks like this:

Does it matter that I can't automatically populate the cases in the lowest level case structure?  It's not much extra hassle to type in the Instrument Type, and it does seem to work (as long as I spelt it correctly).

I've also attached the now modified "Check Visa Connections.vi" and "Loading Bar.vi".  When refactoring the code, I also squished a couple of potential bugs I hadn't noticed before!  Can you see any glaring mistakes or further problems in them?  If not, I'll assume a job well done and leave them be.  

- Kossa