On Wed, Oct 9, 2013 at 2:02 PM, Michael Haberler <mai...@mah.priv.at> 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')
>
By saying IPP you imply there is more than one pause position. This would
be a good thing. If LCNC is going to offer this capability then while you
are in there mucking around go all the way.
ex - back trepanning with a boring bar in a bore
One pause position would not be sufficient to return.
Three would be a minimum and four would be better.
Why limit it to 1 or 4?
This would work nicely with the feed override and rapid override on two
pins.
Rapid override would be used until arrival at the last return segment.
Feed feedrate would be used for the last return segment.
Although, this should be integrator optioned.
Why restrict the reading/setting/use of Tool Length Offsets to tool change
operations? Reading TLO's every line would allow minor changes while the
program is running. The operator would make an offset adjustment to be
applied at the end of the current line running in the program.
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_?
>
Assuming the offset you are talking about is the IPP then I can see a case
for a little different approach in return. Sometimes a broken tool will
require a modified reentry to remove material deposited or hardened as the
result of the broken tool.
Multiple pause positions and feed control would allow fine control of the
reentry process.
> 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).
>
Shouldn't all conditions controllable by HAL be the only control option?
> Question 3: coolant, spindle, keyboard jog (+ eventually wheel jog):
> anything to be added to the shopping list?
>
Resetting TLO's is major at this time. Stopping to clean chips is fine but
changing the tool requiring an offset adjustment is very important.
>
> 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?
>
TLO's
>
>
> 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
>
thanks
Stuart
--
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
Just for you NSA - think autointercourse
terrorist suitcase bomb sarin
hello
------------------------------------------------------------------------------
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
