Hi, Both John and Jon have commented on the relationship between MDI and a gcode interpreter in the pics I drew - and they are right.
I really should have set my thinking context a bit better within the text. I did draw the picture as if MDI was independent of the gcode interpreter... because I tend to look more at what is the desired behavior target, vs what does the code do now. If we want a pic of what the current code does, then the mdi is a text input gathering block; it feeds the gcode text into the gcode interpreter and that feeds motion (at least as far as I currently understand the it). This is the point Jon & John made. I was thinking more about what was wanted on a system conceptual level; that lead me to draw MDI as an alternate source from the gcode interp. Consider for a moment MDI as a generalized concept that gets motion language text from a human - that text input might be gcode, or it might be some other language - once we have multiple motion sources, lots of language possibilities open up. If the language is gcode, then whether MDI feeds into "the" (single) gcode interp is a matter of how many concurrent instances of an interpreter there can be. If there can be only one (as the code is today) then we get "the" (single) interp instance and thus that single instance has to handle any/all gcode - that forces sources to be sequential in nature. In contrast, if we could have more than one concurrent instantiation, there could be one interp for each gcode source. Now MDI does not have to feed "the gcode interp". Generalizing another step (still assuming interpreted languages) we can have motion sources with a corresponding interp for each one. That is really what we have with the "non-gcode python block" in the pic. As I write this, I an envision MDI as taking python code and feeding it to the python interp and that feeds motion. I'm now thinking of MDI as an operator UI block. That makes it easier to think about when MDI wants to be allowed and when it does not. The only one active source at at time model seems to be handling the situation I can think of so far. So separating "motion source" from "how motion source language is processed" seems to be useful - and that lead me to the pic as I drew it. Of course I did not state all that (oops). I don't know why it was not obvious as having been stuck between the lines of the minimal text I added to the pics (my apologies for being too terse). I'm finding that as I think about control architecture, I tend to go to "what I'd like it to be". I find that helpful as it is not constrained by current implementation; (it also matches well with the fact that I don't have the detail knowledge of what the code does internally today that some other people have). ;-) In a couple of conversations now, I've noticed that talking about architecture at a building block level causes some folks to point out "what is today".. and & I like it when that happens. That's how some of the white butcher paper drawing came to be in Wichita: I drew what I thought made a good future target at a module level; Micheal got that; and he then talked about what happens in the code today. The contrast was both fascinating and educational. That "now vs target" conversation is exactly what is needed for (what is to me) the 2nd step when doing a Gedanken experiment (Kent: had to work my new word in here some how) - a goal is not much use if one can't see how to make a practical transition plan to get from where the code is to where it could be. Sometimes possible road maps appear and are easy, sometimes it's harder and sometimes it just isn't gunna happen. I find them all to be good results in that they teach me more about how this LCNC beast works. I'm mulling over Michael's comments about what are desirable characteristics for the canonical API level that I placed in the pics as feeding motion. I need to think about this some more. Dave On 7/15/2013 6:01 PM, Jon Elson wrote: > David Bagby wrote: >> Hi, >> This thread caused me to clean up some notes I'd jotted down during >> Wichita related to this topic. >> In this thread I think that different people are talking about >> different aspects of a topic that I think of as "implications of >> multiple programmatic motion sources". >> >> Alas I think about this stuff better with pictures... (unfortunately, >> it's a little hard to share text and pics via a text only email list >> that does not allow attachments). >> So pardon me, but the best I can think of to do is to upload a pdf >> doc with pics and ask that you grab it to look at. >> www.CalypsoVentures.com/privatedl/LCNC/LCNC_control_mode_distinctions.pdf >> >> > All your pics show MDI bypassing the G-code interpreter. I'm pretty > sure that > MDI must go THROUGH the G-code interpreter. > > Jon ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
