LabVIEW
DO signal continues after stopping VI
@aeastet wrote:
@johntrich1971 wrote:
The OPs code is actually not very bad for a beginner, and a state machine is not necessary for this simple program. While I use a state machine a lot it is not the answer to every problem. LVOOP could just as easily be offered as an alternative programming method, but it is also not necessary to solve the OPs problem for this simple program
Hi John,
You act as though I am telling him to use something that will take hours to implement. A state machine will take 5 minutes to implement. It would solve the issues he is having, no doubt. I'm not sure what LVOOP has to do with anything. It is a different way to program not an architecture. You still need to use state machines and producer consumer loops with LVOOP. LVOOP is not a loop or architecture. I am really not sure what you are trying to suggest. A simple state machine is a great first step in starting to learn how to program. I'm not sure why you even feel you needed to chime in about his except to get more posts.
You seemed adamant that a state machine was the only way to go - even though the OP had already been given a much simpler alternative. There is nothing wrong with his architecture for this simple program. He has three states - initialize (before the loop), running (inside the loop), and shutdown (after the loop). He just needed to add proper shutdown code in his shutdown state. Furthermore, while a state machine might take you or me about 5 minutes to implement it may very well take longer for the OP who is a LabVIEW beginner. I remember it taking some time to learn how to implement a state machine when I was first learning LabVIEW (I probably started doing state machines in LabVIEW 4). Finally, you did not even mention the necessity of putting the code to turn off the motor in the shutdown state (the OP had assumed that the output would return to a default).
Actually I do not use a state machine all of the time now. It is just one tool in the arsenal. I choose the appropriate architecture for the problem. I often have an AI loop which does nothing but acquires data and sends it to another loop. No need to add the extra overhead of a state machine.
I think that before the OP moved to a state machine he needed to move away from the use of the DAQ Assistant. He had a start by using DAQmx for the DO. Next, I've found it to generally be beneficial to have DAQ and control in separate loops. I would have suggested this prior to switching to a state machine.
I think that my initial response, though, was the sarcastic tone of your post. I didn't think the OP deserved it. Yes, we're here to steer in the right direction. If you had said something like, "I would recommend switching to a state machine. You would initialize your DAQ in one state, acquire in another, and then shutdown (including turning the motor off) in a shutdown state," it would have been more beneficial to the OP - it offered another architecture while also giving the solution to the question asked.
