Re: [Emc-developers] Booleans in INI files.

{FALSE, TRUE} is common for booleans but do not know for linuxcnc. > Some booleans in INI take "ON", for example TWOPASS. > Others take "1" and "0" > > There is a suggestion in the code that YES / NO / OFF / ON might be > expected to work: > https://github.com/LinuxCNC/linuxcnc/blob/master/src/em

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Hi On Samstag, 11. April 2020, 05:54:54 CEST Robert Ellenberg wrote: > Reinhard, that's a great point. It looks like there's a clear value in > keeping the select / change steps separate if your ATC needs to pre-load a > tool. This is what I meant by Fanuc-style tool changes >

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Reinhard, that's a great point. It looks like there's a clear value in keeping the select / change steps separate if your ATC needs to pre-load a tool. This is what I meant by Fanuc-style tool changes , where on some systems the T command trigger

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Hi, On Samstag, 11. April 2020, 04:54:41 CEST Robert Ellenberg wrote: > Furthermore, you could eliminate > the M6 (since "changing" a tool doesn't necessarily imply a physical tool > change). For the slitting saw example, your code would look like this (T11 > = saw bottom, T12 = saw top). Sorry,

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

On Fri, 10 Apr 2020 at 22:46, David Bagby wrote: > An example which comes to mind is a slitting saw being used in a > > vertical mill. There is one physical tool for this scenario, but two > different TLO values may typically be in use. One value typically > corresponds to the top edge of the saw

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

That's an interesting point, and a great reason to not require that a tool have exactly one offset. I think there may be a solution that addresses all of these concerns: 1. A tool with no offset doesn't make sense 2. A single physical tool (saw top / bottom, face mill inserts) can have mo

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Quoted verbatim as Dave got a bounce, so it might not have made it to the list as a whole: On Fri, 10 Apr 2020 at 22:46, David Bagby wrote: > > > On 4/10/2020 4:25 AM, andy pugh wrote: > > > > > > It is already an INI file option. I am just proposing to make it default to > > on. > > > > There

[Emc-developers] Booleans in INI files.

Some booleans in INI take "ON", for example TWOPASS. Others take "1" and "0" There is a suggestion in the code that YES / NO / OFF / ON might be expected to work: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/ini/emcIniFile.cc#L50 But I am not sure that it does, having experimented a l

Re: [Emc-developers] builbot is stalled

On 4/10/20 12:41 PM, Chris Morley wrote: Hey Seb looks like there is a bot offline. Yeah, the buster-rtpreempt-i386 buildslave i made recently keeps having kernel panics. :-( I'll bounce it for now, thanks for the bug report. -- Sebastian Kuzminsky __

Re: [Emc-developers] builbot is stalled

Hi Chris, how are you? El vie., 10 abr. 2020 a las 15:43, Chris Morley () escribió: > Hey Seb looks like there is a bot offline. > > > Thanks > > Chris > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sour

[Emc-developers] builbot is stalled

Hey Seb looks like there is a bot offline. Thanks Chris ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] State-synch G-code.

On 2020-04-10 4:02 a.m., andy pugh wrote: On Fri, 10 Apr 2020 at 00:53, Chris Morley wrote: I could definitely see that in remap, though I thought you could do this already with python. and python not gcode is the way i would keep it. Python remaps are not a particularly convenient way to d

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

On Freitag, 10. April 2020, 13:25:04 CEST andy pugh wrote: > LinuxCNC offers G43.1 to apply a temporary tool offset. Oh, I overlooked that. Thanks for the hint. Will check asap Reinhard ___ Emc-developers mailing list Emc-developers@lists.source

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Hi, On Freitag, 10. April 2020, 14:19:27 CEST andy pugh wrote: > On Fri, 10 Apr 2020 at 12:45, Reinhard wrote: > > I have. And some of my colleagues do it cause of lazyness for jobs with a > > single tool only. > > Though presumably in that case there wouldn't be a G43 anywhere in the code? Th

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

> -Original Message- > From: Gene Heskett [mailto:ghesk...@shentel.net] > Sent: Friday, April 10, 2020 12:52 AM > To: emc-developers@lists.sourceforge.net > Subject: Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8 > > On Thursday 09 April 2020 23:19:11 Ken Strauss wrote: > >

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

On Fri, 10 Apr 2020 at 12:45, Reinhard wrote: > I have. And some of my colleagues do it cause of lazyness for jobs with a > single tool only. Though presumably in that case there wouldn't be a G43 anywhere in the code? > For that 3D-jobs we had special tool entries with length and diameter set

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

On Freitag, 10. April 2020, 13:25:04 CEST andy pugh wrote: > There is already an annoying inconsistency in behaviour with this. Reduce inconsistency is always a good goal :) On Freitag, 10. April 2020, 13:25:04 CEST andy pugh wrote: > Has anyone here ever deliberately coded a tool change without

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

On Fri, 10 Apr 2020 at 04:04, Reinhard wrote: > In Heidenhain you have the TD- and TL-words to change Diameter and/or Length. ... > So for me, its a wrong behaviour, allow to retain G43 without the possibility > to change toollength and tooldiameter in GCode. LinuxCNC offers G43.1 to apply a tem

Re: [Emc-developers] State-synch G-code.

Hi Andy, On Freitag, 10. April 2020, 12:58:22 CEST andy pugh wrote: > Imagine that you have a smart speaker and a phone app that lets you > change the volume, but that the volume must never be allowed to change > during a song. Strange, but nice sample ;) > The app can make sure that the music p

Re: [Emc-developers] State-synch G-code.

On Fri, 10 Apr 2020 at 00:53, Chris Morley wrote: > > I could definitely see that in remap, though I thought you could do this > already with python. > > and python not gcode is the way i would keep it. Python remaps are not a particularly convenient way to do tool changes that need axis movement

Re: [Emc-developers] State-synch G-code.

On Fri, 10 Apr 2020 at 06:47, Reinhard wrote: > I guess, the real problem is, that the interpreter performs tasks it should > not. Normally no sync between motion and interpreter is (or should be) needed. Maybe a way to think of this is as an analogous problem. Imagine that you have a smart spe

Re: [Emc-developers] State-synch G-code.

On Fri, 10 Apr 2020 at 06:20, Amit Goradia wrote: > The problem is restoring the current state after abort. No, that's a different problem. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — G

Re: [Emc-developers] State-synch G-code.

On Fri, 10 Apr 2020 at 03:45, Johannes Fassotte wrote: > > I don’t know. This is not something that I have looked into. ... > I’m I thinking wrong? Convert some to kernel modules like in OpenCN? This is actually the cause of the problem. (though calling it a problem is not really correct) At lea