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