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 P<profile 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 'P<profile 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 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
