Am 31.10.2012 um 10:50 schrieb andy pugh: > On 31 October 2012 08:05, Michael Haberler <[email protected]> wrote: > >> looks like I'm married to the keywords 'tool table', and I'm responsible for >> Xmas lighting now, too;) > > And the music too. > >> A while ago I suggested a DB approach to the tooltable - which would have >> allowed for a tool being retrieved through a view, like including holder and >> wear offsets. > > I thought this was why Redis had been brought in? Or at least part of > the reason.
It was a tradeoff. Redis brings uniform persistence for global state - which is needed in many corners MySQL would have brought this and a higher level data manipulation language, at a considerable expense of installation/running effort SQLite would brought a similar data manipulation language, but isnt really multiuser capable nor networked Redis has a lower-level query language than the previous two, but all it needs is a single process, an API library and a Python binding the tool wear/tool holder offset thing surely can be done in redis - at that lower level, but first some brave soul needs to come around, rip out the existing TT, and replace it by redis IO - that I really would like to do in LinuxCNC3 but I'd be happy to support someone doing it in the current codebase. probably the best way to go about it would be to make tool state access embedded Python calls, which makes the whole thing a Python affair, including Redis data manipulation -m btw: the use of Redis in a forthcoming patch already uncovered a race condition in the current startup sequence - the UI's access persistent parameters before the interpreter has gotten around to writing them; this doesnt show up in the current "read whatever is in the .var file" approach because it doesnt detect sequencing errors > I have been expecting a shift to a database tool table to happen in > the future, but when (and who) I have no idea. > > I think we need to allow wear offsets, and for slot numbers and tool > numbers to be independent. And once you do that the available number > of tools (as I understand it) becomes very limiting. > We already have people with more tool slots than LinuxCNC can handle. > > Once you have the wear offset and geometric offset distinction > implicit in the tool-table then the Fanuc-style tool change option > become less intrusive, I think. > > -- > 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_sfd2d_oct > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ 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_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
