Axis Triggering

[tmoulder]

Let's use CTAXLIMT as an example -

Is resetting the E/R input enough to completely cancel a move in progress?

If I execute a move, and then wish to execute another move with different accel / decel / max speed, do I need to

a) run a new CTAXCFG block before-hand?
b) modify and re-run the original CTAXCFG before-hand?
c) change a parameter in the CTAXLIMT block before-hand?

Thanks,

TM

[tmoulder]

Where I'm going with this is, if I have multiple target positions to move to at different ramps, I'd like to do it with a single parameterized move command executed via RUN, rather than 5 move commands in a Stage sequence.  Cleaner, easier to trace, insert-best-practice-here, etc.

[BobO]

Where I'm going with this is, if I have multiple target positions to move to at different ramps, I'd like to do it with a single parameterized move command executed via RUN, rather than 5 move commands in a Stage sequence.  Cleaner, easier to trace, insert-best-practice-here, etc.

I love the idea of a single parameterized command executed as a program block, although I wouldn't hesitate to use stages as part of the implementation of that block.

As for your original questions...

Yes, dropping the enable will completely terminate the move.

CTAXCFG largely just initializes values in a structure that are used with the moves. Since the CTRIO/2 register space is limited to a fairly small window, it is necessary to put stuff down in the module ahead of time. Those values can come from profiles, or on the case of CTRIO2, the CTAXCFG instruction. So if you want to change speed and/or accels, you will have to run a CTAXCFG. Can be the same instruction with different values, or a different instruction.

You can change values in the CTAXLIMT and run it as often as you like. We generally made eveything accept a variable that we reasonably could. Most things that will accept a variable will also accept an array reference...so that offers some additional options for abstracting calls.

[tmoulder]

Thanks Bob, I appreciate the info.

So if I re-run the CFG, since both instructions are async, can I execute one-after-another in the ladder scan, or do I need to implement the cfg "on.success" bit between them?

If I run cfg, does on-success bit turn off immediately, or do I need to look for the transitions before executing my move further into the ladder?

Thanks again!

PS, are you the same BobO I bump into sometimes running around on PLCS.NET?

TM

[BobO]

So if I re-run the CFG, since both instructions are async, can I execute one-after-another in the ladder scan, or do I need to implement the cfg "on.success" bit between them?

In general, you should always use the result bits to sequence operations. That is a large part of why we are big fans of Stage, and the exact reason that we made async boxes capable of implementing stage transition logic directly.

If I run cfg, does on-success bit turn off immediately, or do I need to look for the transitions before executing my move further into the ladder?

From the first scan that the box sees the enable, the result bits are cleared. I offer the caveat 'sees' since stages, programs, and tasks all skip over code when they are disabled.

PS, are you the same BobO I bump into sometimes running around on PLCS.NET?

Don't think so. I live here and at ADC, and that's pretty much it.