Re: [Emc-developers] rocking the boat...

[Ray H. <re...@up...>]

And one more.  Then I may shut up for a while.

ben lipkowitz wrote:

> First of all, can we all agree that NML is bad? 

Um. NO.

In a monolythic program, you can get away with just passing stuff 
between variables and processes but once you try to pipe stuff from one 
end of a multitasking unixy system to the other, some sort of formal 
communication structure needs to be implemented.

Simple things like one process asking another to do something and then 
checking to see that it was done.  I don't want to get pedantic with 
communication theory here but I thrashed you the other day on IRC about 
this and I'm waiting for an answer.  Take a very simple set of 
part-program commands (I know you think g-code is archaic but I'm not 
going to address that here)

1. We tell EMC we need an end mill
2. We tell the spindle we want 12k rpm.
3. We tell EMC we want it to go around the inside of a pocket
4. We tell the spindle we want 12k rpm.
5. We tell EMC the part is over there.
6. We tell the operator there is a problem.

How do we tell it.  How do we know that it's completed the first task so 
that we can start the second.  If Interp, Task, IO, and Motion are 
separate running processes we must create commands that have a single 
meaning at both ends.  In communication they call that semantics.  We 
also have to put those commands into orderly groups so that the 
receiving end can sort out actions and targets.  These command sets are 
like writing simple sentences.  We call this syntactics.  Now we want to 
allow the sender to find out if a command has been carried out so we 
need to build in some sort of feedback.  And last but not least, we want 
the sender to be able to tell everyone when to wait and under what 
conditions they should.  We also want to know any exceptions or errors.  
Since NML does all of this right now, I'm lost as to why you would want 
to create a whole other communication system that needs to do 
essentially the same things. 

We could throw out NML and buy into COM or another existing language but 
the integration of that language would mean touching nearly every file 
in the 1200 + system and then what have we got but the need to customize 
that language with the semantics, syntactics, and feedback that works 
for a machine tool.

We could throw out the whole notion of a unifying language.  We could 
hard code the stack between the interpreter, the task, the IO, and 
Motion but if we do that we have thrown out all of the flexibility that 
you speak of.  Try plugging Stewart or SCARA kinematics into that mess 
and see where you are.  How many softw

I'd a whole lot rather build a bit of flexibility into the existing than 
replace the whole damn thing.  Let's get down to a few specific things 
that NML won't let you do?

Ray