On Tue, 31 Mar, 2020, 9:43 pm Chris Morley, <[email protected]>
wrote:

>
> I don't follow your reasoning of G10 being a queue buster.
> it shifts the origin - completely predictable.
> it will happen at the right time when it gets to the motion side of
> linuxcnc.
>
Chris,

G10 does not shift the origin only, it changes the offset value. This
change needs to be synchronised between rs274 and task and motion.
G5x applies the origin shift.


Tool changes -  if you stop linuxcnc to jog then you are not running in
> auto mode any more.
> You can't pause and jog in linuxcnc currently, without using hacks to
> works around the motion component.
>


G43 is generally applied behind a txx my which is a queue buster. Also
g43.x gets the offset value dynamically. So it should be a queue buster as
only rs274 has access to that value.

Same for g92.


Anything that gets dynamic values from the NGC program or elsewhere should
be a queue buster like g38.1

automata

>
> And of course these decisions must be made for the best compromise, my
> point was that the are reasons to keep queue busters to a minimum.
>
> Chris
>
> ________________________________
>
> >
> > G10 and tool changes are not real queue busters - the answer is
> predictable.
>
> Well, here I disagree completely!
>
> G10 L1, G10 L10, G10 L11, G10 L2 are all queue busters, or at least should
> be.
> Changes of fixture tables should stop readahead, so any location that uses
> that
> fixture table will change location. Even if that might be predictable, if
> it is
> executed at the wrong time, all result will be rubbish.
> You have to distinct between setup of a fixture offsets (which usually
> happens
> in MDI-mode) and moving an actual active fixture to another location (I
> guess
> G10 L20 will be this one - so it is the only one, that might be not a queue
> buster), which might be part of the gcode file.
>
> For me, toolchange is of cause a queue buster. No question!
> Even if you use manually tool changes, you need to jog the tool away from
> workpiece, change the tool, apply new tool settings and narrow the tool
> tip to
> the location it was before.
>
> Only with atc this can be automated. And even with atc it makes absolutely
> no
> sense, optimize the path from before tool change with the path from after
> tool
> change - so what is the sense of making tool change not a queue buster?
>
>
>
>
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to