Re: [Emc-users] G71 lathe roughing cycle
Quote: As far as I know Fanuc don't use UW for axis in lathes or turning centres, they use XYZABC and I believe they also made two co-coordinated and interlinked controls with two sets of XZ - but I've never come across one. I think they used X_ Y_ Z_ for the second toolpost on that control. I've also seen it without the UW words at all, but can't remember what control. They do seem a bit superfluous and are optional on some. No great shakes to program the actual size the roughing cycle is going to cut, rather than the finished size plus an allowance. Steve Blackmore -- End Quote. Not sure how you were ever able to successfully run a FANUC controlled lathe WITHOUT running into U and W commands. I use Fanuc 0T, 10T, 16T, 18T, 21T and U W are used in all of them. If nothing else the homing line command uses them G0 G28 U0. W0.; Its also used for radius calls, incremental taper definitions, tool offsets and more. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
here is a complete example for a 'gcode recorder and playback' based on remapped codes. http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/list-recorder-by-remap unpolished - just to show the principle. Preview and progress display work as well as line number tracking. usage: pull, build, then: $ cd configs/sim/remap/list-recorder $ linuxcnc list-recorder.ini - Michael Am 27.08.2012 um 19:35 schrieb Michael Haberler: Am 27.08.2012 um 18:35 schrieb Ben Potter: Michael, I'll have to think about this a bit, but on first reading I like it. My initial impressions are: 1) If I'm reading you right, the profile block would need to be defined before any call to it. That said, it wouldn't actually execute it, merely store it. 2) No C++ maintenance to worry about, and avoids the somewhat hackish method I was looking at to grab the profile data 3) Leaves N words still unused all above: yes 4) Requires a new set of g-codes to be learned that are only used for profile definitions not really, beyond adding an offset to the base Gcode. They should exactly mirror their G0,G1,G3 cousins in parameters, and I think they could actually executed eventually by resorting to their builtin semantics. See 3.3.4. Advanced example: Remapped codes in pure Python under http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_the_em_argspec_em_parameter_a_id_remap_argspec_parameter_a - you will find a recursive call of the interpreter in a remap there. 5) As per Ralph Stirling's reply to this, this creates a generalised method for defining arbitrary profiles - which can then be used within any remap code. Possible uses on mills/routers too yes 6) P probably conflicts with arcs (where it refers to turns), but I can't imagine a 2d profile where turns are valid, I suppose it depends on whether this is generalised to 3 axis, or to 2 axis + plane definition I just picked 'P' as I was too lazy to check the manual for conflicts - any free word does it 7) Completely different method to other controllers I can't see any of those being a particular problem, but it does break compatibility with other controllers further than the original proposal. Let me be candid on that: I think the other controllers method is a real, total kludge, and I dont think compatibility is a great virtue in that case. What this method does is redefine the semantics of a G-code block *depending on its block number*, which the manual so far declared as optional and meaningless. Just think through what this does to run from line - there goes your tool, bang. It also introduces a new block structure and intra-line dependency which didnt exist yet. I mean RS274NGC is a very limited language so folks have all sorts of ideas but we must aim to reduce the shoot-into-foot potential as good as we can. The method I proposed does involve new codes, and it relies on side effects in Python to accumulate a data structure. but it doesnt change the semantics of the language in an ad-hoc way for a single feature. And it doesnt break run-from-line, brittle as that is. I'll save a diff of where I'm up to on the C++ route in case that ends up being a better option, and play around with this a bit. It's probable that the actual G71 syntax could be very similar to any given existing control, with just the block definition needing rework. Since it's in python, the syntax could even be changed to suit a given persons preferred syntax. Profiles are a good idea I think. Maybe we can agree on a standard syntax on it in RS274 space. I mean you can intersperse ';py,some python statement' into the LinuxCNC dialect now, but I'm not sure this will be helpful at the using end. It's very useful for debugging and selftests though, see some of the remap examples under tests/*. I am curious to see what people think of this proposal instead of attempting to clone an existing controllers syntax. Nothing in that case. - Michael Ben -Original Message- From: Michael Haberler [mailto:mai...@mah.priv.at] Sent: 27 August 2012 10:37 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Ben, it's a creative idea, I like it. The semantics of the 'profile block' is a bit shaky wrt normal execution logic of rs274ngc, but let's see if we can mutate this into common ground so it can be easily done with a remap. what you have is a cycle which in essence refers to a datastructure, namely a list of lines and arcs. assume for a moment you wont specify that datastructure not with aliasing the meaning of existing G-code means, but define new G-codes which dont move the machine but define part of a profile; otherwise have identical parameters. So for instance you use G0, G1, G3 in http://www.bpuk.org/linuxcnc/test2.ngc, its profile block being: N1 G0 X25 N2 G1 Z-10 N3 G3 X20 Z-15 R5.5 N4 G1 Z-20 N5
Re: [Emc-users] G71 lathe roughing cycle
On Tue, 28 Aug 2012 02:00:46 -0700 (PDT), you wrote: Not sure how you were ever able to successfully run a FANUC controlled lathe WITHOUT running into U and W commands. I use Fanuc 0T, 10T, 16T, 18T, 21T and U W are used in all of them. If nothing else the homing line command uses them G0 G28 U0. W0.; Its also used for radius calls, incremental taper definitions, tool offsets and more. Read my post carefully - I said As far as I know Fanuc don't use UW for axis in lathes or turning centres, they use XYZABC Of course they use them as parameters, that's what the discussion is about Steve Blackmore -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle-UW moves
Just to muddy the waters a bit but more :) - Fanuc OT controls at the place where I work use U and W for incremental moves that correspond to X and Z. You can mix incremental axis moves in with absolute moves in the same line of code. This is typically used for dealing with taper like so: G0X1.0Z0 G1U-.001Z-1.300F.003 -move slightly in X as you move towards the headstock. Not to confuse things, but there are a lot of 'exceptions' out there. Dan Message: 7 Date: Wed, 29 Aug 2012 00:44:23 +0100 From: Steve Blackmore st...@pilotltd.net Subject: Re: [Emc-users] G71 lathe roughing cycle To: Greg Bentzinger skullwo...@yahoo.com, Enhanced Machine Controller \(EMC\) emc-users@lists.sourceforge.net Message-ID: kqlq38ljlpfct9mecf4g4mm9vimmd5d...@4ax.com Content-Type: text/plain; charset=us-ascii On Tue, 28 Aug 2012 02:00:46 -0700 (PDT), you wrote: Not sure how you were ever able to successfully run a FANUC controlled lathe WITHOUT running into U and W commands. I use Fanuc 0T, 10T, 16T, 18T, 21T and U W are used in all of them. If nothing else the homing line command uses them G0 G28 U0. W0.; Its also used for radius calls, incremental taper definitions, tool offsets and more. Read my post carefully - I said As far as I know Fanuc don't use UW for axis in lathes or turning centres, they use XYZABC Of course they use them as parameters, that's what the discussion is about Steve Blackmore -- -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users End of Emc-users Digest, Vol 76, Issue 117 ** -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On Sun, 26 Aug 2012 11:14:15 +0100, you wrote: Jeremy/Steve/Chris Chris is correct 1. When reading the U, W words they are reserved for axis movements only. 2. Some lathes are XZ/UW - so the UW words are required for the second tool. As far as I know Fanuc don't use UW for axis in lathes or turning centres, they use XYZABC and I believe they also made two co-coordinated and interlinked controls with two sets of XZ - but I've never come across one. I think they used X_ Y_ Z_ for the second toolpost on that control. I've also seen it without the UW words at all, but can't remember what control. They do seem a bit superfluous and are optional on some. No great shakes to program the actual size the roughing cycle is going to cut, rather than the finished size plus an allowance. Steve Blackmore -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Ben, it's a creative idea, I like it. The semantics of the 'profile block' is a bit shaky wrt normal execution logic of rs274ngc, but let's see if we can mutate this into common ground so it can be easily done with a remap. what you have is a cycle which in essence refers to a datastructure, namely a list of lines and arcs. assume for a moment you wont specify that datastructure not with aliasing the meaning of existing G-code means, but define new G-codes which dont move the machine but define part of a profile; otherwise have identical parameters. So for instance you use G0, G1, G3 in http://www.bpuk.org/linuxcnc/test2.ngc, its profile block being: N1 G0 X25 N2 G1 Z-10 N3 G3 X20 Z-15 R5.5 N4 G1 Z-20 N5 G2 X15 Z-25 R5.5 N6 G1 X12 N7 G1 X10 Z-28 N8 G1 X5 Now lets introduce profile-defining Gcodes G200,G201, and G203 which mirror G0,G1, and G3 except they dont move the machine but rather record profile segments; also I would assume we need a word to specify a profile id, and to clear a profile. Assume we have numbered profiles, so we create a 'M200 Pprofile id' remapped code to clear out the given profile. Also assume G200,G201,G203 will require a word defining which profile that actually is appended to. I'd need to check for conflicts but for now assume it's 'Pprofile id' as well. So with the new scheme we would define the above profile as follows: M200 P47 (clear profile 47) G200 X25 P47 G201 Z-10 P47 G203 X20 Z-15 R5.5 P47 G201 Z-20 P47 G202 X15 Z-25 R5.5 P47 G201 X12 P47 G201 X10 Z-28 P47 G201 X5 P47 what we would have behind the scenes is say G200 causing a python method g200 to be executed which takes the words from the current block and appends a 'rapid' instruction to the profile 47 command list, and the Python method m200 would clear that list. now when that profile is executed in your example, all we do is the following: G18 G21 G91.1 T02 M06 G43 S2000 M03 (Bottom to top, right to left) (G1 X30 Z5 F1000) G0 X5 Z1.0 (Start Position before commanding the cycle) G71 D0.5 F900 J1 L1 I0.5 K0.5 P47 (execute profile 47) so we're not referring to the profile by block number, but by profile id. Same effect, but we havent messed up rs274ngc execution semantics, and along the way we have created a command list in the Python context which can be taken as the basis for cycle execution. See what I mean? if you go that route you can entirely stay with Python, NGC and remap config statements in the ini file. - Michael Am 26.08.2012 um 17:16 schrieb Ben Potter: Am 26.08.2012 um 15:56 schrieb andy pugh: On 26 August 2012 14:04, Michael Haberler mai...@mah.priv.at wrote: Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. I am not sure how the G-code can search itself for a profile definition and parse it. Doesn't that require code introspection? for using the the thing, the choices are: - redefine the builtin G7x[.y]/G8x.[y] cycles with an optional remapping config; if the remap statements are disabled the builtin cycles reappear. But as I said, this needs minor C++ tweakage per redefined code. - just add new ones like in the G17x[.y]/G18x.[y] range - no C++ tweaking required, but that shows on the usage level - either use say G84 for builtin or G184 for the remapped cycle. For most or all of the existing cycles, I can see how moving them out to remap would work. They take a bunch of parameters, and a location to do the first cycle at. They then run the cycle at each set of co-ordinates until they receive a G80. Each of the canned cycles needs nothing more than it's parameters, they don't need to know where the next cycle will be run, and the parameters don't change between runs. For G71 it needs to be able to read the entirety of an arbitrary profile - which could be anything from 2 g-code blocks to 5000 (or more) blocks. The profile can be before the G71 cycle command, or after it. The same profile will usually be used at least twice (G71 then G70). To make it even more confusing, the profile could theoretically be after M2/M30 so that it is never accidentally executed. The profile must contain at least 1 G0 or G1 command, with G2/3 needed for any arcs, if I'm reading the remap docs correctly, these would break it out of remapping. In the patches I added code to rs274ngc_pre.cc which does this readahead - and then returns execution back to the same point to actually process the copied blocks, if that section was cleaned up and thoroughly checked all the rest of the cycle code could be done using remapping, but without it (or an equivalent) there doesn't seem to be any way to get the data needed. That said, I'm not exactly familiar with the way remapping has been implemented, so I could be missing a really obvious command Ben -- Live Security
Re: [Emc-users] G71 lathe roughing cycle
I have wished for a long time for a general mechanism for defining a path (profile) once, then using that path multiple times in functions. This reinvention of G71/G70 looks like a good opportunity to create such a mechanism. I use G71/G70 often in code for our Mori Seiki lathe (Fanuc 0i control). I see no particular reason to slavishly implement the Fanuc syntax though, as it is very peculiar. I have to study the manual carefully every time I write a new program using it. Something more general and intuitive for LinuxCNC would be great. -- Ralph From: Michael Haberler [mai...@mah.priv.at] Sent: Monday, August 27, 2012 2:37 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Ben, it's a creative idea, I like it. The semantics of the 'profile block' is a bit shaky wrt normal execution logic of rs274ngc, but let's see if we can mutate this into common ground so it can be easily done with a remap. what you have is a cycle which in essence refers to a datastructure, namely a list of lines and arcs. assume for a moment you wont specify that datastructure not with aliasing the meaning of existing G-code means, but define new G-codes which dont move the machine but define part of a profile; otherwise have identical parameters. So for instance you use G0, G1, G3 in http://www.bpuk.org/linuxcnc/test2.ngc, its profile block being: N1 G0 X25 N2 G1 Z-10 N3 G3 X20 Z-15 R5.5 N4 G1 Z-20 N5 G2 X15 Z-25 R5.5 N6 G1 X12 N7 G1 X10 Z-28 N8 G1 X5 Now lets introduce profile-defining Gcodes G200,G201, and G203 which mirror G0,G1, and G3 except they dont move the machine but rather record profile segments; also I would assume we need a word to specify a profile id, and to clear a profile. Assume we have numbered profiles, so we create a 'M200 Pprofile id' remapped code to clear out the given profile. Also assume G200,G201,G203 will require a word defining which profile that actually is appended to. I'd need to check for conflicts but for now assume it's 'Pprofile id' as well. So with the new scheme we would define the above profile as follows: M200 P47 (clear profile 47) G200 X25 P47 G201 Z-10 P47 G203 X20 Z-15 R5.5 P47 G201 Z-20 P47 G202 X15 Z-25 R5.5 P47 G201 X12 P47 G201 X10 Z-28 P47 G201 X5 P47 what we would have behind the scenes is say G200 causing a python method g200 to be executed which takes the words from the current block and appends a 'rapid' instruction to the profile 47 command list, and the Python method m200 would clear that list. now when that profile is executed in your example, all we do is the following: G18 G21 G91.1 T02 M06 G43 S2000 M03 (Bottom to top, right to left) (G1 X30 Z5 F1000) G0 X5 Z1.0 (Start Position before commanding the cycle) G71 D0.5 F900 J1 L1 I0.5 K0.5 P47 (execute profile 47) so we're not referring to the profile by block number, but by profile id. Same effect, but we havent messed up rs274ngc execution semantics, and along the way we have created a command list in the Python context which can be taken as the basis for cycle execution. See what I mean? if you go that route you can entirely stay with Python, NGC and remap config statements in the ini file. - Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On Mon, 27 Aug 2012, Ralph Stirling wrote: I have wished for a long time for a general mechanism for defining a path (profile) once, then using that path multiple times in functions. This reinvention of G71/G70 looks like a good opportunity to create such a mechanism. I use G71/G70 often in code for our Mori Seiki lathe (Fanuc 0i control). I see no particular reason to slavishly implement the Fanuc syntax though, as it is very peculiar. I have to study the manual carefully every time I write a new program using it. Something more general and intuitive for LinuxCNC would be great. As an aside I create a program to generate a profile and store the points in a database table. Then a second program to read the points and apply scaling and a z value to create a 3d profile. From my perspective it is much simpler than trying to write it in g-code. Richard -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On 8/27/2012 9:16 AM, Ralph Stirling wrote: I have wished for a long time for a general mechanism for defining a path (profile) once, then using that path multiple times in functions. This reinvention of G71/G70 looks like a good opportunity to create such a mechanism. I use G71/G70 often in code for our Mori Seiki lathe (Fanuc 0i control). I see no particular reason to slavishly implement the Fanuc syntax though, as it is very peculiar. I have to study the manual carefully every time I write a new program using it. Something more general and intuitive for LinuxCNC would be great. -- Ralph I've done that by writing a subroutine that traces the path. The subroutine takes a single argument that represents the offset from the path. Then call it in a loop with appropriate values. Ken -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
I've done that by writing a subroutine that traces the path. The subroutine takes a single argument that represents the offset from the path. Then call it in a loop with appropriate values. Another variation on the theme, similar to the above, I published a set of ngcui subroutines to carry out G71 and G72 plus a lot more on the lathe, last year some time. http://www.linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=40id=11414 They take a finished toolpath profile, entered as a series of linear and arc cuts, enter these into an array, calculate offsets, deepest cuts etc. and then run incrementing by #cutdepth each pass until the profile is cut, less finishing cut depth. The finishing cut is in a separate sub, unlike the fanuc style routine, so that a different tool can be selected if required. (cat skinning method #7) regards -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Michael, I'll have to think about this a bit, but on first reading I like it. My initial impressions are: 1) If I'm reading you right, the profile block would need to be defined before any call to it. That said, it wouldn't actually execute it, merely store it. 2) No C++ maintenance to worry about, and avoids the somewhat hackish method I was looking at to grab the profile data 3) Leaves N words still unused 4) Requires a new set of g-codes to be learned that are only used for profile definitions 5) As per Ralph Stirling's reply to this, this creates a generalised method for defining arbitrary profiles - which can then be used within any remap code. Possible uses on mills/routers too 6) P probably conflicts with arcs (where it refers to turns), but I can't imagine a 2d profile where turns are valid, I suppose it depends on whether this is generalised to 3 axis, or to 2 axis + plane definition 7) Completely different method to other controllers I can't see any of those being a particular problem, but it does break compatibility with other controllers further than the original proposal. I'll save a diff of where I'm up to on the C++ route in case that ends up being a better option, and play around with this a bit. It's probable that the actual G71 syntax could be very similar to any given existing control, with just the block definition needing rework. Since it's in python, the syntax could even be changed to suit a given persons preferred syntax. I am curious to see what people think of this proposal instead of attempting to clone an existing controllers syntax. Ben -Original Message- From: Michael Haberler [mailto:mai...@mah.priv.at] Sent: 27 August 2012 10:37 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Ben, it's a creative idea, I like it. The semantics of the 'profile block' is a bit shaky wrt normal execution logic of rs274ngc, but let's see if we can mutate this into common ground so it can be easily done with a remap. what you have is a cycle which in essence refers to a datastructure, namely a list of lines and arcs. assume for a moment you wont specify that datastructure not with aliasing the meaning of existing G-code means, but define new G-codes which dont move the machine but define part of a profile; otherwise have identical parameters. So for instance you use G0, G1, G3 in http://www.bpuk.org/linuxcnc/test2.ngc, its profile block being: N1 G0 X25 N2 G1 Z-10 N3 G3 X20 Z-15 R5.5 N4 G1 Z-20 N5 G2 X15 Z-25 R5.5 N6 G1 X12 N7 G1 X10 Z-28 N8 G1 X5 Now lets introduce profile-defining Gcodes G200,G201, and G203 which mirror G0,G1, and G3 except they dont move the machine but rather record profile segments; also I would assume we need a word to specify a profile id, and to clear a profile. Assume we have numbered profiles, so we create a 'M200 Pprofile id' remapped code to clear out the given profile. Also assume G200,G201,G203 will require a word defining which profile that actually is appended to. I'd need to check for conflicts but for now assume it's 'Pprofile id' as well. So with the new scheme we would define the above profile as follows: M200 P47 (clear profile 47) G200 X25 P47 G201 Z-10 P47 G203 X20 Z-15 R5.5 P47 G201 Z-20 P47 G202 X15 Z-25 R5.5 P47 G201 X12 P47 G201 X10 Z-28 P47 G201 X5 P47 what we would have behind the scenes is say G200 causing a python method g200 to be executed which takes the words from the current block and appends a 'rapid' instruction to the profile 47 command list, and the Python method m200 would clear that list. now when that profile is executed in your example, all we do is the following: G18 G21 G91.1 T02 M06 G43 S2000 M03 (Bottom to top, right to left) (G1 X30 Z5 F1000) G0 X5 Z1.0 (Start Position before commanding the cycle) G71 D0.5 F900 J1 L1 I0.5 K0.5 P47 (execute profile 47) so we're not referring to the profile by block number, but by profile id. Same effect, but we havent messed up rs274ngc execution semantics, and along the way we have created a command list in the Python context which can be taken as the basis for cycle execution. See what I mean? if you go that route you can entirely stay with Python, NGC and remap config statements in the ini file. - Michael Am 26.08.2012 um 17:16 schrieb Ben Potter: Am 26.08.2012 um 15:56 schrieb andy pugh: On 26 August 2012 14:04, Michael Haberler mai...@mah.priv.at wrote: Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. I am not sure how the G-code can search itself for a profile definition and parse it. Doesn't that require code introspection? for using the the thing, the choices are: - redefine the builtin G7x[.y]/G8x.[y] cycles with an optional remapping config; if the remap statements are disabled the builtin cycles reappear. But as I said, this needs minor C++ tweakage per redefined code. - just add new ones like
Re: [Emc-users] G71 lathe roughing cycle
Dual turret (or spindle) machines do seem to come in an incredible variety of languages. I remember one particularly awkward machine that used z_[1]x through z_[5]x to define which spindle you were moving, followed by a g-code to tell it to actually move the Z-axis. Normal Xn Yn Zn moves would move all 5 spindles at the same time. I was referring to how linuxcnc currently handles those words - but this thread seems to have rekindled some discussion about how to handle multi-tool machines in linuxcnc. If I can retain the UW syntax I will, but the methods I have tried so far won't allow it. The remapping method suggested by Michael Haberler may or may not allow the use of these words, but would require a different method to define the profile. I never really understood why UW in G71 were that essential, IK seems to do the same job with the added bonus of a smooth pre-finish cut. I suppose it depends a lot on the part. Ben -Original Message- From: Steve Blackmore [mailto:st...@pilotltd.net] Sent: 27 August 2012 10:00 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle On Sun, 26 Aug 2012 11:14:15 +0100, you wrote: Jeremy/Steve/Chris Chris is correct 1. When reading the U, W words they are reserved for axis movements only. 2. Some lathes are XZ/UW - so the UW words are required for the second tool. As far as I know Fanuc don't use UW for axis in lathes or turning centres, they use XYZABC and I believe they also made two co-coordinated and interlinked controls with two sets of XZ - but I've never come across one. I think they used X_ Y_ Z_ for the second toolpost on that control. I've also seen it without the UW words at all, but can't remember what control. They do seem a bit superfluous and are optional on some. No great shakes to program the actual size the roughing cycle is going to cut, rather than the finished size plus an allowance. Steve Blackmore -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Am 27.08.2012 um 18:35 schrieb Ben Potter: Michael, I'll have to think about this a bit, but on first reading I like it. My initial impressions are: 1) If I'm reading you right, the profile block would need to be defined before any call to it. That said, it wouldn't actually execute it, merely store it. 2) No C++ maintenance to worry about, and avoids the somewhat hackish method I was looking at to grab the profile data 3) Leaves N words still unused all above: yes 4) Requires a new set of g-codes to be learned that are only used for profile definitions not really, beyond adding an offset to the base Gcode. They should exactly mirror their G0,G1,G3 cousins in parameters, and I think they could actually executed eventually by resorting to their builtin semantics. See 3.3.4. Advanced example: Remapped codes in pure Python under http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_the_em_argspec_em_parameter_a_id_remap_argspec_parameter_a - you will find a recursive call of the interpreter in a remap there. 5) As per Ralph Stirling's reply to this, this creates a generalised method for defining arbitrary profiles - which can then be used within any remap code. Possible uses on mills/routers too yes 6) P probably conflicts with arcs (where it refers to turns), but I can't imagine a 2d profile where turns are valid, I suppose it depends on whether this is generalised to 3 axis, or to 2 axis + plane definition I just picked 'P' as I was too lazy to check the manual for conflicts - any free word does it 7) Completely different method to other controllers I can't see any of those being a particular problem, but it does break compatibility with other controllers further than the original proposal. Let me be candid on that: I think the other controllers method is a real, total kludge, and I dont think compatibility is a great virtue in that case. What this method does is redefine the semantics of a G-code block *depending on its block number*, which the manual so far declared as optional and meaningless. Just think through what this does to run from line - there goes your tool, bang. It also introduces a new block structure and intra-line dependency which didnt exist yet. I mean RS274NGC is a very limited language so folks have all sorts of ideas but we must aim to reduce the shoot-into-foot potential as good as we can. The method I proposed does involve new codes, and it relies on side effects in Python to accumulate a data structure. but it doesnt change the semantics of the language in an ad-hoc way for a single feature. And it doesnt break run-from-line, brittle as that is. I'll save a diff of where I'm up to on the C++ route in case that ends up being a better option, and play around with this a bit. It's probable that the actual G71 syntax could be very similar to any given existing control, with just the block definition needing rework. Since it's in python, the syntax could even be changed to suit a given persons preferred syntax. Profiles are a good idea I think. Maybe we can agree on a standard syntax on it in RS274 space. I mean you can intersperse ';py,some python statement' into the LinuxCNC dialect now, but I'm not sure this will be helpful at the using end. It's very useful for debugging and selftests though, see some of the remap examples under tests/*. I am curious to see what people think of this proposal instead of attempting to clone an existing controllers syntax. Nothing in that case. - Michael Ben -Original Message- From: Michael Haberler [mailto:mai...@mah.priv.at] Sent: 27 August 2012 10:37 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Ben, it's a creative idea, I like it. The semantics of the 'profile block' is a bit shaky wrt normal execution logic of rs274ngc, but let's see if we can mutate this into common ground so it can be easily done with a remap. what you have is a cycle which in essence refers to a datastructure, namely a list of lines and arcs. assume for a moment you wont specify that datastructure not with aliasing the meaning of existing G-code means, but define new G-codes which dont move the machine but define part of a profile; otherwise have identical parameters. So for instance you use G0, G1, G3 in http://www.bpuk.org/linuxcnc/test2.ngc, its profile block being: N1 G0 X25 N2 G1 Z-10 N3 G3 X20 Z-15 R5.5 N4 G1 Z-20 N5 G2 X15 Z-25 R5.5 N6 G1 X12 N7 G1 X10 Z-28 N8 G1 X5 Now lets introduce profile-defining Gcodes G200,G201, and G203 which mirror G0,G1, and G3 except they dont move the machine but rather record profile segments; also I would assume we need a word to specify a profile id, and to clear a profile. Assume we have numbered profiles, so we create a 'M200 Pprofile id' remapped code to clear out the given profile. Also assume G200,G201,G203 will require a word defining which profile
Re: [Emc-users] G71 lathe roughing cycle
Run from line works pretty good on my Mori's Fanuc, but I would sure never try to start on a line in the middle of a G71 profile block. I'd rather not find out what it would try to do in that case. I guess I could live with the G200/1/2/3 versions of the G0/1/2/3, but it doesn't seem like a real elegant solution. I can certainly see why it would be desirable not to rip open a big can of run-from-line worms. -- Ralph From: Michael Haberler [mai...@mah.priv.at] Sent: Monday, August 27, 2012 10:35 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Am 27.08.2012 um 18:35 schrieb Ben Potter: What this method does is redefine the semantics of a G-code block *depending on its block number*, which the manual so far declared as optional and meaningless. Just think through what this does to run from line - there goes your tool, bang. It also introduces a new block structure and intra-line dependency which didnt exist yet. I mean RS274NGC is a very limited language so folks have all sorts of ideas but we must aim to reduce the shoot-into-foot potential as good as we can. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On Mon, Aug 27, 2012 at 05:35:28PM +0100, Ben Potter wrote: 7) Completely different method to other controllers Like others I don't have a problem with this when other controllers are excessively weird or contrary to how ngc works. I am curious which, if either, approach (C or remap) would eventually be able to work with cutter compensation turned on. For most lathe tool shapes it's necessary to use compensation whenever you have an arc or even a straight feature that's not parallel to an axis. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
In a single direction (read: type 1 cycle) - either. The moves generated in either case are the same, it's simply the syntax which they are called with (and what bugs it may introduce elsewhere). I have only ignored it so far since it reduces the number of things to worry about at one time. For type 2 (pockets, much further down the line) it's potentially a bit more complex, but should still be workable. Since linuxcnc actually stores tool shapes (well, front/back angle and radius) the issues some controllers have with changing tip direction can probably be avoided. -Original Message- From: Chris Radek [mailto:ch...@timeguy.com] Sent: 27 August 2012 19:22 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle On Mon, Aug 27, 2012 at 05:35:28PM +0100, Ben Potter wrote: 7) Completely different method to other controllers Like others I don't have a problem with this when other controllers are excessively weird or contrary to how ngc works. I am curious which, if either, approach (C or remap) would eventually be able to work with cutter compensation turned on. For most lathe tool shapes it's necessary to use compensation whenever you have an arc or even a straight feature that's not parallel to an axis. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Am 27.08.2012 um 20:22 schrieb Chris Radek: On Mon, Aug 27, 2012 at 05:35:28PM +0100, Ben Potter wrote: 7) Completely different method to other controllers Like others I don't have a problem with this when other controllers are excessively weird or contrary to how ngc works. I am curious which, if either, approach (C or remap) would eventually be able to work with cutter compensation turned on. For most lathe tool shapes it's necessary to use compensation whenever you have an arc or even a straight feature that's not parallel to an axis. in case a recursive call of the interpreter is used to execute the generated moves then I think that those two issues - cycle and compensation - are ships in the night - not aware of each other, so I guess it would work -m -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On Mon, 27 Aug 2012 17:45:23 +0100, you wrote: Dual turret (or spindle) machines do seem to come in an incredible variety of languages. I remember one particularly awkward machine that used z_[1]x through z_[5]x to define which spindle you were moving, followed by a g-code to tell it to actually move the Z-axis. Normal Xn Yn Zn moves would move all 5 spindles at the same time. Argghhh :) I was referring to how linuxcnc currently handles those words - but this thread seems to have rekindled some discussion about how to handle multi-tool machines in linuxcnc. It's a pity that UVW are reserved and not available, it would be much easier if the axis words were only reserved by hal or ini, rather than globally or simply ignored as an axis in a lathe canned cycle block. If I can retain the UW syntax I will, but the methods I have tried so far won't allow it. The remapping method suggested by Michael Haberler may or may not allow the use of these words, but would require a different method to define the profile. I'm not keen, as you say it detracts even further from some sort of compatibility and adds even more complexity to a simple function. When you use multiple control types it becomes a nightmare. I never really understood why UW in G71 were that essential, IK seems to do the same job with the added bonus of a smooth pre-finish cut. I suppose it depends a lot on the part. Yea - I know what you mean. I don't think they are essential if you are going to use a finishing cycle or other processes after. I do some CAM consultancy and my list of different post processors gets longer and more complex these days. Personally if I'm testing a new part I tend not to use cycles at all, it makes it much easier to see where you can trim some time off the machining and what section may cause a problem. Very often the optimised code ends up longer, but quicker :) Steve Blackmore -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On Sun, 26 Aug 2012 00:59:59 +0100, you wrote: To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: Please don't. U and W are consistent amongst Fanuc based controls for stock amount left on X and Z respectively in cycles. More likely to confuse those who use CNC commercially and reduces portability of code across controls by changing parameters. Steve Blackmore -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: Please don't. U and W are consistent amongst Fanuc based controls for stock amount left on X and Z respectively in cycles. More likely to confuse those who use CNC commercially and reduces portability of code across controls by changing parameters. Steve Blackmore -- I am betting he chose his words wisely - work around U and W I am betting that linuxcnc confuses then for the U and W axis. Chris M -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Ben, after reading your patch I found not a single line which warrants the modification of the interpreter at the C level. The whole thing can be done in an O-word procedure, maybe a bit of Python glue, as a remapped code, which is in master, and in a stable fashion for the better part of this year. And it is exactly the use case for which I developed the remapping extension in the first place. Please read http://www.linuxcnc.org/docs/devel/html/remap/structure.html , and see the examples under configs/sim/remap. The chapter on 'Creating new G code cycles' http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_creating_new_g_code_cycles_a_id_remap_g_code_cycles_a will be particularly helpful. If you need help on the first steps of getting a remapped code working, I am happy to help. However, I resist low-level extensions duplicating higher-level functionality with the extra onus of C++ skills required for adaptation or fixes. - Michael Am 26.08.2012 um 01:59 schrieb Ben Potter: I have been working on an implementation of the G71 roughing cycle for lathes. While the code is unfinished and known to be non-robust it's ready for initial review. A patch is available at: http://www.bpuk.org/linuxcnc/g71-patch-1-initial-feedback-mod.diff with sample g-code programs at: http://www.bpuk.org/linuxcnc/test.ngc http://www.bpuk.org/linuxcnc/test2.ngc The main question I have is what 'should' happen after the G71 line is executed. Should the program continue on the next line, or skip the profile block (defined by N1 Nx) ? To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: P Block Number of contour beginning (uses N word in beginning block) Q Block number of contour end (uses N word in end block) D Roughing Depth per move R Retraction from each cut J Overthickness for finishing at X (diameter) (U on other controllers) L Overthickness for finishing at Z (W on other controllers) I Thickness for finishing at X K Thickness for finishing at Z F Feedrate override between P and Q blocks S Spindle speed override between P and Q blocks T Tool override between P and Q blocks There are a few screenshots at http://www.bpuk.org/linuxcnc/ at various stages of progress. OD and ID should work for G1/G2/G3/G4 profiles for front-tool lathes, I haven't looked at back-tool lathes at all yet. UW commands are invalid and ignored at this stage. Until I'm happy with the code I won't be looking at type 2 - as such only type 1 (no pockets) g-code is supported so far. Any comments are appreciated Ta Ben -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Michael, Thanks - I'm going to have a good look into that lot. I had previously seen it, but only when looking for something else. From the first couple of minutes of looking at the docs I'd ask if there is a way that (XZ or UW) can be required words, but not both sets? Ben -Original Message- From: Michael Haberler [mailto:mai...@mah.priv.at] Sent: 26 August 2012 10:23 To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] G71 lathe roughing cycle Ben, after reading your patch I found not a single line which warrants the modification of the interpreter at the C level. The whole thing can be done in an O-word procedure, maybe a bit of Python glue, as a remapped code, which is in master, and in a stable fashion for the better part of this year. And it is exactly the use case for which I developed the remapping extension in the first place. Please read http://www.linuxcnc.org/docs/devel/html/remap/structure.html , and see the examples under configs/sim/remap. The chapter on 'Creating new G code cycles' http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_creating_new_g _code_cycles_a_id_remap_g_code_cycles_a will be particularly helpful. If you need help on the first steps of getting a remapped code working, I am happy to help. However, I resist low-level extensions duplicating higher-level functionality with the extra onus of C++ skills required for adaptation or fixes. - Michael Am 26.08.2012 um 01:59 schrieb Ben Potter: I have been working on an implementation of the G71 roughing cycle for lathes. While the code is unfinished and known to be non-robust it's ready for initial review. A patch is available at: http://www.bpuk.org/linuxcnc/g71-patch-1-initial-feedback-mod.diff with sample g-code programs at: http://www.bpuk.org/linuxcnc/test.ngc http://www.bpuk.org/linuxcnc/test2.ngc The main question I have is what 'should' happen after the G71 line is executed. Should the program continue on the next line, or skip the profile block (defined by N1 Nx) ? To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: P Block Number of contour beginning (uses N word in beginning block) Q Block number of contour end (uses N word in end block) D Roughing Depth per move R Retraction from each cut J Overthickness for finishing at X (diameter) (U on other controllers) L Overthickness for finishing at Z (W on other controllers) I Thickness for finishing at X K Thickness for finishing at Z F Feedrate override between P and Q blocks S Spindle speed override between P and Q blocks T Tool override between P and Q blocks There are a few screenshots at http://www.bpuk.org/linuxcnc/ at various stages of progress. OD and ID should work for G1/G2/G3/G4 profiles for front-tool lathes, I haven't looked at back-tool lathes at all yet. UW commands are invalid and ignored at this stage. Until I'm happy with the code I won't be looking at type 2 - as such only type 1 (no pockets) g-code is supported so far. Any comments are appreciated Ta Ben -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Jeremy/Steve/Chris Chris is correct 1. When reading the U, W words they are reserved for axis movements only. 2. Some lathes are XZ/UW - so the UW words are required for the second tool. While I'd love to keep compatibility with other controllers as far as possible, I just can't see a way to do it in this case. Ben -Original Message- From: Chris Morley [mailto:chrisinnana...@hotmail.com] Sent: 26 August 2012 08:41 To: EMC Subject: Re: [Emc-users] G71 lathe roughing cycle To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: Please don't. U and W are consistent amongst Fanuc based controls for stock amount left on X and Z respectively in cycles. More likely to confuse those who use CNC commercially and reduces portability of code across controls by changing parameters. Steve Blackmore -- I am betting he chose his words wisely - work around U and W I am betting that linuxcnc confuses then for the U and W axis. Chris M -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On 26 August 2012 08:35, Steve Blackmore st...@pilotltd.net wrote: To work around the use of U and W words on other controllers Please don't. U and W are consistent amongst Fanuc based controls for stock amount left on X and Z respectively in cycles. But are Axes in LinuxCNC G-code, even on Lathes. There is at least one user with a twin-toolpost lathe. I think he is expecting to use UW to move the second head, and he would (presumably) like a G71 which allowed UW roughing. I would argue that the Fanuc standard enforces an artificial lathes are lathes, and can't be part of a multi-axis machine distinction. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On 26 August 2012 10:22, Michael Haberler mai...@mah.priv.at wrote: after reading your patch I found not a single line which warrants the modification of the interpreter at the C level. The whole thing can be done in an O-word procedure, maybe a bit of Python glue, as a remapped code, which is in master, and in a stable fashion for the better part of this year. And it is exactly the use case for which I developed the remapping extension in the first place. Would that be an argument for removing all other canned cycles from the Interpreter and putting them in O-subs? That was meant as a reductio ad absurdum, but now I am not so sure that that wouldn't actually be a good idea. It would allow users/integrators to tweak canned cycles to suit very easily. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Am 26.08.2012 um 11:50 schrieb andy pugh: On 26 August 2012 10:22, Michael Haberler mai...@mah.priv.at wrote: after reading your patch I found not a single line which warrants the modification of the interpreter at the C level. The whole thing can be done in an O-word procedure, maybe a bit of Python glue, as a remapped code, which is in master, and in a stable fashion for the better part of this year. And it is exactly the use case for which I developed the remapping extension in the first place. Would that be an argument for removing all other canned cycles from the Interpreter and putting them in O-subs? I'd have to read the cycle code once more, it's been a while; but I think I carried over all of the important state handling from the C++ code. In terms of Canon calls, both C++ and Python have the same interface available. So I think it is possible, yes. That was meant as a reductio ad absurdum, but now I am not so sure that that wouldn't actually be a good idea. It would allow users/integrators to tweak canned cycles to suit very easily. right, that was the argument for sticking with oword procedures, not just Python which would have been a lot simpler. The only work item I'd see is: redefining an existing code needs some C++ modifications if one were to go for that; defining an entirely new code doesnt. But it's not complex, there's just no good automated support in place for doing that, because of it came kind of as an afterthought. I think it would be possible to completely regression-test the output of the remapped cycles against the builtin cycles automatically. Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. - Michael -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
On 26 August 2012 14:04, Michael Haberler mai...@mah.priv.at wrote: Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. I am not sure how the G-code can search itself for a profile definition and parse it. Doesn't that require code introspection? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Am 26.08.2012 um 15:56 schrieb andy pugh: On 26 August 2012 14:04, Michael Haberler mai...@mah.priv.at wrote: Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. I am not sure how the G-code can search itself for a profile definition and parse it. Doesn't that require code introspection? I guess I meant the following. - the existing builtin G7x[.y]/G8x.[y] cycles stay untouched - a remap configuration (ini magic, python glue, NGC procedures) might add the G17x[.y]/G18x.[y] clones then run a say G8x cycle through the standalone interpreter (rs274) which generates a list of canon commands based on existing cycles. when you run the 'equivalent' G18x through rs274 with a remapping config it should generate an bit-for-bit identical list of canon commands This is for regression testing. for using the the thing, the choices are: - redefine the builtin G7x[.y]/G8x.[y] cycles with an optional remapping config; if the remap statements are disabled the builtin cycles reappear. But as I said, this needs minor C++ tweakage per redefined code. - just add new ones like in the G17x[.y]/G18x.[y] range - no C++ tweaking required, but that shows on the usage level - either use say G84 for builtin or G184 for the remapped cycle. - Michael -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Am 26.08.2012 um 15:56 schrieb andy pugh: On 26 August 2012 14:04, Michael Haberler mai...@mah.priv.at wrote: Taking all G7x[.y]/G8x.[y] and writing equivalent new codes eg G17x[.y]/G18x.[y] in NGC and a bit of Python is possible without any C++. I am not sure how the G-code can search itself for a profile definition and parse it. Doesn't that require code introspection? for using the the thing, the choices are: - redefine the builtin G7x[.y]/G8x.[y] cycles with an optional remapping config; if the remap statements are disabled the builtin cycles reappear. But as I said, this needs minor C++ tweakage per redefined code. - just add new ones like in the G17x[.y]/G18x.[y] range - no C++ tweaking required, but that shows on the usage level - either use say G84 for builtin or G184 for the remapped cycle. For most or all of the existing cycles, I can see how moving them out to remap would work. They take a bunch of parameters, and a location to do the first cycle at. They then run the cycle at each set of co-ordinates until they receive a G80. Each of the canned cycles needs nothing more than it's parameters, they don't need to know where the next cycle will be run, and the parameters don't change between runs. For G71 it needs to be able to read the entirety of an arbitrary profile - which could be anything from 2 g-code blocks to 5000 (or more) blocks. The profile can be before the G71 cycle command, or after it. The same profile will usually be used at least twice (G71 then G70). To make it even more confusing, the profile could theoretically be after M2/M30 so that it is never accidentally executed. The profile must contain at least 1 G0 or G1 command, with G2/3 needed for any arcs, if I'm reading the remap docs correctly, these would break it out of remapping. In the patches I added code to rs274ngc_pre.cc which does this readahead - and then returns execution back to the same point to actually process the copied blocks, if that section was cleaned up and thoroughly checked all the rest of the cycle code could be done using remapping, but without it (or an equivalent) there doesn't seem to be any way to get the data needed. That said, I'm not exactly familiar with the way remapping has been implemented, so I could be missing a really obvious command Ben -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
I have not had the chance to run a dual turret lathe with a FANUC control, but I have a few thousand hours on a OKUMA dual turret. Currently LCNC treats each axis as a reserved word and you can't duplicate axis. Okuma's Method to work around this used G13 G14 to define what the program code would apply to. G13 was for the upper turret, G14 for the lower. By adding P000xx codes ( Priority code ) you were able to define which moves were independant and which could be executed simaltainiously. (adding this might require a GUI mod of a split screen for the different turret programs, even though its all one top down program in the file.) So far LCNC has been able to move forward as a one size fits all program package, where the only major divergant config is the type of KINS file the user chooses. The ability to map/remap codes sounds like an important way to allow different machine type to move to more machine specific gcode structures. At the initial config a install script could be called to sell the interpreter for lathe, or mill etc. While the ability to define a multi turret or multi mill head type machine is likely a LCNC v2.8 or later type project, I would like the option of having G12/G13 pocketing in milling and G13/G14 for lather turret designation at some future time. Code mapping may be the first step in that direction. Greg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Currently LCNC treats each axis as a reserved word and you can't duplicate axis. Okuma's Method to work around this used G13 G14 to define what the program code would apply to. G13 was for the upper turret, G14 for the lower. By adding P000xx codes ( Priority code ) you were able to define which moves were independant and which could be executed simaltainiously. (adding this might require a GUI mod of a split screen for the different turret programs, even though its all one top down program in the file.) this is interesting and although off the lathe subject it makes me consider this. I am intending to run the knee and the spindle down feed independently of each other when I convert to 5 axis, so this begs me to question will I have to rename the spindle down axis and then g code around it? Not urgent but some thoughts for me in the future -- jeremy youngs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Okuma's Method to work around this used G13 G14 to define what the program code would apply to. G13 was for the upper turret, G14 for the lower. By adding P000xx codes ( Priority code ) I suppose we should think of the sliding head lathes that will be looked at in the future I have one resting in the garage that needs a large round tuit applying Currently it is a cam auto but would be a nice cnc retrofit project it has 4 tool slides one being a back and forward tool by rocking it has facilities for tooling to be mounted on the front too (I have a screw head slotting attachment) http://www.archivist.info/cnc/works2008b/P1010226.JPG Dave Caroline -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
I am really glad someone is working on G71/G70 To me G71 is as important on a lathe as G83 is to a mill Thanks guys Terry - Original Message - From: Dave Caroline dave.thearchiv...@gmail.com To: emc-users@lists.sourceforge.net Cc: Sent: Sunday, August 26, 2012 2:46 PM Subject: Re: [Emc-users] G71 lathe roughing cycle Okuma's Method to work around this used G13 G14 to define what the program code would apply to. G13 was for the upper turret, G14 for the lower. By adding P000xx codes ( Priority code ) I suppose we should think of the sliding head lathes that will be looked at in the future I have one resting in the garage that needs a large round tuit applying Currently it is a cam auto but would be a nice cnc retrofit project it has 4 tool slides one being a back and forward tool by rocking it has facilities for tooling to be mounted on the front too (I have a screw head slotting attachment) http://www.archivist.info/cnc/works2008b/P1010226.JPG Dave Caroline -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] G71 lathe roughing cycle
I have been working on an implementation of the G71 roughing cycle for lathes. While the code is unfinished and known to be non-robust it's ready for initial review. A patch is available at: http://www.bpuk.org/linuxcnc/g71-patch-1-initial-feedback-mod.diff with sample g-code programs at: http://www.bpuk.org/linuxcnc/test.ngc http://www.bpuk.org/linuxcnc/test2.ngc The main question I have is what 'should' happen after the G71 line is executed. Should the program continue on the next line, or skip the profile block (defined by N1 Nx) ? To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: P Block Number of contour beginning (uses N word in beginning block) Q Block number of contour end (uses N word in end block) D Roughing Depth per move R Retraction from each cut J Overthickness for finishing at X (diameter) (U on other controllers) L Overthickness for finishing at Z (W on other controllers) I Thickness for finishing at X K Thickness for finishing at Z F Feedrate override between P and Q blocks S Spindle speed override between P and Q blocks T Tool override between P and Q blocks There are a few screenshots at http://www.bpuk.org/linuxcnc/ at various stages of progress. OD and ID should work for G1/G2/G3/G4 profiles for front-tool lathes, I haven't looked at back-tool lathes at all yet. UW commands are invalid and ignored at this stage. Until I'm happy with the code I won't be looking at type 2 - as such only type 1 (no pockets) g-code is supported so far. Any comments are appreciated Ta Ben -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G71 lathe roughing cycle
Hey Ben, thanx for your work on this, I am wondering why the deviation from u, w? On Sat, Aug 25, 2012 at 7:59 PM, Ben Potter b...@bpuk.org wrote: I have been working on an implementation of the G71 roughing cycle for lathes. While the code is unfinished and known to be non-robust it's ready for initial review. A patch is available at: http://www.bpuk.org/linuxcnc/g71-patch-1-initial-feedback-mod.diff with sample g-code programs at: http://www.bpuk.org/linuxcnc/test.ngc http://www.bpuk.org/linuxcnc/test2.ngc The main question I have is what 'should' happen after the G71 line is executed. Should the program continue on the next line, or skip the profile block (defined by N1 Nx) ? To work around the use of U and W words on other controllers I have used J and L respectively. As such the complete list of words used by the current implementation of G71 is: P Block Number of contour beginning (uses N word in beginning block) Q Block number of contour end (uses N word in end block) D Roughing Depth per move R Retraction from each cut J Overthickness for finishing at X (diameter) (U on other controllers) L Overthickness for finishing at Z (W on other controllers) I Thickness for finishing at X K Thickness for finishing at Z F Feedrate override between P and Q blocks S Spindle speed override between P and Q blocks T Tool override between P and Q blocks There are a few screenshots at http://www.bpuk.org/linuxcnc/ at various stages of progress. OD and ID should work for G1/G2/G3/G4 profiles for front-tool lathes, I haven't looked at back-tool lathes at all yet. UW commands are invalid and ignored at this stage. Until I'm happy with the code I won't be looking at type 2 - as such only type 1 (no pockets) g-code is supported so far. Any comments are appreciated Ta Ben -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- jeremy youngs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
