I like it except:
Instead of saving just the initial-pause-position, I would save all of
the jog positions, too. Then resume could play the positions back in the
reverse order.
If is more work than is warranted now, at least keep that in mind for an
enhancement so the the present solution doesn't rule that out.
Regards,
Ken
On 10/9/2013 3:02 PM, Michael Haberler wrote:
> please think through if this sequence sounds generally applicable, and
> consider my questions below.
>
> the current flow I am thinking of is this:
>
> pause sequence:
> -----------------
> if running, and pause command is issued:
> save the position where pause was detected as initial-pause-position
> ('IPP')
> if the pause-offset 1) is non-zero:
> jog to that offset, using a jog-velocity pin 2)
> stop motion once there
> else
> just stop motion
>
> ... jogging around...
>
> resume sequence:
> ----------------
> if at the inital pause position:
> wait for at-speed
> resume motion
> else # in some offset
> if the pause-offset is non-zero and not currently at the offset position:
> issue a jog move to the pause offset at jog velocity 2)
> once arrived, wait for spindle at-speed 3)
> issue the reentry move to the IPP at jog velocity 2)
> else
> # we are already at the offset position
> wait for spindle at-speed
> issue the reentry move to the IPP at jog velocity 2)
>
> if arrived at IPP:
> resume primary motion queue, program continues.
>
> During the all pause states (except normal state - program running, not
> paused) coolant and spindle NML commands will be honored.
>
> --
> 1) defined by a set of motion.pause-offset-x/y/z etc pins
>
> 2) currently NML jog commands needing velocity carry it as a parameter;
> afaict there is no concept of 'current jog speed' in motion without a jog
> command issued. But this move happens without an NML command conveying
> values, so motion has no idea what the 'current jog speed' is. Short term
> fix: use a pin motion.offset-jog-speed which applies to the initial offset
> move, and the reentry move. Better long-term solution: make motion remember
> whatever is 'current jog speed', e.g. by issuing an EMC_JOG_SPEED command at
> startup and jog speed change in a UI.
>
> 3) doing it in this order (start jog, wait for at-speed when done) enables
> overlapped spin up and move to the offset position by issuing spindle on,
> then resume
>
> ----------------------------
>
> Question 1: is there any use case for the offset used while pausing, and
> while returning _to be different_?
>
> this would suggest two sets of HAL pins, pause-offset-x etc and
> return-offset-x etc. Note either of those being zero would avoid the
> predefined move-on-pause
> and move-on-return respectively.
> Having one set of pins implies that both moves will always be issued if
> non-zero. The alternative is some mode pin which states which of the
> moves (on-pause, on-return, or both) is to use the pause offset (less
> elegant, less pins).
>
> Question 2: is there any scenario where the wait-for-at-speed needs to be
> skipped?
> (note motion.at-speed can be faked by external HAL logic if needed).
>
> Question 3: coolant, spindle, keyboard jog (+ eventually wheel jog): anything
> to be added to the shopping list?
>
> Question 4: is a separate HAL pin for the on-pause/on-return speed acceptable
> for the first round?
>
> Question 5: any possible interactions with other commands/modes which could
> be an issue?
>
>
> this is a nontrivial change, so I would prefer the change is specified,
> discussed and understood fully beforehand
>
> I attach the description of the various states the pause handling goes
> through which might help to clarify operation a bit
>
>
> thanks,
> - Michael
>
> -------------
> // the states of the pause finite state machine
> // current state is exported as 'motion.pause-state'
> enum pause_state {
> PS_RUNNING=0, // aka 'not paused', normal execution
>
> // a pause command was issued and processed by command-handler
> // looking for the first pausable motion (e.g. not spindle-synced)
> // the current position is recorded in initial_pause_position
> PS_PAUSING=1,
>
> // the initial pause offset is non-zero.
> // jog to this offset once a pausable motion has been detected;
> // once this jog completes state transitions to PS_PAUSED_IN_OFFSET
> PS_JOGGING_TO_PAUSE_OFFSET=2,
>
> // motion stopped, and position is where the pause command was issued
> // This state is reached only if pause offset is zero.
> // on resume, no further move will be issued
> PS_PAUSED=3,
>
> // motion stopped, and positon is NOT the initial_pause_position
> // meaning a reentry sequence is needed before a resume (i.e. switch to
> the
> // primary queue) can be executed
> PS_PAUSED_IN_OFFSET=4,
>
> // currently honoring a jog command (incremental or continuous)
> // state can be reached only from PS_PAUSED and PS_PAUSED_IN_OFFSET
> // a coord mode motion in progress
> // once done, state transitions to PS_PAUSED_IN_OFFSET
> // (or - unlikely case: if stopped in inital_pause_position, to
> PS_PAUSED)
> PS_JOGGING=5,
>
> // a jog abort during jog move was issued. This happens on
> // keyboard jog/key release during a continuous jog.
> // when the move stops state transitions to PS_PAUSED and
> PS_PAUSED_IN_OFFSET
> // depending on stopped position.
> PS_JOG_ABORTING=6,
>
> // state was PS_PAUSED_IN_OFFSET, and a resume was issued
> // the move to the offset position is in progress
> // this state will be reached only on reentry, AND if the offset is
> non-zero
> // the sequel state is PS_WAIT_FOR_AT_SPEED once the move completes
> PS_RETURNING_TO_REENTRY_OFFSET=7,
>
> // reached from PS_PAUSED, PS_PAUSED_IN_OFFSET,
> PS_RETURNING_TO_REENTRY_OFFSET only
> // wait for motion.spindle-at-speed to become true
> // sequel states: PS_RETURNING if not in initial_pause_position, else
> PS_RUNNING
> PS_WAIT_FOR_AT_SPEED=8,
>
> // the final reentry move to initial_pause_position is in progress
> // when this move completes, state switches back to PS_RUNNING
> // and the primary motion queue is resumed where we left off
> PS_RETURNING=9,
>
> // like PS_PAUSED/PS_PAUSED_IN_OFFSET but used while stepping
> PS_PAUSING_FOR_STEP=10
> };
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
