On Fri, 2013-05-17 at 21:07 +0100, andy pugh wrote: > On 17 May 2013 20:06, Dave <e...@dc9.tzo.com> wrote: > > > I like the idea of a database. However, realistically, how many > > people/users are going to want to apply the wear offset from one tool to > > a different tool?? Is that a requirement/desire by someone?? > > There certainly seems to be an argument for more than one set of > offsets per tool (applied additively). > A nominal 8mm milling cutter, plus a regrind offset, a standard lathe > tool + wear offset. > I don't know if you would need more than two offsets. I suspect that > three would be plenty. > > One use-case for sharing an offset would be for duplicate tools. They > could share a geometry offset (these both take the same insert, and > are the same length) with a "tweak" for their differences, and a > second "tweak" for wear. > > One situation where duplicate tools would make sense would be if you > had job-specific toolchanger magazines, both of which contained a T1 > turning-and-facing tool, but different physical tools. > (the multiple-magazines idea need not apply only to physically > separate magazines, they could be different populations of tools in > the same tool chain for different jobs. Why edit the whole tool-table > if you can simply switch setups within the same tool-table?). > Admittedly in this situation all T1s would probably be exactly the > same T1. > > We even have a user who could usefully have duplicate tools. > Skunkworks has a large, slow, unidirectional tool-chain. I doubt he > cares _which_ 1" end-mill he gets when he asks for one. >
Indeed Kent did get my attention with a mention of a step dll for APT. I just want an easier path from the geometric defs of APT to tool paths. I know absolutely nothing about OODB but at one time did a SQL database for my lab. The closer the table designer is to the real application the better the design is likely to be. I've seen database professionals make a complete mess of tables for a lab. One needs to understand the flow and interrelations of the data so the tables make sense. At least with SQL there is an extensible structure to work from. The API will shield the user (hopefully) from the details but make it possible for a 'plain' user to modify the tables without pain. Someplace around here I still have a copy of Date's book, unless I've loaned it out...... .... a very wordy tuppence. Dave ------------------------------------------------------------------------------ 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
