Am 02.04.2014 um 16:23 schrieb Rod Fitzsimmons Frey <[email protected]>:
> Thanks, your explanations really help. I actually think there's a > astonishing lack of entropy in the code, given its age and the inherent > complexity of the problem. It's all coming together for me with your > explanations. would you mind taking notes along your safari, and make that a document fragment which can be included in http://www.linuxcnc.org/docs/devel/html/remap/structure.html like as a case study? I think that would help lots of other folks downstream - I might just have tunnel vision, like 'all obvious to me' so I'm not a good author for that type of document 'lack of entropy - I like it ;) - Michael > > > On Wed, Apr 2, 2014 at 7:29 AM, Michael Haberler <[email protected]> wrote: > >> >> Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey <[email protected]>: >> >>> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
