Re: [Emc-users] The Ideal Tool Table
Am 09.11.2012 um 01:14 schrieb andy pugh: On 6 November 2012 16:34, Michael Haberler mai...@mah.priv.at wrote: 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. I think this means that it doesn't matter where G-code changes to an unloaded tool are stored, as there should be a synch at tool change. yes we need to do some careful reading of the code of: - where the interpreter syncs its tooltable view - how the interpreter picks up an externally edited tool table - how iocontrol picks up changes - how UI's pick up changes and think through how change notifications might need adapting, if any as I understand it, currently Axis sucks the whole tooltable at startup, and goes from a local copy, resynching only on toolchange ie, given a single central repository of tool data, if G10 L2 wants to change a value in there, then it can. And if the user then uses tool-edit to change it back, then they _probably_ want the G-code to use their value after tool change. (though their tool editor would ideally flag that). Once the path is committed to the queue using the tool data current at the time, then I don't think that there should be any expectation that tool table changes alter that. I guess the question is whether VPT / motion queue is continuous through tool changes. As Redis writes are guaranteed atomic, I am not sure that it would be totally unacceptable for anything that wants tool data to just grab it directly. (though at the same time there is no point duplicating the code, so a simple API makes sense). I don't think anything in kernel space uses tool data? Though clearly the tool and pocket numbers end up in kernel/HAL no what we need to break the NML size limit is the following change: EMC_STAT will not contain the 'full tooltable', but only the entries currently needed and the 'machine view': those are - the current tool descriptor - any prepared tool(s) descriptors - a reference which entry is the current tool (or say -1 for 'no tool loaded') - a reference which entry is the current prepared pocket (or -1 to mean 'no prepared pocket') a 'change' then means: adjust references a 'tool unload' then means: set toolref to -1 a 'pocket prepare' means: set prepared-ref to corresponding entry a 'pocket unload' means: set pepared-ref to -1 this leaves, in principle', the path open to have multiple toolstores/pockets as it gets around the magic meaning of 'current pocket' to be a unique array index and: no more swapping of entries in the NML message. -m -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] The Ideal Tool Table
Am 06.11.2012 um 18:15 schrieb Michael Haberler: Am 06.11.2012 um 17:34 schrieb Michael Haberler: 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++). what I will contribute to the effort: I will rework the redis-used-for-persistent-parameters patch (Daniel Rogge's work which I reworked for Redis, but I havent committed it yet) to use exactly the API style I'm talking about: callout into Python, and do the 'database dependent' work in Python - that can be used as an example for the toolstore API calls extra upside of eating my own dogfood: the Redis-dependent C/C++ code can be eliminated, and I didnt like that to start with - LinuxCNC _compiled_ code remains DB-agnostic this is the (still un-Pythonified) branch I'm talking about: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-params as promised, here comes the delivery on the above: The modified branch is here: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/interpreter-python-api-numbered-params and it contains examples for a simple embedded Python api for numbered parameters, with an eye towards reusing it for other tasks like tooltable work. This README should cover most questions on functionality, configuration and possible reuse: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/42bc65f4d4e5585dbf6b6dc7d89cd4db896b32fc:/src/emc/rs274ngc/README.python-numberedparams-api - Michael 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
Re: [Emc-users] The Ideal Tool Table
On 9 November 2012 08:10, Michael Haberler mai...@mah.priv.at wrote: what we need to break the NML size limit is the following change: I am still reading the code and trying to see at which point the tool table is passed in an NML message. (I am not well practiced at teasing apart code, especially complex code, that I didn't write). EMC_STAT will not contain the 'full tooltable', but only the entries currently needed and the 'machine view': those are - the current tool descriptor - any prepared tool(s) descriptors - a reference which entry is the current tool (or say -1 for 'no tool loaded') - a reference which entry is the current prepared pocket (or -1 to mean 'no prepared pocket') Is there a reason that this information can't be pulled out of the central data store every time it is used? Why does EMC_STAT need anything but the current tool number? (ie, what does it do with this information?) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] The Ideal Tool Table
On 6 November 2012 16:34, Michael Haberler mai...@mah.priv.at wrote: 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. I think this means that it doesn't matter where G-code changes to an unloaded tool are stored, as there should be a synch at tool change. ie, given a single central repository of tool data, if G10 L2 wants to change a value in there, then it can. And if the user then uses tool-edit to change it back, then they _probably_ want the G-code to use their value after tool change. (though their tool editor would ideally flag that). Once the path is committed to the queue using the tool data current at the time, then I don't think that there should be any expectation that tool table changes alter that. I guess the question is whether VPT / motion queue is continuous through tool changes. As Redis writes are guaranteed atomic, I am not sure that it would be totally unacceptable for anything that wants tool data to just grab it directly. (though at the same time there is no point duplicating the code, so a simple API makes sense). I don't think anything in kernel space uses tool data? Though clearly the tool and pocket numbers end up in kernel/HAL -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] The Ideal Tool Table
Am 06.11.2012 um 21:54 schrieb andy pugh: On 6 November 2012 19:55, Jan Van Gilsen janvangil...@gmail.com wrote: Maybe you could use this geometry: http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg I suppose that is one way to be very general. But excludes ogee router cutters and panel-raising bits. Then the question becomes how general we want to be, considering that LinuxCNC only pays any attention to diameter. If cutsim or anything similar is ever likely to replace the current preview (or would hook into the same tool database) then perhaps is it worth considering. To an extent it doesn't matter how many values we store, as the tool table will only display the ones chosen (the default set could be chosen to be sensible, and based on machine type) right dumb question: doesnt this industry have some standard describing tool geometry? like an XML format? (I'm not saying 'use XML'; I'm saying: 'steal an existing, widely used database schema if possible', we'll care about import later) - Michael -- 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
Re: [Emc-users] The Ideal Tool Table
On Tue, Nov 6, 2012 at 12:33 PM, andy pugh bodge...@gmail.com 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 That NML message restriction is just silly, just send a few tools per message, those that are about to be used. Yes there are some machines that use a number at a time/setup, I could envisage up to 10 maybe but but still gcode is restricting you to changing one at a time :) Dave Caroline -- 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
Re: [Emc-users] The Ideal Tool Table
On 6 November 2012 13:08, Dave Caroline dave.thearchiv...@gmail.com wrote: That NML message restriction is just silly, just send a few tools per message, those that are about to be used There is a further complication with the current scheme (and with your proposal) that means that several different opinions of the tool table values can exist at any one time in different parts of the code. By having each module extract the data from the database when required this problem is somewhat reduced. I suspect that it would be difficult for the code which transmits the tool table in the current structure to know which tools the requesting code wanted. Another inelegant feature of the current method is that it enforces a one-tool-per-pocket limit. I can conceive of a few scenarios where this is a limitation. (Gang tooling, and a rack changer with interchangeable racks, for example) -- 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
Re: [Emc-users] The Ideal Tool Table
I suspect that it would be difficult for the code which transmits the tool table in the current structure to know which tools the requesting code wanted. Another inelegant feature of the current method is that it enforces a one-tool-per-pocket limit. I can conceive of a few scenarios where this is a limitation. (Gang tooling, and a rack changer with The sliding head in the garage has two tools on a rocker so there is an inversion in direction for cutting too :) Dave Caroline -- 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
Re: [Emc-users] The Ideal Tool Table
On 6 November 2012 13:42, Dave Caroline dave.thearchiv...@gmail.com wrote: The sliding head in the garage has two tools on a rocker so there is an inversion in direction for cutting too :) That can be accomodated in the existing structure in at least two ways. 1) You can use negative diameters when using the other-side tool. This just works 2) You can use coordinate rotation around the Z axis (optionally with a G-code remap) to switch to the rear tool. Discussion here: http://www.linuxcnc.org/index.php/english/forum/26-turning/24729-gangtool-setup--backtools?limitstart=0 -- 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
Re: [Emc-users] The Ideal Tool Table
On Tue, 2012-11-06 at 12:33 +, 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
Re: [Emc-users] The Ideal Tool Table
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
Re: [Emc-users] The Ideal Tool Table
Am 06.11.2012 um 17:34 schrieb Michael Haberler: 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++). what I will contribute to the effort: I will rework the redis-used-for-persistent-parameters patch (Daniel Rogge's work which I reworked for Redis, but I havent committed it yet) to use exactly the API style I'm talking about: callout into Python, and do the 'database dependent' work in Python - that can be used as an example for the toolstore API calls extra upside of eating my own dogfood: the Redis-dependent C/C++ code can be eliminated, and I didnt like that to start with - LinuxCNC _compiled_ code remains DB-agnostic this is the (still un-Pythonified) branch I'm talking about: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-params - Michael 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
Re: [Emc-users] The Ideal Tool Table
Andy, Maybe you could use this geometry: http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg This results in different possible tool shapes: http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr2.gif from: http://www.sciencedirect.com/science/article/pii/S0890695501000451 Regards, Jan -- 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
Re: [Emc-users] The Ideal Tool Table
On 6 November 2012 19:55, Jan Van Gilsen janvangil...@gmail.com wrote: Maybe you could use this geometry: http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg I suppose that is one way to be very general. But excludes ogee router cutters and panel-raising bits. Then the question becomes how general we want to be, considering that LinuxCNC only pays any attention to diameter. If cutsim or anything similar is ever likely to replace the current preview (or would hook into the same tool database) then perhaps is it worth considering. To an extent it doesn't matter how many values we store, as the tool table will only display the ones chosen (the default set could be chosen to be sensible, and based on machine type) -- 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
