Pilot avoids putting all of the work offsets in the
> > state
> > > tag by making commands like G10 a queue-buster.
> > >
> > > -Rob
> > >
> > >
> > > On Tue, Mar 31, 2020, 8:50 AM Chris Morley >
> > > wrote:
> > >
>
On Tue, 31 Mar 2020 at 19:39, Chris Morley
wrote:
>
> How is changing the origin not give a predictable answer? and if it does
> then you don't have to stop the filling the queue.
M66 E0
G10 L2 Z#5399
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the espe
__
> From: Robert Ellenberg
> Sent: March 31, 2020 7:07 PM
> To: EMC developers
> Subject: Re: [Emc-developers] improve synchronization between backend and
> UI
>
> Chris, unfortunately G10 doesn't send any "motion" commands, it dire
#x27;s interesting to get into it a bit (and a little scary).
Chris
From: Robert Ellenberg
Sent: March 31, 2020 7:07 PM
To: EMC developers
Subject: Re: [Emc-developers] improve synchronization between backend and UI
Chris, unfortunately G10 doesn't send any
e for example for the concept that queue busters are
> not a free lunch to add willy nilly :)
> But pilotpath sets these as queue busters and it's seems to be working
> fine for them...
>
> Chris
> ____________
> From: Amit Goradia
> Sent: March 31, 202
it Goradia
Sent: March 31, 2020 5:43 PM
To: EMC developers
Subject: Re: [Emc-developers] improve synchronization between backend and UI
On Tue, 31 Mar, 2020, 9:43 pm Chris Morley,
wrote:
>
> I don't follow your reasoning of G10 being a queue buster.
> it shifts the origin - comp
On Tue, 31 Mar, 2020, 9:43 pm Chris Morley,
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 cha
ag by making commands like G10 a queue-buster.
> >
> > -Rob
> >
> >
> > On Tue, Mar 31, 2020, 8:50 AM Chris Morley
> > wrote:
> >
> > > All good Reinhard.
> > >
> > > You will probably become our new expert :)
> > > State
On Tue, 31 Mar 2020 at 17:42, Amit Goradia wrote:
>
> Are they included in the current state tags branch?
>
Note that there is a merge of current-master and statetags in
andypugh/statetags-200328
It fails some tests, but I am prepared to work on those if there is as much
interest as there seems
; Statetags needs some investigation - I think pilotpath uses it
> > successfully.
> > I'm not sure if it tags each gcode line or each motion command but i'm
> > sure it could be changed.
> > In the end motion needs know about gcode state for all this to work
> > prope
On Tue, 31 Mar, 2020, 9:09 pm Reinhard,
wrote:
> Hi,
>
> On Dienstag, 31. März 2020, 17:11:43 CEST Amit Goradia wrote:
> > We have added line numbers to each struct returned from rs274.
> >
> > I have asked one of my colleagues to update that to master branch and
> > publish it.
>
> Whow - that's
On Tue, 31 Mar 2020 at 17:13, Chris Morley
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.
G10 can also be used to change the tool table.
But
Hi Andy,
On Dienstag, 31. März 2020, 17:59:13 CEST andy pugh wrote:
> On Tue, 31 Mar 2020 at 16:07, Reinhard
> wrote:
> > It's like a C-compiler which does (part) of the linkers job, but so bad,
> > that lot of compilations units fail, as the compiler did not have compiled
> > a necessary module
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.
Tool changes - if you stop linuxcnc to jog then you are not running in auto
mode any more.
You can't pause and
On Tue, 31 Mar 2020 at 16:07, Reinhard
wrote:
It's like a C-compiler which does (part) of the linkers job, but so bad,
> that
> lot of compilations units fail, as the compiler did not have compiled a
> necessary module yet.
Sort-of.
The scheme is to run ahead as far as possible to keep the mot
On Tue, 31 Mar 2020 at 16:21, Amit Goradia wrote:
>
> We have added line numbers to each struct returned from rs274.
> I have asked one of my colleagues to update that to master branch and
> publish it.
How does this fit in with state-tags? I am curious how much redundancy
there would be here.
Hi Chris,
On Dienstag, 31. März 2020, 17:29:49 CEST Chris Morley wrote:
> >From my way of thinking, readahead of the interpreter is fine, as long as
> >it does not affect the state of the machine (and fixture settings is
> >machine property). The interpreter may only prepare all stuff for the task
Hi,
On Dienstag, 31. März 2020, 17:11:43 CEST Amit Goradia wrote:
> We have added line numbers to each struct returned from rs274.
>
> I have asked one of my colleagues to update that to master branch and
> publish it.
Whow - that's great. It's a bunch of work so far, changing all the functions
>From my way of thinking, readahead of the interpreter is fine, as long as it
>does not affect the state of the machine (and fixture settings is machine
>property). The interpreter may only prepare all stuff for the task executor,
>but as with current f-word behaviour, it is completely wrong, chang
Hi Reinhard,
We have added line numbers to each struct returned from rs274.
I have asked one of my colleagues to update that to master branch and
publish it.
Regards,
automata
On Tue, 31 Mar, 2020, 8:37 pm Reinhard,
wrote:
> Hi,
>
> On Dienstag, 31. März 2020, 16:19:01 CEST Robert Ellenberg
Hi,
On Dienstag, 31. März 2020, 16:19:01 CEST Robert Ellenberg wrote:
> Thanks for looking into this! I think state tags could solve your issue. I
> wrote state tags years ago for PathPilot's fork of LinuxCNC ...
Don't know about state tags (yet) and did not know PathPilot either.
After a quick l
On Tue, 31 Mar 2020 at 15:21, Robert Ellenberg wrote:
> For example, PathPilot avoids putting all of the work offsets in the state
> tag by making commands like G10 a queue-buster.
I think that any G10 or tool change should be a queue buster. I really
can't see any need to blend motion through t
know about gcode state for all this to work
> properly.
> I'm glad ur interested and motivated!
>
> Chris
> ________
> From: Reinhard
> Sent: March 31, 2020 12:36 PM
> To: EMC developers
> Subject: Re: [Emc-developers] improve synchronization between backend an
r all this to work properly.
I'm glad ur interested and motivated!
Chris
From: Reinhard
Sent: March 31, 2020 12:36 PM
To: EMC developers
Subject: Re: [Emc-developers] improve synchronization between backend and UI
Hi Chris
> But here is something to muse.
Hi Chris
> But here is something to muse.
> lets take the f code for instance it could be alone or with other commands.
> eg.
> g1 x 1 f6
> or
> f6
> g1 x1
>
> So how do you account for that when single stepping?
I'm not able to talk about my (possibly) 30th step, before I did the
So i don't know enough yet to say for sure.
But here is something to muse.
lets take the f code for instance it could be alone or with other commands.
eg.
g1 x 1 f6
or
f6
g1 x1
So how do you account for that when single stepping?
either way, currently (with fcode_message branch) the
26 matches
Mail list logo
