Hi, > Maybe I am misunderstanding the question, but take the example > > N1 F100 > N2 G1 X0 > > During the G1 move motion.current-line will show 2 > ... > And, in execution time, they take literally no time to execute, as > their effects are rolled up in to the motion commands.
Asking for execution time is the wrong question. There are 2 major criteria, that distinct professional cnc-controllers from the rest of the world (at least in my way of thinking): 1.) (re-)acting on feed overwrite without delay 2.) support single step execution To support single step execution its evident, that UI shows the right line to be executed next. On my pretty outdated mill at work, even an empty line will pause execution. ... and to close conclusion: if cnc-controller is separated in background and foreground tasks (like lc), synchronization of both is a big issue. Currently the only way to synchronize UI with motion or better said "gcode executor" is current line from status. At work I work on the smallest machine from company. We have 4- and 5-axis mills, lathe and lathe with multiaxis milling heads ... But there is no machine, that runs gcode without singlestep execution on first run. > I think that emcmot (== motion) is part of task. Yes, video and handouts from machinekit hit the same direction. I wonder, why motion sets up nml-queues if it is part of the same process than task ... Communication between taskmanager and motion should not be public, should it? Anyway - if motion uses nml-queues different than taskmanager - could I connect to status channel like I already do with taskmanagers status queue? Motion uses functions from different abstraction layer to open nml-queues. Does this mean, that the queues are different or do they follow nml-paradigm? Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
