Chris wrote:
>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.
That depends what you mean with "realtime side"
real time means, things have to get executed in a defined amount of time
starting from firing the command.
We can have task run in userspace, but it splits workload over a lot of modules
(processes)
So meet that timing requirements isn't an issue on actual multi core machines.
Work split between g-code interpreter, task manager and motion in single step:
G00 X.. Y... Z...
G01 X... Y... F...
It really happens that on the G01 line, feed is set for subsequent operations,
it happens (internally)
in a single instruction, before TP is calculating the move to the new location.
g-code interpreter and task has to know the order of executing several commands
on a single line.
If I single step through g-code it doesn't bother me if I don't see any machine
movement on a
only F... line, but see the result in a pin or so while looking at the related
variable/pin in HAL.
The operator may not look at hal, but should not expect a physical move on a F
or offset changing line.
Reinhard wrote:
>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 :)
That's not the case for all lcnc users.
Override values are also often used to optimize cutting.
While job setup, you program a low (secure) feed in g-code and while running
the program
you crank up the feed to an optimal value using override. Then you change the
g-code for
a production run.
Taking that scenario in account, yes trajectory, especially path blending
matters.
ju
________________________________
From: emc-developers-requ...@lists.sourceforge.net
<emc-developers-requ...@lists.sourceforge.net>
Sent: Sunday, April 19, 2020 8:18 AM
To: emc-developers@lists.sourceforge.net <emc-developers@lists.sourceforge.net>
Subject: Emc-developers Digest, Vol 168, Issue 79
Send Emc-developers mailing list submissions to
emc-developers@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/emc-developers
or, via email, send a message with subject or body 'help' to
emc-developers-requ...@lists.sourceforge.net
You can reach the person managing the list at
emc-developers-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emc-developers digest..."
Today's Topics:
1. Re: fixture offset (Chris Morley)
2. Re: fixture offset (Amit Goradia)
3. Re: fixture offset (Reinhard)
4. Re: fixture offset (Reinhard)
----------------------------------------------------------------------
Message: 1
Date: Sun, 19 Apr 2020 00:06:26 -0700
From: Chris Morley <chrisinnana...@hotmail.com>
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] fixture offset
Message-ID:
<mwhpr05mb33600d264d39ee9f755ad522c0...@mwhpr05mb3360.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 2
Date: Sun, 19 Apr 2020 12:16:03 +0530
From: Amit Goradia <amitgora...@gmail.com>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] fixture offset
Message-ID:
<CAG_j_bDUo1OENxjjHB_scaJJ=0ki8zeo2ch23+tguq2es0b...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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, <reinha...@schwarzrot-design.de>
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
>
------------------------------
Message: 3
Date: Sun, 19 Apr 2020 09:15:17 +0200
From: Reinhard <reinha...@schwarzrot-design.de>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] fixture offset
Message-ID: <1644621.a0pevgK91x@django019>
Content-Type: text/plain; charset="us-ascii"
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.
------------------------------
Message: 4
Date: Sun, 19 Apr 2020 09:37:30 +0200
From: Reinhard <reinha...@schwarzrot-design.de>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] fixture offset
Message-ID: <2084521.iirOpRrRXk@django019>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------
End of Emc-developers Digest, Vol 168, Issue 79
***********************************************
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
