Am 02.05.2012 um 16:07 schrieb Kenneth Lerman: > Michael, > > It appears that there might be a problem with cutter radius > compensation. Whenever that mode is on, lookahead will be effectively > disabled because any pause can cause the diameter to change. (Or do I > not understand something?)
That is because in the current design the CRC offset curve is computed in canon and therefore committed at motion time. In the revised design, two pieces of information migrate to the 'gcode executor', tentatively called 'VPT machine' (virtual paper tape machine;): the tool offset, and tool attributes pertaining to cutter radius compensation, effectively making these parameters not 'committed at program start time' and hence subject to change during pause. The current idea is that the 'virtual paper taper' really is a list of parsed blocks. What this means is you have a dual-queue arrangement in the VPT machine: 1. the VPT as it comes from the frontend 2. the motion queue on 1) TLO and tooldiameter are not committed yet but available for offsetting and CRC on 2) both values are factored in and committed. Between 1) and 2) happens application of TLO, and offset curve computation, which might need an auxiliary path data structure. However, when tool diameter is changed, the current offset path can be thrown away and recomputed. If 1) is a circular buffer, step-back-by-block is within reach; so far we had only step-forward. Re tool information: this means that VPT machine will be the authoritative source of tool information (TLO and dia), and be able to committ to the tool table on changes. It will probably be the remaining consumer of tool information as the frontend need not know much about tool parameters. As for the frontend, this is largely reduced to the roles of parsing, interpretation of control structures, and doing the right thing when accessing a parameter, which my note was about. Correctly detecting limit violations at parse time needs some more thought, as some limits are subject to change during execution due to TLO and diameter; false negatives are a nuisance, and false positives would be worse, so runtime checking still is needed. This suggests the work to drop in a different language or a different interpreter is substantially reduced; I discussed this offline with Joseph who did the openscam interpreter, and it looks real straightforward so far (ha!). Semi-related: motion id's will become 'block serial numbers'. The block serial is a key to a source location, and also to the interpreter execution state at the point where the block was generated. Block serials relate n:1 to source locations and 1:1 to execution states. The above reflects my understanding of IRC discussions with Chris, I hope this matches his. We still need to write this down, this is very early into the shakeout process. - Michael > > Regards, > > Ken > > On 5/2/2012 4:57 AM, Michael Haberler wrote: >> Am 02.05.2012 um 10:30 schrieb Viesturs Lācis: >> >>> 2012/5/2 Michael Haberler<[email protected]>: >>>> So, 'changing to MDI, fiddling some parameters and returning to auto with >>>> the new parameter settings' in the general case isnt what you want because >>>> of the side effects. What is probable doable is: use MDI mode as way to >>>> move around, and nothing else, but then thats really just a glorified jog >>>> mode. 'Doable' doesnt really translate well into 'desirable'. >>> >>> Thank You very much for Your patience in explaining this! >>> I agree that there is no much use for MDI except for situations, when >>> emergency tool change is required >> yes >> >>> and then interpreter somehow has to >>> be told about that fact. >> No. >> >> The whole point of the changes under discussion: they are restricted in >> scope very carefully so you do *not* have to tell the part of the >> interpreter which does readahead about it, for the same reasons we >> discussed: avoid queue stalls, and avoid 'backing up the interpreter' (see >> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WhyManualWhilePausedIsHard) >> >> The only change wrt to the interpreter is the access modality for tool >> length offset and tooldiameter parameters (#54xx): so far those were >> considered untainted because no entity except the interpreter could change >> them. They now can change at any motion (due to toolchange during pause), >> which is why came up this state reference model in the first place - they >> are now 'tainted by motion'. >> >> That said, the only execution difference will be: if you refer to a #54xx >> parameter, a sync will happen before the referencing block is executed. So >> far it didnt. But that shouldnt cause any user-visible behavioural change >> except that 'current tool parameters as seen by the interpreter are "more >> correct"' ;). >> >> - Michael >> >> >>> Other than that - the chance to move around >>> during pause is already there. >> >>> 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 > > ------------------------------------------------------------------------------ > 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
