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