Overwriting an output in idle state

[TeamHalli]

Hello everyone,

I am using an RT and a Host VI to control a motor. The RT VI contains a state machine which executes after the user presses a "start button" on the host VI. The motor ON/OFF is an output from the state machine.

After the state machine executes and goes back to the idle state, I would like to retain the last state of the motor before allowing the user to turn ON or OFF the motor from a "Motor Button" on the host VI. How can I achieve this without having a race condition?

So in iddle state, the "Motor Button" turns ON or OFF the button, but after the state machine executes, the state of the motor is determined by a shift register and the "Motor Button".

Thank you for the help.

[crossrulz]

Your idle state should be looking for messages.  When you get a "set output" message, you set it to whatever you were told.  I recommend using a Network Stream for sending messages from your host to your RT.

[Bob_Schor]

It is difficult enough advising people on "how to" do something in LabVIEW without seeing their code -- when you add in doing this in a LabVIEW RT environment, it gets even more of a guessing game.

All of the guessing could, of course, be eliminated by including code, for example, a Zip file of the entire project (or selected pieces that show the basic concept).  Otherwise, it would help to provide the following:

• A description of the main Host routine (possibly even the Main Host routine, itself).
• A description of the main RT routine (which you did, but providing the actual Code gives us a much better idea of what you are doing).
• A description of how Host and RT communicate with each other.

In any case, you should try to provide actual code, not pictures of block diagrams -- we need to be able to "see behind" the diagram and potentially execute/test the code.

Bob Schor

[TeamHalli]

Here is an example code using LabVIEW 2013.

Thanks,

[Bob_Schor]

It is now much clearer what you are trying to do.  Here is what I think you want:

• The Host has three controls -- Start, which connects to the RT System (and should initialize the Motor to Off), Motor Control (which does nothing if Start hasn't been pushed, otherwise turns the Motor On and Off), and Stop, which stops the Host.  Note that nothing stops the Remote!!!
• The Host also has an indicator set by the Remote when the Motor State changes.
• The Remote has three States -- Idle (or Waiting to Start), Motor On, and Motor Off.  I recommend using these State Names instead of State 1 and State 2.
• Communication between the Host and Remote is through Network Shared Variables -- Start, Motor Control, and Motor State.

Before going on, there are several things fundamentally "wrong" with the Host VI.  First, the Host Loop has no timing function, so it will run "as fast as it can", using up as much CPU power as you can throw at it, checking those controls perhaps a million times per second (clearly excessive).  There are two "solutions" to this dilemma -- put a Wait function inside the loop (so it only checks, say, 10 times/second) or use an Event Structure so nothing happens until one of the switches changes.  [This is probably what you want to do -- if you don't know about Event structures, you need to spend a few hours with the LabVIEW Tutorials!].

The Start Button is a "Latch when Released", which means that it will be True only momentarily.  Network Shared Variables aren't really very good at sending very brief pulses to a remote Target -- if the Target doesn't read it at the right microsecond, it may miss the change.  You need to think about how to handle that.

It might make sense to add one more NSV called Stop -- set it in the Host when you stop the Host.

On the Remote side, you also have a loop with no Time Control.  With what time accuracy do you want to control your motor?  I'm guessing that if you put a 10 ms Wait in the loop (so you update the Motor State at 100 Hz), this would be adequate, at least to get started.

So let's ask what the various Remote States do.  The Idle State checks the Start NSV and, if True, changes to the Motor Off State.  Motor Off sets Motor State to Off and checks Motor Control -- if it is On, it changes to Motor On State (otherwise it remains in Motor Off).  Motor On sets the Motor State to On and checks Motor Control (I'll let you finish what it does based on the previous sentence).  

Now that we added a Stop NSV, we should probably also add a Stop State.  Why not simply wire the Stop NSV to the Remote Stop indicator?

What would happen if the Motor happened to be running when you stop the Remote loop?  If you add a Stop State (when you enter when the Stop NSV is True, no matter what State you are in), you can safely turn off the Motor before stopping the Remote.

Try coding this up.  Note that you have two Remote State Variables -- the Remote State (Idle, Motor On, etc.) and the Motor State (On or Off).  Keep them in Shift Registers, initialized appropriately.

Bob Schor

[TeamHalli]

Bob,

I made the example VI for visualization purposes. I am aware of the basics that I missed.

Here is again what I am trying to accomplish:

After the state machine executes and goes back to the idle state, I would like to retain the last state of the motor AND allow the user to turn ON or OFF the motor from a "Motor Button" on the host VI. How can I achieve this without having a race condition?

Thank you

[Bob_Schor]

I think we are talking about two different State Machines here.  As I envisioned the Remote, it never goes back to the Idle State once the Start Button has been pushed -- it is either in the Motor On State (and the Motor is On), the Motor Off State (and the Motor is Off), or the Stop State (and the Remote Program stops running).  

Are you envisioning something else?  What does "Idle State" mean to you?  How do you see a return to the Idle State?  Is it your intention to require multiple presses of Start?  What is the function of the Start Button (as opposed to the Motor Control button)?  In dealing with State Machines, you need to consider the transitions between States.  Make a list of your State Transitions, compare them to my description, and alter your State Machine accordingly.

Bob Schor