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
