I thought it might be helpful to overview our understanding of the
current process. Hopefully the gurus will straighten out any errors I
make here - but a least it's a talking point.
This is a very simplified description of the two processes running to
turn gcode into machine motion. I didn't
On Sunday 19 April 2020 02:22:12 Reinhard wrote:
> On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:
> > Take feedrate.
> >
> > Right now feedrate by it's self does not cause a motion command.
> >
> > Motion is the only part that syncs with the real world.
> >
> > So if you single
On Sonntag, 19. April 2020, 09:06:26 CEST Chris Morley wrote:
> Motion does the trajectory planning which can't be preplanned by
> interpreter/task because of things like overides and spindle sync
Well, in my mind, task-manager should do all motion planning respect to tool
tip. Tool tip moves in
On Sonntag, 19. April 2020, 09:00:16 CEST Chris Morley wrote:
> Yes I agree but it shows the problem of stepping code when motion is not
> one to one with gcode.
May be I don't get the whole picture, but at the moment, I can't see any
reason for that requirement.
Current single stepping is done in task with little part implemented in
motion.
Task fetches one line ( there is some debate about line classification, but
more on that later) from rs274. Then does some checking on it and passes it
to motion. At this point, in the checking part, task does single
On 2020-04-18 11:01 p.m., Reinhard wrote:
On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
Motion does the movement planning so would be the one to know when to stop
before breaking limits.
Well, if motion does the movement planning, than motion performs taskmanagers
job.
On 2020-04-18 11:22 p.m., Reinhard wrote:
On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:
Take feedrate.
Right now feedrate by it's self does not cause a motion command.
Motion is the only part that syncs with the real world.
So if you single step over a F code only line it's
On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:
> Take feedrate.
>
> Right now feedrate by it's self does not cause a motion command.
>
> Motion is the only part that syncs with the real world.
>
> So if you single step over a F code only line it's ignored because
> motion won't
On 2020-04-18 11:04 p.m., Reinhard wrote:
On Sonntag, 19. April 2020, 07:58:52 CEST Chris Morley wrote:
The problem become that motion commands and gcode are not one to one.
Well, that does not mean, that it should cause problems.
When programming G-code (at the machine) there can be several
On Sonntag, 19. April 2020, 07:58:52 CEST Chris Morley wrote:
> The problem become that motion commands and gcode are not one to one.
Well, that does not mean, that it should cause problems.
When programming G-code (at the machine) there can be several commands in one
line. Its the interpreters
On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
> Motion does the movement planning so would be the one to know when to stop
> before breaking limits.
Well, if motion does the movement planning, than motion performs taskmanagers
job. Movement planning is not motion.
And if motion
On 2020-04-18 10:50 p.m., Reinhard wrote:
On Sonntag, 19. April 2020, 07:45:13 CEST Chris Morley wrote:
Now if you want motion to do such things as step each line of gcode,
Well, motion should not step.
It's the task-manager, that should step.
The difference of a motion command in single
On 2020-04-18 10:37 p.m., Reinhard wrote:
Hi Chris,
I think, you did not got me right.
I don't talk about making motion more intelligent, but instead making
interpreter less intelligent and of cause less machine dependent.
Yes I don't understand how this would work as you describe it.
Or
On Sonntag, 19. April 2020, 07:45:13 CEST Chris Morley wrote:
> Now if you want motion to do such things as step each line of gcode,
Well, motion should not step.
It's the task-manager, that should step.
The difference of a motion command in single step or auto mode is the speed at
begin and
On 2020-04-18 10:35 p.m., Robert Ellenberg wrote:
Well it does.
ie G10 adjust the tool offsets.
How tool offsets work are defined by the Gcode rules.
We could produce a different interpreter that converts ChrisMorley code
into motion moves.
maybe it doesn't have tool offsets, linuxcnc
Hi Chris,
I think, you did not got me right.
I don't talk about making motion more intelligent, but instead making
interpreter less intelligent and of cause less machine dependent.
All position and execution logic should happen in the middle between
interpreter and motion. I don't see the
> Well it does.
>
> ie G10 adjust the tool offsets.
>
> How tool offsets work are defined by the Gcode rules.
>
> We could produce a different interpreter that converts ChrisMorley code
> into motion moves.
>
> maybe it doesn't have tool offsets, linuxcnc motion would be fine with it.
>
>
> It's
On 2020-04-18 9:37 p.m., Reinhard wrote:
On Sonntag, 19. April 2020, 06:20:35 CEST Chris Morley wrote:
The Gcode interpreter is what defines the concept of offsets tool and
wok offsets and all other Gcode related concepts..
No! Definitely not!
Well it does.
ie G10 adjust the tool offsets.
On Sonntag, 19. April 2020, 06:20:35 CEST Chris Morley wrote:
> The Gcode interpreter is what defines the concept of offsets tool and
> wok offsets and all other Gcode related concepts..
No! Definitely not!
Think about all languages that control a mill. There are may be thousands out
there. But
On Mittwoch, 15. April 2020, 15:24:11 CEST Juergen Gnoss wrote:
My idea is, sorting out the g-code interpreter and make it loadable modules,
where we choose at configuration level what machine we like to have. Just
as with kinematic module ...
You can, there is a stand alone interpreter.
On Samstag, 18. April 2020, 22:15:11 CEST Chris Morley wrote:
> On 2020-04-18 8:27 a.m., Reinhard wrote:
> > On Samstag, 18. April 2020, 17:15:48 CEST Robert Ellenberg wrote:
> >> Reinhard, I strongly recommend using G10 for this because the NML
command
> >> doesn't update the offsets in interp.
On 2020-04-18 8:27 a.m., Reinhard wrote:
Hi Robert,
On Samstag, 18. April 2020, 17:15:48 CEST Robert Ellenberg wrote:
Reinhard, I strongly recommend using G10 for this because the NML command
doesn't update the offsets in interp. This would cause subsequent motions
to have the wrong offset
Hi Robert,
On Samstag, 18. April 2020, 17:15:48 CEST Robert Ellenberg wrote:
> Reinhard, I strongly recommend using G10 for this because the NML command
> doesn't update the offsets in interp. This would cause subsequent motions
> to have the wrong offset values, and get the machine into an
Reinhard, I strongly recommend using G10 for this because the NML command
doesn't update the offsets in interp. This would cause subsequent motions
to have the wrong offset values, and get the machine into an inconsistent
state.
In general, I'd be very wary of bypassing G-code for this kind of
Hi Andy,
thank you for your fast response!
On Samstag, 18. April 2020, 16:17:56 CEST andy pugh wrote:
> On Sat, 18 Apr 2020 at 15:12, Reinhard
wrote:
> > what is the preferred way to set fixture offset (coordinate values) from
> > ui?
>
> Looking at the code, none of the existing UIs uses the
On Sat, 18 Apr 2020 at 15:12, Reinhard wrote:
> what is the preferred way to set fixture offset (coordinate values) from ui?
>
> Use nml-message EMC_TRAJ_SET_G5X or assemble a G10 L2
Looking at the code, none of the existing UIs uses the NML message.
And in Touchy the button brings up an
Hi,
what is the preferred way to set fixture offset (coordinate values) from ui?
Use nml-message EMC_TRAJ_SET_G5X or assemble a G10 L2 and send it as MDI-
command under the hood?
Reinhard
___
Emc-developers mailing list
27 matches
Mail list logo
