Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey <rodf...@gmail.com>:
> To test my understanding: is it legitimate for the python mapping code to > call canon methods directly? Would that mess up state for the interpreter > when it continued executing? to be more clear: canon is primarily a 'downwards' API - sending instructions from the interpreter to task and eventually motion, so safe to use from an interpreter state perspective the exceptions to this rule are those GET_* canon calls which retrieve machine state to synchronize the interpreter; for instance, after a probe, interp needs to query the machine (or indirectly motion really) where the probe stopped; otherwise it wouldnt know where the tooltip currently is. But AFAICT all of these calls are referenced in the interpreter init() and sync() methods: Interp::synch(): http://goo.gl/0kwDTf (eg line 1894 onwards) Interp::init(): http://goo.gl/tyPljj meaning: as long as you dont do anything which might break position prediction (probe, toolchange, read pin), you are good to use any number of canon calls in sequence - this chapter http://goo.gl/6AC8CF may help to understand what is going on if you use one of those 'queuebuster' operations, a synch() with the machine state is needed - that is exactly what happens in the read_pin example I gave, by using the 'yield INTERP_EXECUTE_FINISH' statement in terms of canon documentation, http://goo.gl/6gcbpY is the best overview sorry if this sounds pretty complex - it is, but let me put it this way: the control flow of task and interpreter is 'intricate', to put it politely; some might choose to call it 'botched beyond repair - rewrite from ground up required'; with remapping I tried to avoid that huge rewrite and the cost is complexity in dealing with it - Michael ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
