At the moment I'm on Reinhard's page thinking that TP has to be done i a
separate module
rather than going to happen in motion.
But maybe I doesn't see the full picture.
What are the key factors why TP actually happens in motion?
Sure, there are some occasions where trajectory needs to be recalculated, even
after they
made it already to the part where actual iron gets moved.
Implementing it the way I described before,
motion just does moving iron and has several motion queue buffers.
movements describing
G00 X... Y...
G01 X... Y... F...
G02 I... J... F...
has been sent already to three of motions buffers
G00 is done and disappears from motions buffers.
G01 move is half the way done, while the operator moves the feed override
slider.
Now, what is what actual happens and what would we expect to happen.
Does motion actual recalculate the remaining part of the G01 move in order to
run the
new feed rate or does it apply the new feed rate to the G02 moves?
juP
________________________________
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
