On 10/09/2013 02: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
>
good, i hope these value can be changed on the fly
( like calc a normal to the path plane and retract along that )
> 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
>
no spindle speed if no spindle
no spindle on tangential cutting, drag cutting, wire foam, edm
can something equivalent be wired in ?
( this_weird_cutting_discipline_is_ready ? )
> ----------------------------
>
> 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).
>
Q1 i dont a reason for 2 offsets, but other's scope may see some reason
> 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).
>
Q2 some cutting disciplines have no spindle
> Question 3: coolant, spindle, keyboard jog (+ eventually wheel jog): anything
> to be added to the shopping list?
>
Q3 not clear: coolant and spindle(speed?) are requirements for proceeding
but keyboard jog/wheel jog are methods
for the requirements, enforcing one discipline's reqs on another is bad
the outsiders would need to forgo JWP
i can live thru that tho
for the list of methods, i can live with those also, cant think of other
jog triggers
> Question 4: is a separate HAL pin for the on-pause/on-return speed acceptable
> for the first round?
>
'for the 1st round' ...
important thought that this is 'get the model working and lets see what
we got'
fine with me
> Question 5: any possible interactions with other commands/modes which could
> be an issue?
>
i dont see it bothering path compensations this way, looks good
>
> 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
>
the proposed flow looks good to me
------------------------
the following is an initial stab at the state machine flow
i haven't tured it enuf to say its valid
its just psuedo c-code
dunno if its of any use to real coders
so fwiw:
coding styles vary a lot
i code a state machine where:
each state is entered because a flag is set
each state is exited when that flag is cleared BY that state
each state sets flag for next state on exit
it doesnt lock the machine down waiting, its time sliced & re-entrant
each state is sequentially entered & re-entered till completion
i use a lot of 'busy_blah' and 'waiting_blah' flags/markers
// trigger event: Paused = True
// structs type Pose OffsetPose, PausePose
// flags
set busyInitialMotion False
set waitingJogDone False
set waitingReturnToInitialOffsetPose False
set waitingRequisites False
set waitingReturnToPausePose False
set ReadyToReturnToPath False
if (Paused and ! ReadyToReturn)
{
if (PoseNow() != OffsetPose) { // if offsets have value
InitialMotion(); // func sets busyInitialMotion
// it gets called till it resets flag
}
return;
}
if busyInitialMotion { // stuck here till done or abort
checkInitialMotion(); // ... until (PoseNow == OffsetPose)
return; // its a time sliced state machine
} // save state and try again
----- helper funcs
PoseNow() {
// stub
// returns current pose
}
InitialMotion() {
SetTargetPose( OffsetPose ); // begin moving to OffsetPose
busyInitialMotion = True; // marker set till satisfied
}
checkInitialMotion() { // PoseNow queries system pose
if PoseNow() == OffsetPose {
busyInitialMotion = False; // this is only release of loop
waitingJogDone = True; // next state
}
-----
// we are now where the tool should be after a pause
// we have not JOGGED yet
// i stub out the jog ( away) and return funcs
if waitingJogDone {
JogTillYouPuke(); // when is user done? special input?
// user can press btn without any jog
}
----- helper func
JogTillYouPuke() {
// stub a re-entrantTillSatisfied func
// clears waitingJogDone
// sets waitingReturnToInitialOffsetPose
}
------
if waitingReturnToInitialOffsetPose {
ReturnToIntialOffsetPose(); // no motion necc, just pose equality
// you may already be there :)
// but dont advance in state machine
// until back at InitialOffsetPose
}
----- helper func
ReturnToInitialOffsetPose() {
// stub re-entered till satisifed
// clears waitingReturnToInitialOffsetPose
// sets waitingRequisites
}
// maybe retrace, as in unstacking jog moves
// maybe a simple single line move from wherever
// back to InitialOffsetPose
// maybe either according to some config or Mcode
// i bet unstack jogs is better
// unless some clamping changed WHILE jogging
----
// now we jogged away and have auto returned to InitialOffsetPose
// so we are ready to re-enter the path when requisites are fulfilled
// requisites like SpindleUpToSpeed Flood Mist Air
// "Atomic batteries to power. Turbines to speed."
if waitingRequisites {
checkRequisites();
}
----- helper func
checkRequisites(reqs){ // pass a set of requisites
// stub stay here till list satisifed
// clears waitingRequisites
// sets ReadyToReturnToPath
}
-----
if ReadyToReturnToPausePose {
// lets see... testicles spectacles wallet and watch
// yep
// turbines to power, lets go Batman
SetTargetPose( PausePose );
waitingReturnToPausePose = True;
}
if waitingReturnToPausePose {
checkReturnToPausePoseMotion();
}
----- helper func
checkReturnToPausePoseMotion() {
if PoseNow() == PausePose {
waitingReturnToPausePose = False;
ReadyToReturnToPath = True;
}
-----
if ReadyToReturnToPath {
// no idea how to restart the path
// but we be all ready boss
// in posn, requisites met
// user said to go
// some trigger gotta be pulled
}
------------------------------------------------------------------------------
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
