Re: [Emc-developers] fixture offset

[Chris Morley]

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 include tool I/O etc or manual 
commands. Basic auto or MDI process.


task (userspace- runs continuously)
    -calls interpreter to read gcode line
    -interp updates an internal settings structure
    - if the line has a motion command adds it to queue.
    - updates status on some things (not in sync with machine)
    repeat

Motion (realtime - runs continuously)
    -reads queue for next command
    -updates status on some things (in sync with machine)
    -reads HAL inputs for motion/spindle
    - plans trajectory (adjusts for overrides/threading etc)
    -outputs HAL pins for motion/spindle
    repeat

Once we know this is rightish then we can expand on it.

Hopefully in the end I can pull together some enough for documents for 
the future so more people can get involved. It also is helping wrap my 
head around linuxcnc internals.



Chris


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Gene Heskett]

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 step over a F code only line it's ignored because
> > motion won't know about it until there is an actual move.
>
> and in my understanding this is a bug - not a feature!

Yes.  No other option can be applicable.
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 3D-coordinate space and other axis may help on tool-
shaft orientation without changing tooltip location.

So task-manager cares about theoretically (let me name it so) motion, whereas 
motion takes out physical motion.
Taskmanager knows anything about fixtures, tool-length, radius- and length 
properties ...
... but taskmanager does not know anything about physical machine (kinematics 
and the like), which means, it tells motion to move tooltip from location A to 
location B, but only motion knows how to do that (kinematics and all that 
things go into here).

Trajectory planning should not be based on overwrite values. Planning could be 
done with programmed feed rate. Only motion should care about overwrite values 
and changes projected speed from taskmanager.
I believe, that overwrite values don't change the quality of trajectory 
planning. That should work based on angular changes (or similar geometric 
based properties) from one motion to the other.

In my daily work, overwrite values are used to lower or stop programmed 
motion. If overwrite button is used, NO user cares about path optimization. 
It's irrelevant in that moment. The only important question is, that the 
machine stops as fast as the button hits zero. And the importance of that 
requirement is proportional to the moving speed :)

But even if only motion cares about overwrite values, UI should be able to 
reflect changes of overwrite values with acceptable delay. UI is not that 
timecritical than motion, so delay of 0.5s might be quite ok.
But UI is supposed to show any machine properties at time.
You can try to program feed or spindle speed without any motion. On 
professional machines, the UI shows the result of the programmed change.
You can program spindle speed even if the spindle is not turning.
Motion and programming is separated completely.

Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Amit Goradia]

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 stepping.
However, for the commands that have already been queued to motion, task
tells motion to single step those commands too.
Beyond this task will only send one command at a time to motion which will
execute them while task waits for that execution to complete.
At this time (during single stepping) read ahead from rs274 is not stopped.
That goes on to for us over or cannon queue is full or task is waiting for
explicit sync command i.e tool change m66 etc.

What qualifies as single line of gcode from rs274 is decided by the canon
commands. Canon  commands are used to send commands to task from rs274.
Canon commands are lined up by rs274 into a canon queue for task to read
from. A bunch of cannon commands like mcodes don't have line numbers in
them. Thus task cannot stop for them during single stepping. If we add line
numbers to those cannon commands, task should automatically start stopping
for them during single stepping.
Task implements a simple line number check while waiting for single
stepping, which is "Keep sending commands to motion to execute till we
don't see a different line number".

Hope this explains helps.

- automata


On Sun, 19 Apr, 2020, 11:33 am 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. Movement planning is not motion.
> And if motion does the movement planning, it should of cause know about
> single
> step or auto mode and should know about g-code lines and machine commands.
>
> Very weird design.
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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. Movement planning is not motion.
And if motion does the movement planning, it should of cause know about single
step or auto mode and should know about g-code lines and machine commands.

Very weird design.



Motion does the trajectory planning which can't be preplanned by 
interpreter/task because of things like overides and spindle sync





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 ignored because
motion won't know about it until there is an actual move.

and in my understanding this is a bug - not a feature!


Yes I agree but it shows the problem of stepping code when motion is not 
one to one with gcode.


unless you put task in realtime side it's hard to work around.



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 know about it until there is an actual move.

and in my understanding this is a bug - not a feature!




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 commands in one
line. Its the interpreters job to know sequencing of commands and when they
arrive task-manager, they already should be single commands.
Though multiple commands can share the same source line.

Reinhard


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 know about it until there is an actual move.





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 job to know sequencing of commands and when they 
arrive task-manager, they already should be single commands.
Though multiple commands can share the same source line.

Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 does the movement planning, it should of cause know about single 
step or auto mode and should know about g-code lines and machine commands.

Very weird design.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 step or auto mode is the speed at
begin and end of that motion.
In singlestep both start and end speed are set to 0 - in automode they
correspond to the neighbor motion and may be on path parameters too.


Reinhard


The problem become that motion commands and gcode are not one to one.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 maybe I don't understand the difference between it and how it's done now.


All position and execution logic should happen in the middle between
interpreter and motion. I don't see the need to change motion or io, but I see
the need to extract lot of functional code from interpreter into - may be a
new created instance in front of, or to) taskmanager.
Taskmanager should know about offsets, tool length and orientation, execution
lines, machine commands and io commands, and optimization of motion moves
(recalculation of speeds). What ever logic the cnc-controller is able to
perform, the taskmanager is the one, that should know about it.

Then what would the interpreter do?

Motion should not know about softlimits or endstops or whatever.
Motion just moves from A to b in given path.


Reinhard

I think motion should know about end stops and limits - I have no idea 
at the moment where that is accounted for but my guess is motion. Motion 
does the movement planning so would be the one to know when to stop 
before breaking limits.





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 end of that motion.
In singlestep both start and end speed are set to 0 - in automode they 
correspond to the neighbor motion and may be on path parameters too.


Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 motion would be fine with it.


It's the interpreter that converts users made code into motion moves.
This does seem to be the crux of the problem - motion needs to know some
things about the parent language that the motion moves comes from. This
is what state tags does.


Chris, one little nitpick: state tags exist BECAUSE motion doesn't know
anything about the interpreter state. It's a way for motion to report what
the state was that generated a motion command, without having to understand
or use any of it directly. There are a few small exceptions (like peeking
at the spindle command speed to check if a synced move is safe), but mostly
motion doesn't care about the state tag.


Thanks for correcting me I'm learning as I discuss.

Now if you want motion to do such things as step each line of gcode, 
then motion would start to need to know more what the gcode, would it 
not? I guess not but we would need to have more motion commands that are 
used to sync things? I am not up on statetags (or really any of this 
much - trying to get it clear in my head.)


Chris




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 need to change motion or io, but I see 
the need to extract lot of functional code from interpreter into - may be a 
new created instance in front of, or to) taskmanager.
Taskmanager should know about offsets, tool length and orientation, execution 
lines, machine commands and io commands, and optimization of motion moves 
(recalculation of speeds). What ever logic the cnc-controller is able to 
perform, the taskmanager is the one, that should know about it.

Motion should not know about softlimits or endstops or whatever.
Motion just moves from A to b in given path.


Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Robert Ellenberg]

> 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 the interpreter that converts users made code into motion moves.
> This does seem to be the crux of the problem - motion needs to know some
> things about the parent language that the motion moves comes from. This
> is what state tags does.
>

Chris, one little nitpick: state tags exist BECAUSE motion doesn't know
anything about the interpreter state. It's a way for motion to report what
the state was that generated a motion command, without having to understand
or use any of it directly. There are a few small exceptions (like peeking
at the spindle command speed to check if a synced move is safe), but mostly
motion doesn't care about the state tag.

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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.

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 the interpreter that converts users made code into motion moves. 
This does seem to be the crux of the problem - motion needs to know some 
things about the parent language that the motion moves comes from. This 
is what state tags does.




Think about all languages that control a mill. There are may be thousands out
there. But all mills do the same kind of motion.
So the interpreter should transform cnc-language into binary command. With
that binary command all langugages are the same, so another intelligence can
think about what needs to be done.


This is what it does now more or less. The Interpreter/task converts to 
motion moves.


but motion moves don't know anything about gcode.




Any interpreter should not have any state or know anything about the machine.
Well, in my mind ;)

The difference between cnc-languages is how elegant the user can code motion at
the machine. Some languages are elegant, others are dumb, but all motion is
the same.

If using CAM cnc-language does not matter any more.
CAM creates motion from geometrics, which than get translated by a
postprocessor into cnc-language.
At machine, the interpreter is the counterpart to postprocessor - eliminating
the language from motion commands.

Well, theory from wonderland :)


cheers Reinhard

Sound like you would like to convert gcode to agnostic 'byte' code 
(sorta like python does) and have motion run byte code. It means motion 
would need to know about high level concepts like offsets. So a lot more 
code would need to run in realtime. I don't know about the practical 
problems of that I assume that is the reason the interpreter in user space.



Chris


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 all mills do the same kind of motion.
So the interpreter should transform cnc-language into binary command. With 
that binary command all langugages are the same, so another intelligence can 
think about what needs to be done.

Any interpreter should not have any state or know anything about the machine.
Well, in my mind ;)

The difference between cnc-languages is how elegant the user can code motion at 
the machine. Some languages are elegant, others are dumb, but all motion is 
the same.

If using CAM cnc-language does not matter any more.
CAM creates motion from geometrics, which than get translated by a 
postprocessor into cnc-language.
At machine, the interpreter is the counterpart to postprocessor - eliminating 
the language from motion commands.

Well, theory from wonderland :)


cheers Reinhard





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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. There is even a sim config 
to show case it.


It doesn't do much but prove that it is possible.



On Samstag, 18. April 2020, 22:15:11 CEST Chris Morley wrote:

The motion component only runs raw motion commands.

Well, neither the interpreter, nor motion should care about offsets!

The Gcode interpreter is what defines the concept of offsets tool and 
wok offsets and all other Gcode related concepts..


Have to keep in mind motion was made as a general purpose controller not 
specifically a gcode controller. Though I am sure Gcode specific things 
have crept in.



Chris



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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. This would cause subsequent motions
> >> to have the wrong offset values, and get the machine into an inconsistent
> >> state.
> > 
> > Puh - the interpreter is getting from bad to worse :(
> 
> This actually makes sense to me, the interpreter is what defines offsets

Even if that was right, it makes no sense at all!

The interpreter does lot of tasks it should not, so that misconception is 
source of all evil.

May be you are willing to think about a redesign once 2.8 is done.

Then ideas like proposal of Juergen Gnos could be realized:

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 ...


On Samstag, 18. April 2020, 22:15:11 CEST Chris Morley wrote:
> The motion component only runs raw motion commands.

Well, neither the interpreter, nor motion should care about offsets!

In my way of thinking, interpreters job is to validate textual G-code from 
users and transform that into a binary command.
Thinking in a pluggable concept, interpreter should be done at nml-command 
level, so output of interpreter should be the same as internal sent nml-
command.
Its then the job of the task-manager (or whatever you name the central 
intelligence), to care for all the logic, which ends in "simple" commands to 
motion and io.

If responsability is new thought and redistributed, no line-number or g- or m-
code will get lost during execution, and single step versus auto execution 
determines just the depth of motion-queue optimization.

> Is there a reason we can't allow G10 in manual mode? As long as the
> machine is homed I can't think of a reason. Because I agree switching to
> MDI/AUTO to do manual things is annoying and there is lots of this done
> in the screens. It's a major PITA to manage mode changes in screens.
> 
> I'm thinking the whole MAN/MDI/AUTO mode process should be evaluated.

Well, together with rethinking the interpreter this would make lot of sense.

> ... why do we need the interpreter to decide what can and can't be done.

Exactly what I think.


Reinhard






___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Chris Morley]

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 values, and get the machine into an inconsistent
state.

Puh - the interpreter is getting from bad to worse :(


This actually makes sense to me, the interpreter is what defines offsets 
IFAIK.


The motion component only runs raw motion commands.

Offsets are a hirer level concept.

For instance you could build an new interpreter that doesn't have 
offsets and the motion component should be able to run it fine.



In general, I'd be very wary of bypassing G-code for this kind of thing.


Thats not to say we couldn't make commands specific to do manual things?

I'm a little fuzzy on how manual commands get done. Am I right that 
manual spindle commands bypass the interpreter process altogether?



Ok, so if something can be done by G-code, I should use G-code?
Ok, I will do so.

NML-experience was strange enuf ...

First try in manual mode failed.
So I tried to switch mode to mdi, but that failed too.
... and executing such a command in auto-mode - hairrising.

So I go for hidden gcode ...
Guess I have to use appmode MDI for sending G-codes ...
... but for that, I have to change whole app, as MDI-mode is intended as user
action :(

Miss an appmode for internal communication.


Thanks for the hints!

Reinhard

Is there a reason we can't allow G10 in manual mode? As long as the 
machine is homed I can't think of a reason. Because I agree switching to 
MDI/AUTO to do manual things is annoying and there is lots of this done 
in the screens. It's a major PITA to manage mode changes in screens.


I'm thinking the whole MAN/MDI/AUTO mode process should be evaluated.

Aside from a couple basic rules such as don't allow running (most of 
the) manual commands while running a program, why do we need the 
interpreter to decide what can and can't be done.


Same with MDI and AUTO what really is the difference to the interpreter?

Chris


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 inconsistent
> state.

Puh - the interpreter is getting from bad to worse :(

> In general, I'd be very wary of bypassing G-code for this kind of thing.

Ok, so if something can be done by G-code, I should use G-code?
Ok, I will do so.

NML-experience was strange enuf ...

First try in manual mode failed.
So I tried to switch mode to mdi, but that failed too.
... and executing such a command in auto-mode - hairrising.

So I go for hidden gcode ...
Guess I have to use appmode MDI for sending G-codes ...
... but for that, I have to change whole app, as MDI-mode is intended as user 
action :(

Miss an appmode for internal communication.


Thanks for the hints!

Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Robert Ellenberg]

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 thing.
For example, calling canon commands directly in remap can be risky if you
don't meticulously update the interpret state at the same time). NML
commands have the same kind of issue.

On Sat, Apr 18, 2020, 10:51 AM Reinhard 
wrote:

> 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 NML message.
>
> Hm, for me an UI is to hide complicated stuff from user and help on easy
> use.
> So I'd prefer nml as it is invisible to the user.
> ... and currently every actions from my app goes through nml.
>
> Another question: when I'm editing files, tools or fixtures, the
> application
> state is set to manual.
> When I send the nml to change fixture offset, I get the error, that
> backend
> can't do that in manual mode.
>
> May be I misunderstood manual mode?
>
> Which mode is appropriate to send such a non-motion nml-message?
>
>
> Reinhard
>
>
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[Reinhard]

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 NML message.

Hm, for me an UI is to hide complicated stuff from user and help on easy use. 
So I'd prefer nml as it is invisible to the user.
... and currently every actions from my app goes through nml.

Another question: when I'm editing files, tools or fixtures, the application 
state is set to manual.
When I send the nml to change fixture offset, I get the error, that backend 
can't do that in manual mode.

May be I misunderstood manual mode?

Which mode is appropriate to send such a non-motion nml-message?


Reinhard






___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] fixture offset

[andy pugh]

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 explicit G10 command in the MDI
window.

But I don't know if anyone is likely to express an actual preference here :-)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers