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
