On 7/15/2013 10:31 PM, David Bagby wrote: > 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. In thinking about some non-traditional machines, for example lathes with multiple cross-slides and/or chucks, I could imagine having multiple concurrent active sources and motions.
That might be considered out of scope for this project, but I'd hate to rule something out today when it might be easy to include if we plan correctly. This is another example where thinking in terms of singletons is a bad idea. Ken > 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 ------------------------------------------------------------------------------ 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
