Global Stop/Go

[AsianChef]

Hi,

I am in need of assistance dealing with creating a control that will allow me to turn the stages I'm working with "on" and "off" without closing the program entirely. There are a couple of problems (at least for me) with this though, perhaps concerning the method. Currently, I am not able to stop the stages right away. It usually goes through two motions before a complete stop occurs, and I was wondering if there was a way to make them stop moving once the stop of off button is pressed. The other issue is turning them on again, for this will be integrated with a camera interface, and the stages themselves are able to be controlled manually. I wanted options just in case. I attached the program if that helps (Using LabView 8.5).

Any thoughts or advice? I appreciate the help.

[CoastalMaineBird]

Your VI requires something in INSTR.lib called "ZaberT" that you did not include- I don't have that item, so I can't exactly tell what you''re doing.

It looks like you're going thru 8 stages of motion, by sending a command to some instrument, waiting for X mSec and then moving to the next position.

BTW I strongly suggest you use a TYPEDEF for that MOTION1-MOTION8 enum- some of your copies have an END option and some do not.  Use a TYPEDEF will make them all identical and you can change the master without having to change all the individuals. That's why you have all those type-coercion dots, though that's not your problem.

All that said, I don't understand what you are trying to do, because I don't know what you mean by "turning OFF" a stage.  Do you mean you want to abort the waiting period?  Or what?

[AsianChef]

The Zaber files can be found here

I don't exactly understand, though, what you mean mean by TYPEDEF; I wouldn't say there is a master motion though, as all but two positions are repeated, though the ones that are have an additional purpose.

By turning off a stage, I am referring to simply stopping the motion of the stages immediately (comparable to aborting the program) or at least stopping the next pattern from continuing. In addition, I would like the option to turn the stages back on without having to start the program again, though I seem to be having difficulty with that as well.

[altenbach]

---

@AsianChef wrote:

It usually goes through two motions before a complete stop occurs, and I was wondering if there was a way to make them stop moving once the stop of off button is pressed.

---

This is because of dataflow and the way your programmed it. The stop button gets read at the start of the loop in parallel to the case structure. In order to read the stop condition that occurred later during the same iteration, the loop needs to spin once more. You need to ensure that the stop button gets read after the case structure. For example you could place it in a single-frame flat aequence and add some data dependency.

---

@AsianChef wrote:

Any thoughts or advice? I appreciate the help.

---

I guess the main problem is the fact that your motions take a long time. You could move in smaller steps in a loop, leaving more occasions to stop.

I also don't see why you need to initialize before, and close after every motion. It is probably sufficient to initialize before the main loop, do the various motions while keeping the task active, and only close after the while loop at the end of the pogram.

[CoastalMaineBird]

By TYPEDEF, I mean the definition of the control itself.  You create a CTL file with the ENUM in it, and set it to be a TYPEDEF.  You then place instances of that wherever you want the constants to be used.  If you change the definition in the master CTL file, all the instances update automatically.  That's a convenience, but it's not part of your problem.

If you want to be able to start and stop the things, then you have to design your program differently.  Right now, your program has no choice but to wait the given time, and proceed to the next command.  If you want it to have choices then you have to program it that way.

Consider a state machine.  It would have several states, defined in a (typedef) ENUM:

IDLE

Connect

Moving to position 1

Waiting in position 1

Moving to position 2

Waiting in position 2

Moving to position 3

.... etc., etc.

Disconnect

The rules of a state machine are:

1... It knows what state it is currently in.

2... It knows what conditions are necessary to get to some other state.

3... It executes quickly as possible and returns to it's caller.

It would be born in IDLE state, it remembers it's own state in a shift register.

It is called repeatedly (every X mSec) with a command of "Service"

The host VI would call the state machine with a command of MAKE CONNECTION.

All the MAKE CONNECTION  does is set the internal state to CONNECT.

The next SERVICE call will see the state = CONNECT, make the serial connection, and store the connection refnum, task ID, whatever, in a shift register, and change the state to MOVING TO POSITION 1.

The next SERVICE call will see the state = MOVING TO POSITION 1, issue the command using the stored task ID, and set a time target = NOW + X mSec, and set the state to WAITING IN POSITION 1.

The next SERVICE call will see the state and check the time.  If it's not time yet, then it just returns (leaving the state as is). If NOW is >= the target time, then it sets the state to MOVING TO POSITION 2.

The next SERVICE call sees the state = MOVING TO POSITION 2, and issue the appropriate command, and set a new time target and a new state.

Doing it that way will result in the exact behavior you have now, if nothing else happens.  But the point is that you can call the state machine with other commands to move to positions out of order, to stop (set state = IDLE), or do other things.  You have WAY more flexibility, plus you have time in the host VI (you do no waiting in the state machine itself) to attend to other unrelated tasks.

My blog has an entry for this:

http://culverson.com/state-of-the-machine/

[AsianChef]

Alten --

I realize that the dataflow is programmed that way, it's just that I can't figure out how to adjust this  correctly.

As to initializing and closing the vi out of the case structure, you are absolutely correct; then again, it doesn't exactly change anything in terms of what I am looking for.

Concerning the wait times, they need to be that long. There are 5 positions that I would like to focus on which will have a description for (which is basically non-existant now). I'm trying to image an object with moving parts, so it's necessary to have a hold time (it really comes out to just 5000 seconds right now though)

Coastal --

As to the state machine, I guess I'll have to read up on more tutorials. I understand what you are saying, it's just my skill level is probably not up to par and I can't visualize how to make such options. Would you know of any sample programs or examnples by chance? Thanks for giving me an idea though.

[CoastalMaineBird]

The blog post provides an example - did you look at it?

Although the re-entrant part of that is probably not important to your case, the basic idea is the same.  The state machine has all the logic for state transitions, the host is the controller.

In that example the core function SERVICE is the call that operates everything.  It is called periodically by the host VI.

Other functions (START CAL, for example) exist to provide points to control the state machine behavior.

[altenbach]

---

@AsianChef wrote:

I realize that the dataflow is programmed that way, it's just that I can't figure out how to adjust this  correctly.

---

Dataflow dictates that a node will not execute unless it has data on all inputs and a structure will not output data unless everything in it has finished.

You simply need to delay reading the stop boolean until the case structure has finished. By placing a sequence frame and adding a data dependency from the case structure as follows, the diagram of the frame will wait until the case has finished, at which point the boolean gets read. Note that the stop button is latch action, meaning it will stay depressed until it is read by the code.

BAsically:Once the case structure completes, data is available at A. The sequence frame waits until data is at B. The stop button gets read during C.

Also, your time controls should be inside the loop, else they won't get read during every loop iteration.