On Tue, 2012-11-06 at 12:33 +0000, andy pugh wrote:
> (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?)
Wow! A comprehensive and coherent tool table approach is not going to be
easy.
Random thoughts:
In my limited thinking it would never occurred to me to pass all the
tools in one nml message. Someone has suggested a python API which makes
sense to me. Again in my limit thinking I can see no reason to do any
more that pass info on the requested tool ... interp -> task, ...
I can think of two schemes to define tools; a. APT style to define
geometry. b. use insert data. 'A' would appear to work better for mills
and 'b' to be more suited for a lathe. This is only my view and others
may strongly disagree.
For either approach I think the user will have to enter the data for
their insert or tool as there are enough combinations to make a fairly
good sized database.
Discussion is appreciated. None of us know it all. Darned!
Dave
> 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
