Am 09.11.2012 um 01:14 schrieb andy pugh: > On 6 November 2012 16:34, Michael Haberler <[email protected]> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
