Am 01.05.2012 um 22:35 schrieb Viesturs Lācis: > 2012/5/1 Michael Haberler <[email protected]>: >> on #linuxcnc-devel there's currently a discussion (mostly cradek and me in >> the last few days) about a future linuxcnc design. In that context, >> 'queuebusters' and the synchronization of interpreter state came up. >> >> I think I came up with a more elegant, flexible and language independent >> solution to this issue than we currently have >> >> I've written up some thoughts here: >> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited >> >> I'd appreciate any comments > > I love reading Your explanations! Because at least during reading I > feel that I understand it. > > Could You, please, explain, what is the benefit of these changes?
The background was the following: we discussed changes which would permit changing tool offset and cutter radius during a pause operation. Under the current scheme, this would mean: - the handling of parameters 5400-5413 needs to be changed in the interpreter; something which wasnt considered a 'queuebuster' so far since it wasnt possible anyway suddenly looks like a queuebuster. - changing a tool and its parameters during pause has no corresponding underlying g-code operation, so I dont see any clean way to do this in the current scheme since this is keyed to an *operation* - by keying synchronization on state access, this becomes possible, and in fact with low effort - the only change which is needed is to a static variable descriptor (in the case of tool length offset and radius this would mean: any use of #5400-5413 would cause a sync before the block where it's referenced). The rest is automatic. - a nice side effect: since this means parceling out parameter access and synchronisation into a, say, C++ class, any other language could use that class, and get the same effect - be that RS274-on-steroids, Python, APT360 or whatever is yet to be invented. > You mentioned "lookahead" several times. Do I understand correctly > that it includes the same "lookahead" of more than 1 g-code line for > trajectory planner that was discussed in relation to arcs and other > part geometry being described as small G1 moves? yes, that is one of the reasons for 'reading ahead' in the interpreter - it's really hard to plan if you dont know what's coming next;) -m > Viesturs > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
