Exiting loops prematurely

[IBAHKA]

Hello,
This is a logical question. I've been sitting in front of this problem ALL DAY and I am stuck! So I have posted a piece of my program, hoping that someone has experienced this in the past.

My question is about leaving a loop before it finishes all its tasks. Like an emergency stop.

please see attached file.

My brain and I thank you!

Ivanka

[Dennis_Knutson]

Your VI is extremely hard to read. You've commited an awful of style recomendations. You have an awful lot of hidden wires, wires going backwards, etc. It's just about impossible to tell where you have most of the case statments wired because of these problems. That being said, you're going to have to make some major changes. The simplest solution is to create a separate while loop that would just set a local variable called terminate. Then in each while loop, add a read of that to each terminate condition. You would do that by ORing the normal terminate condition with the local variable being true. You'll probably need some more logic to skip displaying the dialog boxes you have. You should also know that one of the downsides of sequence structures is that they always execute every sequence. You cannot just jump from sequence 1 to the end. Making use of event structures and a state machine architecture would give you a more flexible, easier to maintain, and easier to read program.

[altenbach]

I fully agree with everything Dennis said. Implement an event driven state machine without sequences should be much simpler.

A few other problems I would like to point out.

- Your tab terminal is outside the loop and this will only be read at program start. Is that what you want?

- The inner case structure contains 7 cases with nearly identical code (and probably nearly identical subVIs!) and each case duplicating basically the same controls and indicators on various tabs. It would seem to me that the core of the code needs to exist exactly once. I am sure it would be much simpler to only retain one control and indicator each and move the unique set outside the tab structure. Write the inner code in a re-usable way and you can eliminate 6/7 of it! You'll only need a small case structure containing the items that are truly different. Your duplicate design is also a problem with code maintenance. Every code change must be applied in seven different locations!

- You seem to impose very strict rules on the sequence of user inputs with a series of loops that do nothing but check input as fast as they can, consuming all CPU while writing the same identical properties over and over again. Almost every of your inputs requires two operations: (1) setting a value and (2) pressing a "choose .." button. Why so complicated? You can eliminate 50% of all remaining controls right here! (Including all the micro-management of enabling/disabling controls.
Your inner loops have no reason to exist at all. Get rid of them and your original problem is solved.

- It is much less frustrating to the operator if he can set all controls in random order by simply adjusting the controls. If a certain action requires that other controls are in a valid state, they can be disable until all is fine.

- Instead of writing value properties, use local variables. It's more efficient.

[IBAHKA]

Thank you Dennis and Altenbach for your suggestions.

I will look into changing the sequence loop to a case structure. The other suggestions made by altenbach cannot be used, because the program must be so controlled. Each following input is controlled by teh previous control's input.

Thank-you!

[altenbach]

---

IBAHKA wrote:The other suggestions made by altenbach cannot be used, because the program must be so controlled. Each following input is controlled by teh previous control's input.

Thank-you!

---

IBAHKA,
A state machine can do exactly that. There is no need to duplicate all that code. For example if one state is to input a certain control, it can, once finished, force the state that accepts the following input and so on....

[IBAHKA]

thanks for the suggestion altenbach.
what is a state machine? is it a sub vi?

[tst]

A state machine is a device for making decisions as the code progresses. Here and here are two tutorials about state machines in LV. Also, I'm assuming that looking for "state machine" in the LV Example Finder will yield some results.

[Ben]

Hi IBAHKA,

Great questions!

You have inspired me to find out that there is a 5000 character limit in a reply. Therefore this part one of two.

tst has already pointed at some links that will get you started.

Attached is an image of one of the state machines I put together a while back.

It represents a process where a set of steps must be executed in a specific order where subsequnt steps are dependent on the results of previous steps.

The user has the ability to exit the process at any time.

I am offering this image because it illustrates how a state machine architecture can help a devloper manage an applications behaviour without getting bogged down with the trivial details.

If my user calls me and says
"Ben, we changed our mind. We can not assume the same widget will be tested after we save the data for a test. We need to query for a different widget!"

I can just modify my state diagram such thtat the default transition coming out of the "Save Data" state goes to the "Show Spreadsheet Page" instead of going to the "Prep for Restart" state.

The state diagram is a wonderful way of handling very complex code.

I will throw together a state diagram almost anytime a function is "too complex to see" (sorta like how you started this Q) i.e. There are just to many factors to keep it all straight in my head.

They also let you analyze your solution for ways of simplifying because everything is laid out in one picture.

In the example I am including, I can look at it and say " I could have implemented this as fewer states". (Note:I chose this example on purpose because it could stand some improvement).

End of response to your Q:

End of part one of two.

I hope this helps,

Ben

[Ben]

Part two of two.

Start of Ben's "Ode to a State Diagram"

I love thee state diagrams, let me count the ways (W. Shakespear ?).

I develop the designs of most of the applications that come out of my shop. This means that I have to start with a bunch of "fluffy cloud" pictures my customers give me into a set of requirements for VI's that will be developed to implement the solution. The state diagrams I devlelop help me "catch a cloud and pin it down" (How do You solve a Problem Like Maria?", Sound of Music).

State diagrams are great for documenting in an understandable form what an application will do before it is developed.

They serve as guides to discussions of the approaches that will be used. This is when I tell customers, "See,the data will not be saved until you hit save, if there is a power failure before that, the data will be lost. Are you OK with that?"

Once refined and accepted the designs then serve to control scope creep. Any request that requires the State Diagrams (SD's) be changed, is big warning that the scope is changing.

The SD's also jump start the code requirements! As I document what needs done in each state of the application, I am in effect describing what the code that executes in that state is required to do. Each state can (depending on the complexity) become a unique sub-VI who's VI documentation is the documentation for that state.

The discusion of a sub-VI's functionality is never complete without a mention of the data coming into it and the data it returns. This is where the SD drives the data analysis portion of the design. LV after all does implement a data flow paradim (sp?). No code in LV can be implemented properly without concideration being given to dataflow. While specifying the functionality of a state, I am asking myself
"Where am I going to keep that I/O reference?",
"Where is it needed?",
"Who is going to be writting to it?",
"Is this going to be a memory pig?",
etc.

The results of this questioning lets me structure the applications data. (This is another story)

So...

When I am done with the SD and everything is documented, I end up with an application I can then turn over to developers that may not understand the complexities of the application, but can develop all the required sub-VI and have them all work together as expected.

General Note:
The image included is a screen shot of the LabVIEW State Diagram Editor (SDE). The SDE is not required to devlop SD's but simplifies their development. I have used paper and pencil to develop SD's for code written in C. MS Paint and MS PowerPoint for LV before the SDE was released.

The SDE in its current form is primative.
It does not have a "undo". You can not select more than one object at a time and allign them. You can not have more than one SDE screen open at a time (in LV 7.1).
It is primative.

Having said that, let me go on to say,

It is great!

It has simplified my life greatly.

I now can work in a LV environment. I do not have to edit diagrams in PP and then import and paste in diagrams. They are included.

I can watch my ideas in execution highlighting more where my "fluffy clouds" come to life.

I can quickly move from the design view of the SDE to the LV code by clicking on a state or one of the transitions.

I can step into someones cube that is "drawing up my clouds" and quickly figure out why those "lightning bolts" are coming from.

Warning:
SD should not be over-used! They are an excellent way to slow down your code. If you can "see" the LV code, write it in LV!

SD's and event structures do work together but "These things must be done delicately" (Wicked Witch, Wizard of Oz).

I hope this helps,

Ben

[IBAHKA]

Thanks Ben,
Yes, you are VERY enthusiastic about SDE's! Thanks for your elaborate and passionate description.
Ivanka