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 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
