Cancel a movement

[tmoulder]

Hello All!

I'm using a CTRIO2 for stepper motion control.  I'm working on alarm logic, and have a couple of low-level questions:

1.  If a move is started in a code block, and the block is HALTed before execution completes, what happens to the pulse train?  Does the move finish?  Are status bits updated regardless?

2.  If a move is started in one code block, how can it be cancelled in another code block?

Thanks!

TM

[BobO]

1.  If a move is started in a code block, and the block is HALTed before execution completes, what happens to the pulse train?  Does the move finish?  Are status bits updated regardless?

First...if possible, don't. Generally you should avoid using HALT and should use EXIT instead. Driver based (asynchronous) instructions really need to complete normally to guarantee that everything cleans up properly.

Second...here is a known bug (from about a week ago) that certain CTRIO/2 instructions will not behave well when forcibly terminated. It should be fixed in the upcoming 1.1, but, we're talking about improving the behavior in an exception condition that ideally should never occur.

More info: When a code block that contains a driver based instruction doesn't run constantly until the instruction completes normally, it results in a hung driver...bad. This can be caused by HALT, EXIT, JMP, SUSPEND, or a time-based TASK with an unacceptably long period. We have added code to check for locked drivers when a code block terminates, and make a best effort to clean up. When that happens you'll get an abnormal termination warning ST147 ($InstrTerminated). You really don't ever want to see that and should treat it as a programming error.

2.  If a move is started in one code block, how can it be cancelled in another code block?

Drop the enable, which can be controlled by a public bit, and the instruction will terminate normally and set the success bit or transition to the success stage.

[tmoulder]

I was going for something akin to a user-defined-function block, but this pretty much rules out that approach.  That's fine, just need to adjust accordingly.

Thanks!

TM

[BobO]

I was going for something akin to a user-defined-function block, but this pretty much rules out that approach.  That's fine, just need to adjust accordingly.

I don't see why not. You simply need to make sure that the function block is allowed to terminate properly. We're happy to help if you will describe what you need it to do.

[tmoulder]

Basically I was planning to create a program block containing a config command, followed by a dynamic move command, using stage.  To move to a target with a particular profile, load the profile into a set of DW and run the program block  After the move executed, the program would exit, and thus the move would be complete.

The problem is not in the move, it's in the alarm logic.  On any alarm, I want all executing moves to end.  My first thought was to simply halt the motion program, but I could not predict if this would physically stop the motor - thus my question.  After reading your reply, I rewrote the motion commands into program blocks that will be scanned continuously, so a move in progress can be halted by the "Any Alarm Active" bit, and terminate correctly.

I suppose with a bit of effort, I could have kept the original prg blocks and worked out how to stop them cleanly, but when you pointed out that the move command needs to execute to completion, I felt that continuous scan was the best way to ensure that.

By the way, casting did turn out to be a marvelous use of vectors.  I also discovered the user-defined memory blocks, and they are fantastic.  Now your conversation with Controls Guy about structures makes alot more sense, and let me chime in in support of User-Defined structures - it would be great to design a Motion Structure for each of my axes, instead of "YAxisB0-32" for bits and "YAxisDW0-15" for motion parameters.

Thanks!

TM

[tmoulder]

On a related note, you could design a motion heap item yourself and incorporate it into the next version of DmD.  Combine the config and execute into a single function, then no more concerns about sequencing the two...

Just sayin... 

[BobO]

...but when you pointed out that the move command needs to execute to completion, I felt that continuous scan was the best way to ensure that.

To be clear, the move itself doesn't need to run to completion, the move instruction needs to finish. You can kill the move by dropping the box enable, you just need to not kill the containing logic, stage or program block, before the instruction signals completion. It is not hard at all to incorporate abort logic into the stage flow...but if you wanna kill moves before they normally complete and jump to an exception handler to terminate early, you just have to add a small additional bit of logic to the stage. It's logic you would be writing regardless, so I personally would have stayed with stage.

By the way, casting did turn out to be a marvelous use of vectors.  I also discovered the user-defined memory blocks, and they are fantastic.  Now your conversation with Controls Guy about structures makes alot more sense, and let me chime in in support of User-Defined structures - it would be great to design a Motion Structure for each of my axes, instead of "YAxisB0-32" for bits and "YAxisDW0-15" for motion parameters.

It is currently on the schedule for Rel 1.2, due out later this year. Barring any unforeseen technical challenges, it should be pretty painless...the entire memory system, including system data types, is already dynamic created. The big effort is UI and dealing with data types being more dynamic...meaning...can go away or be different from moment to moment.

[BobO]

On a related note, you could design a motion heap item yourself and incorporate it into the next version of DmD.  Combine the config and execute into a single function, then no more concerns about sequencing the two...

Just sayin... 

We have plans to do a fully legit Do-more centric motion module with super-duper mind-reading integration. The CTRIO/2 integration was a bit ad hoc, and based heavily on existing thought. Were I to do it again based on what we eventually came to, it would probably work more like you are describing.

OTOH, it ain't perfect, but it is still about 1000% better than under DL.

[tmoulder]

To be clear, the move itself doesn't need to run to completion, the move instruction needs to finish. You can kill the move by dropping the box enable, you just need to not kill the containing logic, stage or program block, before the instruction signals completion. It is not hard at all to incorporate abort logic into the stage flow...but if you wanna kill moves before they normally complete and jump to an exception handler to terminate early, you just have to add a small additional bit of logic to the stage. It's logic you would be writing regardless, so I personally would have stayed with stage.

I understand where you are coming from, I was speaking of "execution of box" as opposed to "execution of move".  And I can see where it could have been done and remained in stage.

The problem I have with conditionally-scanned logic - both here and other platforms - is the risk of missing something on the dismount.  Simple example - in the past, I've tried using conditional routines to conserve timer memory, re-using a timer at several points in the program.  But forget once to reset the timer "on the way out" and your next stage/state/step starts with some of it's time-span used up already - leading to premature timeouts.  This also tweaks my CCA, since it's an additional line of code in every timeout stage for no other reason than resetting a timer.

And that's just a small example.  Had I continued along on my motion logic without thinking to ask, I could have wound up with a much more complex example in the near future 

So as a general principle, if anything *must* be scanned to complete execution (logically) I prefer not to make it conditional.

And yes, a full motion module with be great!  I look forward to seeing it.

Thanks!

TM