Chris,
I have been asking myself this question too. I find no good reason for it
either.
My current theory is this: the distinction exists because of:
1. a conceptual mixup of an input method, and a machine state
2. the lack of concept of a concept of what is called a 'compilation unit' - a
unit of interpreter processing if you will
3. (unsure) failure to spell out clearly what the difference in execution
semantics between MDI actually is
ad 1) I dont see any good reason to tack a 'machine state' onto the - rather
irrelevant - question whether input to the interpreter comes from a file, or a
a string (that _is_ the current distinction as far as the interpreter and task
goes). At some very distant past 'MDI' obviously was meant to be 'a single
block', and that is history, adding to the confusion. Inputting 'o <procedure>
call' is technically MDI nowadays, it could translate into millions of blocks,
or just one.
Example: assume you have several input tabs, each having an editing window for
GCode. Some of these windows might be backed by a file, some not. You might
pass a line (aka block) to the interpreter by selecting a line, or you might
highlight several. Why does the fact that a window is backed by a file have any
bearing on some 'machine state'? Beats me.
ad 2) the current architecture has no provisions to delineate a unit of input
to the interpreter downstream. What the interpreter generates is some sausage
('queue') of motion primitives, but it doesnt say where a input unit started
and where it ended, and that has consequences - for instance, the motion
component has no way to determine if a underrun of commands happened because a)
the interpreter decided not to generate more, e.g because of a bug b) task
decided for some reason it wouldnt schedule commands to motion c) the operator
fell asleep at the MDI input window. That is a fairly bizarre deficiency, but
for some reason it did not cause enough concern so far to prod some rethinking
of the way how things are done.
ad 3) Conjecture: MDI was originally meant to mean 'a single block followed by
an interpreter sync()'. I would be interested to hear opinions on that. If that
happens to be the case, then it is a valid problem with a silly solution. A
better solution to the problem would be explicit readahead control, meaning you
could specific 'sync the interpreter here by some G-code', 'sync the
interpreter after each step' or 'sync as usual'. That is a parameter of the
'compilation unit' or a Gcode therein, it has nothing to do with machine
states. Think of it as a checkbox on the current MDI tab.
As always with architectural deficits, those show up relentlessly in the
bugtracker. Related to this particular one - the lack of a 'compilation unit'
concept and a lack of source backreferences beyond a single integer value (the
'line number' which reappears as 'motion id' and consequently is broken since
it isnt unique anmore) shows up in recurring bugs in:
- run-from-line bugs
- a pathetic hack using negative line number (aka motion id) to indicate 'MDI
mode', now backed out
- motion fails to tell a bona-fide command underrun from a program end
- the rash of mdi oword processing bugs (that has some other reason to it as
well, for instance the rather bizarre inversion of control flow between task
and interp)
- Seb's and my quest for fixing bugs in 'queued MDI' which turned out to be a
red herring from a design perspective to start with, but nevertheless happily
used regardless thanks to a bug which made it appear to work
You're spot on on revisiting some of the prevalent concepts - they might not be
particularly good despite the fact they've been in use for a decade or more.
- Michael
sorry for the top posting, but I wanted to leave this in one flow.
Am 14.07.2013 um 23:00 schrieb Chris Morley <[email protected]>:
>
>
>
> This has been bugging me awhile.
> Why does linuxcnc force three modes?
> I understand it's a hold over from industrial machines.
>
> For my Okuma, manual functions were actually done
> outside the computer's control using relays and such.
>
> What is the actually programical distinction needed in
> linuxcnc's case.
>
> As a GUI builder, it's really is a pain in the ass to trick
> linuxcnc to do MDI commands in manual mode and
> I see no reason for it.
>
> To set the origin, index the tool, and change the user system
> require MDI mode.
>
> I could see a distinction between issuing commands that do
> one thing no matter what and a command that could be different
> depending what came before it.
>
> So this sounds like manual and 'continuous' (MDI and AUTO being continuous)
>
> Even if we actually did need the three modes, I think we should
> put some thought into some of the commands that require MDI but
> are regularly used in manual such as the three I mentioned.
>
> Thoughts?
>
> Chris M
>
>
> ------------------------------------------------------------------------------
> 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
