On May 17 2013 10:27 AM, Kent A. Reed wrote: > On 5/17/2013 10:20 AM, andy pugh wrote: >> On 17 May 2013 08:05, Chris Morley <chrisinnana...@hotmail.com> >> wrote: >> >>> If I was doing a clean sheet Gcode dialect I think I would choose >>> multiple geometry and wear offsets >>> per tool, but that gets to be a lot of entries in the tool table. >>> 100 tools x 10 geo offsets + 100 tools x 10 wear offsets is 2000 >>> entries. (arbitrary example) >> It is potentially a lot more than that, as each individual offset >> might be in 6 different axes. >> Some form of sparse data structure is probably needed. >> >>> I'm thinking of a 'virtual' tool number that the program would call >>> say tool 1 >>> then the control would use one of a number of actual tools - all >>> preset to cut identical. >> They wouldn't need to be preset, they could have individual offsets. >> The trick is to separate Tool-ID and T-number. >> You can also imagine having multiple carousels for different jobs, >> with some tools duplicated between carousels. >> >>> max force - The maximum force use while cutting - one could set the >>> control to change tools if max force is too high. >> Hmm, another thing to add to the list. (There probably needs to not >> be >> a "list". Tool-table entries should be integrator-configurable.) >> > > This is starting to sound like the ISO STEP-NC project > (http://en.wikipedia.org/wiki/STEP-NC) which produced ISO 10303-238, > "Application protocol: Application interpreted model for computerized > numerical controllers" and the concomitant ISO 13399 "Cutting tool > data > representation and exchange" > (http://en.wikipedia.org/wiki/ISO_13399). > Don't expect the ISO documentation to be easy to obtain or to read > once > obtained. > > I believe my old friends at Step Tools, Inc., have some useful > material > online (http://www.steptools.com/products/stepncmachine/). > > Lists and tables are not very satisfying data structures. Chris's > first > example reminds me of the problem that relational database > normalization > was intended to solve when it was introduced forty years ago. > > If a relational database approach isn't acceptable, how about an > object-oriented database approach instead?
Is STEP-NC a strict superset of RS274D (or one-to-one translation from g-code to STEP-NC)? If so, maybe we could look at implementing STEP-NC in LinuxCNC-[3,4]. Also, with regards to language support of features... Over a decade ago I wrote a fully runtime polymorphic parser that allowed me to overload g-codes at runtime and support different interpretations without having to recompile the base code. (think dynamic loadable modules). I'm more than glad to give this to you if you would find it useful as a prototype, but will need to be revamped -- it is 13 year old experimental code... EBo -- ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
