my vi is hung...how can I discover where it hangs without running it over and over

[Hummer1 · Accepted solution]

I think you are right about the switches vs latches...I'll do that.

Also I found the problem...the code had gotten so cumbersom that I didn't notice a second event structure in the while loop...(not supposed to do that)...I moved it out and it works fine now...

Thanks. to all.

[smercurio_fc]

---

Jeff Bohrer wrote:

HOLD On you said thee LATCHING booleans  AHHA! and a value change event

Make 'em switchers.  The first thing to do in the event would be to read the old val and use a property node>Value (Not Value(Signaling)) to reset the boolean.  Latching booleans don't play nice with value properties because of the way latching is handled in the guts of the complied code.

---

That is completely unnecessary. There's nothing wrong with latching Booleans - the default Stop button is a latching button. The poster never said anything about setting the value programmatically. Besides, this is not necessary at all - LabVIEW will automatically reset the button as long as it's inside the event case. Since the poster indicated they are, the problem clearly lies elsewhere, and my suspicion is the first event that's being fired.

Here's a simple test: Remove all the code from the event case for that first button. Does the VI work? If it does, then clearly the event is not stopping. 

[smercurio_fc]

---

Hummer1 wrote:

I think you are right about the switches vs latches...I'll do that.

Also I found the problem...the code had gotten so cumbersom that I didn't notice a second event structure in the while loop...(not supposed to do that)...I moved it out and it works fine now...

---

Well, there you go.

---

the code had gotten so cumbersom

---

This should indicate that you need to reevaluate your architecture. Suggested reading:

Application Design Patterns: Producer/Consumer

Application Design Patterns: State Machines

[Hummer1]

Yep ... you are exactly right...it is a hack.

I have thought of trying to write what I am doing in the state machine, but don't have the tool and don't want to invest the effort in looking at it temporarily if we don't eventually get it.

I don't have the test bench either...that might work too...the concept is to have an executive run other vi's inserting operational values into them as it goes to substitute for how the vi's were run manually.  It works nicely, but is a bit cumbersome.  I haven't thought out how to arrange all the variables, and IO yet...which is why it got clunky...time, skill and education will eventually overcome this problem...education coming from my kind friends on the forum, and skill developing after having listened to them all these years.

Thanks again to all the valuable input.

Hummin along again.

[Mark_Yedinak]

You don't need the state chart toolkit to use or create a state machine. You can implement a state machine by simply using a case structure inside a while loop. You can use simple strings as your state names or a typedefed ENUM. You would use a shift register to pass the next state through the state machine. A more flexible version would be a queued state machine that uses a queue for the states. The examples and templated that ship with LabVIEW should get you started. Also, take a look at the articles posted above.

[GovBob]

---

Hummer1 wrote:

Yep ... you are exactly right...it is a hack.

I have thought of trying to write what I am doing in the state machine, but don't have the tool and don't want to invest the effort in looking at it temporarily if we don't eventually get it.

Thanks again to all the valuable input.

Hummin along again.

---

I'm a little confused by your statement that a state machine is a special tool? Actually a state machine is just a case structure surrounded by a while loop. The case to be run is determined by a enum control. You should customize this enum control to make it a type def. This custom control is outside the  while loop and through a shift register to the case selector. Inside each case you create a constant of this type def enum control and wire that to the right hand shift register to determine the next case to go to. In your shut down case you wire a boolean constant to shut down your while loop. Do I make sense? The state machine is really powerful construct and well worth the time to learn as it makes your coding life so much easier. If you want I could provide a quick example. Once I learned it my coding became so much easier to follow.

Mark beat me to it.

Message Edited by GovBob on 10-01-2009 05:07 PM

[JÞB]

---

smercurio_fc wrote:

---

Jeff Bohrer wrote:

HOLD On you said thee LATCHING booleans  AHHA! and a value change event

Make 'em switchers.  The first thing to do in the event would be to read the old val and use a property node>Value (Not Value(Signaling)) to reset the boolean.  Latching booleans don't play nice with value properties because of the way latching is handled in the guts of the complied code.

---

That is completely unnecessary. There's nothing wrong with latching Booleans - the default Stop button is a latching button. The poster never said anything about setting the value programmatically. Besides, this is not necessary at all - LabVIEW will automatically reset the button as long as it's inside the event case.

Nice tidbit of info:  Thanks- kudos again!

Since the poster indicated they are, the problem clearly lies elsewhere, and my suspicion is the first event that's being fired.

Here's a simple test: Remove all the code from the event case for that first button. Does the VI work? If it does, then clearly the event is not stopping. 

---

[Hummer1]

GovBob...thanks for the info.  I used enumerations to pick values for various alternative operations, but when I went to remote control the vi, Ben suggested that I should use a ring rather than an enumeration....

I am coming to understand that almost everything I write will eventually be wrapped in a larger application and so generically applying techniques that are easy to manage using Invoke node or Property node with signaling is important.  For that reason alone, it will become my practice to use press on / press off mechanical action on my controls in the future, resetting them as part of the events they trigger.

I like the latching buttons, but in order to manage an application remotely you have to double up on the buttons, and then hide them and then add control value change to the event definitions,all of which is fraught with confusion for my old and creaky mind.

I think I might download the state machine tool and give that a try  (is it sate machine or structure I don't remember...I'll find it ...)

Thanks to all

H