Re: [Emc-developers] fixture offset

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 kn

Re: [Emc-developers] fixture offset

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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75

Hi Jürgen, I guess you really understood my writings. On Sonntag, 19. April 2020, 08:03:30 CEST Juergen Gnoss wrote: > If the motion queue is made of a few rolling buffers and does pull the > content of that buffers from task-manager rather than get pushed into it, > it's far more easy to keep tr

Re: [Emc-developers] fixture offset

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 j

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75

I think what the interpreter is actually doing is a result of different interpretation of the term "interpreter" There is a difference in interpreting g-code or user commands/inputs, even further in the sense of g-code, where does the g-code actual come from? A file or MDI. I think I'm not the o

Re: [Emc-developers] fixture offset

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 do

Re: [Emc-developers] fixture offset

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 ste

Re: [Emc-developers] fixture offset

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 m

Re: [Emc-developers] fixture offset

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 en

Re: [Emc-developers] fixture offset

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 motio

Re: [Emc-developers] fixture offset

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

Re: [Emc-developers] fixture offset

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

Re: [Emc-developers] fixture offset

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.

Re: [Emc-developers] fixture offset

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

Re: [Emc-developers] fixture offset

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

Re: [Emc-developers] fixture offset

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

[Emc-developers] Document errors

A forum user posted some PDF doc errors in the way some graphics appear: > They do appear ok in the HTML docs:

Re: [Emc-developers] wrecked on pi4

On Saturday 18 April 2020 18:02:47 andy pugh wrote: > On Sat, 18 Apr 2020 at 21:12, Gene Heskett wrote: > > git branch --set-upstream 2.8 origin/2.8. > > which says I am 600 commits ahead, crazy. > > should I just blow it away. > > Yes. > But a reset --hard should be enough. wasn't, blew it awa

Re: [Emc-developers] wrecked on pi4

On Sat, 18 Apr 2020 at 21:12, Gene Heskett wrote: > git branch --set-upstream 2.8 origin/2.8. > which says I am 600 commits ahead, crazy. > should I just blow it away. Yes. But a reset --hard should be enough. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed fo

Re: [Emc-developers] fixture offset

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 va

Re: [Emc-developers] wrecked on pi4

On Saturday 18 April 2020 14:46:06 Gene Heskett wrote: > On Saturday 18 April 2020 13:44:13 andy pugh wrote: > > On Sat, 18 Apr 2020 at 18:19, Gene Heskett > > wrote: > > > last nights test build must have done git pull at a bad time, 181 > > > of the runtests failed. > > > > Which LinuxCNC versi

Re: [Emc-developers] wrecked on pi4

On Saturday 18 April 2020 13:44:13 andy pugh wrote: > On Sat, 18 Apr 2020 at 18:19, Gene Heskett wrote: > > last nights test build must have done git pull at a bad time, 181 of > > the runtests failed. > > Which LinuxCNC version? > > There was a faulty commit to 2.8, now reversed. But if you pul

Re: [Emc-developers] wrecked on pi4

On Saturday 18 April 2020 13:17:04 Gene Heskett wrote: > last nights test build must have done git pull at a bad time, 181 of > the runtests failed. > > I'm rerunning that script again. > > Cheers, Gene Heskett Its Ok this time Cheers, Gene Heskett -- "There are four boxes to be used in defense

Re: [Emc-developers] wrecked on pi4

On Sat, 18 Apr 2020 at 18:19, Gene Heskett wrote: > > last nights test build must have done git pull at a bad time, 181 of the > runtests failed. Which LinuxCNC version? There was a faulty commit to 2.8, now reversed. But if you pulled 2.8 in that period you might need to reset --hard origin/2.8

[Emc-developers] wrecked on pi4

last nights test build must have done git pull at a bad time, 181 of the runtests failed. I'm rerunning that script again. 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 des

Re: [Emc-developers] fixture 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 incons

Re: [Emc-developers] fixture offset

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 thi

Re: [Emc-developers] fixture offset

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 N

Re: [Emc-developers] fixture offset

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 explici

[Emc-developers] fixture offset

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 Emc-developers@lists.sourcef