subvi's in State Machine

[VeeJay]

Hey Guys! 🙂

I have a question regarding using subvi's in a particular state of a state machine and stopping the subvi's when an error or stop occurs and changing the state. Is my implementation right here? (more than unlikely but I would like to hear a YES 😉 )

Please find the attached vi. I am not attaching the subvi's. The two subvi's "ELEV" and "SPEED" run in parallel at 100ms and 250 ms resp. Now, an error in either subvi's should stop the other vi, which I have implemented. Both subvi's will send the next state if an error occurs , state it has to go is "wait". Can I use one of those to pass it to the sift register of the SM? Thanks!

V

[tbob]

Without being able to see the subvi's we can't tell if it is right or wrong.  You should run it.  If it works, then it is right.  You can use an ouptut of the subvi to cause the next state.

[smercurio_fc]

---

@tbob wrote:

You should run it.  If it works, then it is right.

---

Succinct and oh so true.

[VeeJay]

Oh!! I just wanted to know if the implementation is right. 🙂 I didn't get a chance to try it out yet. What I want to know is, when two subvi's run in parallel in one state case of the SM; either of them may encounter some error condition and shut off due to safety concerns; then, we output the next state from the subvi; I get that. But what if only one encounters the error; yet both have to be stopped and the SM must go into the next state. That's what my question is about. Thanks!

V

I wouldn't have had a question if I had a chance to run it and knew it worked now would I 😉

[smercurio_fc]

The "Start Protocol" state will not complete until both VIs have finished. If only one of them stops due to an error condition, LabVIEW must wait until the other one has completed before it can leave the state since it is waiting for data to be generated by the other VI. If you must make sure that the other VI terminates if one encounters an error condition then you must use some sort of communication protocol or flag to tell the other VI to stop. There are many ways to do this: control references, global variable (YES, all you global variable haters!), queues, notifiers, etc. I'm sure eveyone will decide to chime in at this point offering their opinions on the advantages and disadvantages of each solution, which you can get just as well by doing a search since this "inter-VI" communication has come up dozens and dozens of times (with the same persons offering the same opinions each time ).

[tbob]

I think VeeJay is now familiar with control references and property nodes.  That is what I would use.  Have a general flag (boolean) in the main vi and pass the control reference to each subvi.  If an error is encountered anywhere, write to the Value property node.  Each subvi will have to check the Value property node periodically to see if it is time to stop.

[VeeJay]

Yes, Control reference is what I have used. I get the whole idea. Syntactical implementation is what I am having trouble with. LabVIEW has too many icons and function 😉 Would this be a case of main vi/subvi relationship with respect to the two parallel subvi's? I mean in terms of passing the reference of the flag from one subvi to the other and vice-versa. An example would be appreciated with a "KUDOS" lol 🙂

VeeJ

[smercurio_fc]

---

@VeeJay wrote:

Yes, Control reference is what I have used. I get the whole idea. Syntactical implementation is what I am having trouble with. LabVIEW has too many icons and function 😉

---

Well, .NET has too many classes, properties, and methods....

---

Would this be a case of main vi/subvi relationship with respect to the two parallel subvi's? I mean in terms of passing the reference of the flag from one subvi to the other and vice-versa.

---

The main VI must wait until both VIs are finished because of data dependency. The subVIs generate a value for a front panel indicator. LabVIEW cannot set the value of the indicator until the data on the wire has been generated, and the subVI is the only source. That source of data is not filled until the subVI is complete. That's pretty much it.

If you are familiar with text-based languages, then consider an equivalent example: you have two functions which you spin off to run in their own threads. If one of the functions ends, the other function doesn't know anything about it. Unless you use some mechanism that both functions can access.

---

An example would be appreciated with a "KUDOS" lol 🙂

---

See attached.

[VeeJay]

____________________________________________________________________________________________

 

The main VI must wait until both VIs are finished because of data dependency. The subVIs generate a value for a front panel indicator. LabVIEW cannot set the value of the indicator until the data on the wire has been generated, and the subVI is the only source. That source of data is not filled until the subVI is complete. That's pretty much it.

If you are familiar with text-based languages, then consider an equivalent example: you have two functions which you spin off to run in their own threads. If one of the functions ends, the other function doesn't know anything about it. Unless you use some mechanism that both functions can access.

______________________________________________________________________________________________

I get the idea. Obviously, subvi's in parallel will not know each other's status unless they communicate. I get it. My question was with regards to implementation using control references. Just the way we do with updating the main vi from subvi, would that be the same way to go. But, I understand now.

Thanks! :))

[VeeJay]

Hmmmmm..... Now, to send the next state value to the SM? Can we just send that value from one subvi (the faster vi) to  the shift register of the SM since both loops are stopped now? That was my original question.