Am 18.05.2013 um 10:33 schrieb EBo <e...@sandien.com>: > On a more theoretical level, does it make any sense to have more than > 6-D offsets for a tool? If a tool has some length, then row/pitch/yaw > can come into play, but I am having trouble conceptualizing a 7-D+ > offset (unless other dimensions include info on force feedback or tool > friction). That being said, I agree that there is no real reason to > limit the table size and just keep it an n-tuple. > >> then you have a relation describing the active offsets, which is 1:N >> in nature (a tool can have an arbitrary number of offsets or none at >> all): >> >> tooloffsets(toolid, offsetid) (only toolid is a primary key) > > Getting back to the abstraction of tool number (which is a CNC > programming abstraction, ie. T01), tool UID, and the offsets which I > think only make sense attached to a given unique tool id. So, I would > conceptually explore something like this: > > set_tool(toolnum, toolid) (where toolnum equates to something like > T1) > set_tooloffsets(toolnum, offsetid)
I think in the real model (that was a simple(minded) example for warming up folks to the concepts) one would distinguish between a tool type, and a tool instance the type uniquely describes a geometry and purpose, where as a tool instance describes a particular tool, numbered, likely loaded in a magazine, and offsets, holders, wear etc are keyed on the instance, not the type what we have as 'tool number' in gcode then really is the instance number the reason for distinguishing those objects (and that was around on the list too) is that that you can have several instances of the same tool type, which enables for instance automatic swapping of tools depending on wear or breakage, another operation which is impossible to model now (I dont say this needs to be done in round one, but I think it's reassuring one will be able to model this if the need arises) > I can also see tooloffsets(toolid, offsetid) in the relations table. > Hmmm... maybe that is what you meant whereas I was thinking in > programming model instead of relations model... So, we should be clear > when we talk about relations/program models to make sure we are talking > the same thing, but to further the discussion I would like to keep the > idea of abstracting the tooluid from the toolnum. I think so too; note that distinguishing the two enables another feature impossible to describe right now: you can load some tool manufacturer database into the tool types table which is static and likely non-linuxCNC specific; hence shareable when you define a tool, you associate an tool instance id with a type id as per manufacturer, and inherit the properties from the type entry by means of a view, but the type is not the instance and hence doesnt need to carry any linuxCNC specific keys -m ------------------------------------------------------------------------------ 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
