Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75
Hi Jürgen, I guess you really understood my writings. On Sonntag, 19. April 2020, 08:03:30 CEST Juergen Gnoss wrote: > 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. Right. > 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. Exactly > If motion asks for the next block, ... Well, motion should not ask for anything. It should work out what is in the motion queue. If the task-manager works in single-step mode, than it puts only a single move into motions queue. Motion executes that and as the queue is empty it waits for next entry. So task-manager knows the sequence of motions and machinecommands and how they interact or how they are related. Motion does not need to know about machine commands (like flood, mist or spindle commands) > 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. Well, best would be, first discuss the desired system design. Code is all there, it needs to be reorganized/moved. May be, that's a chance to rewrite ugly/obfuscated code. Reinhard ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75
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