On May 18 2013 3:00 AM, Michael Haberler wrote: > 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 am in complete agreement. I think I had the wrong mental model when I read the post. >> 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 yes. I like it. This also gets around the problem of bootstraping and expecting the user to do everything from scratch. > 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 It is just this type of inheritance that got me to thinking of OOD. We can also abstract the inheritance scheme to build classes of tool types (like an endmill is very different from a lathe bit or a fly cutter, and I think I can say that all end mills share some aspects and it becomes more specific when you talk about 2-flute/6-flute, left/righ spiral... Maybe that is not the right way to think about it, but was a start. Yes, agree on all points. 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
