I think what the interpreter is actually doing is a result of different interpretation of the term "interpreter" There is a difference in interpreting g-code or user commands/inputs, even further in the sense of g-code, where does the g-code actual come from? A file or MDI.
I think I'm not the only one that's missing some hairs on the forehead already finding an intelligent solution for that. Here a really loose and initial idea (just brainstorming) As Reinhard mentioned, glue logic goes into the task-manager, that should be kind of a server. Lot's of different modules get loaded based on configuration. That modules register their functions they provide on the server. The server decides what function from what module should be called in order to get the desired result. So if there is a module ATC, it has to know what IO's have to be managed in order to do it's job, same on manual tool change. Both modules are mutual exclusive and provide functions like Prepare_Tool(X) Change_Tool() After Tool change the task-manager calls Apply_Offsets() and whatever module provides that function has to do what's expected and has to know where and how to get it's information. If the motion queue is made of a few rolling buffers and does pull the content of that buffers from task-manager rather than get pushed into it, it's far more easy to keep track of the machine state. Task-manager splits motion commands into "motion blocks", caring for motion logic not for filled buffers, and knows the order in what they should be executed. If motion asks for the next block, it gets transferred into the free buffer, if motion is done with one buffer it switches to the next and requests new data. So motion knows what buffer and what position in the buffer it is, and can return that if task-manager asks for that, task manager has to know what to do next. Sounds a lot of work, but that relativates to a lot of modules with a small amount of code each. So maintenance should profit from that as well. ju _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
