Hi Andy, great to see the tooltable issue gets attention.
having thought about it in the past, and decided I leave this for LinuxCNC3 ;) anyway let me note some observations and suggestions how to go about it. first, views. the notion of a 'table' might suggest that this is a tabular arrangement of data which code consults and gets a unique answer every time. This is not the case, and it has to do with interpreter readahead. What you have in reality is an 'interpreter view' and a 'machine view' of the tool information, and they might fall apart during readahead as the NGC program might change tool attributes on the fly. Only at commit points like a tool change, or set tool number, or set offsets, are parts of the readahead view synchronized with the machine view. From there on, views might diverge again. A data model for the TT needs to keep that in mind. The table in the EmcStat message represents the machine view. The interpreter view is currently not necessarily externally visible as there are no interpreter interfaces (like callouts to a datastore mechanism). second, types of information and their use, and keys into them. Note a 'tooltable entry' lumps together all sorts of information and keys them 1:1 on a row id, the tool number, which is very restrictive to start with. We have (at least): offsets, diameter, tool orientation, and they are used in very different parts of the interpreter: Offsets: impact commanded position, and limit violation detection. Offsets do not impact tool path shape computation. Diameter: this impacts tool diameter compensation and hence path shape computation, and possibly others. 'Tool orientation' also impacts gouging detection. Then there are some things on the collective wish list, like: wear recording and compensation; multiple tool instances (for instance I learned one other control has the capability to define a group of tools which define a tool instance; you 'toolchange' to an instance and the control pulls one of the class members which has acceptable wear, and disables tools with excessive wear automatically) I remember a suggestion for tool holders; a tool is held in a holder of a certain type, which basically adds a holder-specific offset. In summary, you suddenly have several types of objects with different keys (tool classes, wear records, offsets, tool geometry information) and suddenly the idea of a 'table' collapses because it is an inadequate means - at this point kludging appears and we find repeated entries with different meanings and so forth. Then again for many the above laundry list might be much shorter, and many features irrelevant. ---- That said, I think the starting point should not be 'how should the tooltable look'. It should be 'what information is accessed, modified or committed, and by which entity'. In the interpreter the points where tool related information is accessed, modified or committed need to be identified, and translated into an API. So, the interpreter cant just fiddle some offset data structure internally, it must go through an API, like get_offset(), set_offset(), get_diameter(), set_diameter() get_orientation(), commit_view() etc. The other design question is 'who manages the machine view, and how'. This is currently the iocontrol process, and it communicates the machine view through the current limited table in EmcStat. To break the size limit, the machine view can be restricted to two tools: the current and the prepared tool. In essence, iocontrol needs to go through the same API as the interpreter. Thinking through and implementing the interpreter/iocontrol toolstore API, the machine view mechanism, and how commits are communicated (right now iocontrol is kicked by an NML message), is the hard part of the work. The 'how should the table look' aspect then becomes the fun part of the problem, and it suddenly becomes amenable to integrator adaptation. Once you have that API in place, then you can tack an arbitrarily complex or simple toolstore onto it, and it might be the current table, redis, Sqlite or whatever. The point is: the interpreter, iocontrol and the rest of LinuxCNC should not know, and should not care how this is done. This is what APIs are all about. The mechanism I would choose for this API is to reuse the embedded Python code which is already in place, robust and quite simple to use. The API calls I listed above would just map to Python methods of the same name. There is just no reason whatsoever to go through a C/C++ API *externally* (internally we have to as long as iocontrol and interpreter are in C/C++). Suddenly this whole tool access mechanism is at the Python level, and from there you can use the flat file, Redis, Oracle, whatever - the rest of the code is not impacted anymore. --- the whole thing is a sizable task, and nontrivial. it really needs planning of the API, identifying where the API needs to be inserted, peer review of plans. I am happy to contribute; I'd really appreciate if somebody else took the lead and it is great to see the leader has been identified ;) - Michael Am 06.11.2012 um 13:33 schrieb andy pugh: > (Originally posted to the dev list, but there appear to be no opinions > on the matter there) > > So, having started to think about how a database-based tool table might work > (As background, the currently tool table only supports 56 tools, > because that is what will fit in an NML message. Any module that wants > tool info gets sent the whole tool table. > If we wanted to add separate wear offsets, then we would probably have > a 20 tool limit. There has been talk for a while of keeping the tools > in a database as one way t circumvent this limit.) > > Each tool has a number of characteristics: > > Tool number. Can more than one tool of the same tool-number exist? > Redis wants a unique key for each entry. Do we make the key be the > tool number, or keep it separate? > (ie, find the tool with number 1, then return the diameter of that > tool, or simply return the tool:1:diameter?). > I can see how you might want a database of named tools, and just > change their allocated T-number to suit. I can also see that mandating > unique T-numbers would be reasonable. The interface to G-code is > likely to always be a numeric tool number. > > Pocket Number. I think more than 1 tool can share a pocket (gang > tooling, or alternative tool-sets). > Currently pocket-zero is the spindle. How do we handle tools that are > not currently available? (Pocket "none" might work) > > Each tool can probably have geometry and wear offsets in XYZ/UVW. Do > we need geometry offsets in ABC? How about wear offsets? > > Diameter/Radius > > Front Angle / Back Angle > > Comment. > > Nose radius? Might be useful for clever kins or cutting simulation in > the future. > > SFM? Material? Insert code? Or are those all comments? > > With something database-y it seems we can add values simply as and > when required. Then the tool-editor(s) can simply access what they > want and not even notice the rest. > So there is a subset of things that need to be available for current > code, and then a number of items that might be added for future > modules (automated insert ordering based on logged usage....) > > It is even possible that the tool editor might be allowed to add extra > columns. (there is an INI file option to hide irrelevant columns, why > not allow people to add ones too?) > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
