On 02/10/2017 05:03 AM, Ingo Breßler wrote: > Hello, > I'm working on a specialized UI which computes appropriate G-Codes first > and passes them to LinuxCNC for execution finally. Using the MDI mode > worked quiet nice for the task, used v2.5.3 so far. > > With the recent v2.7.8 (and git master/HEAD), I noticed that the > remaining number of pending motions in EMC_TRAJ_STAT.queue is not > reduced anymore during the operation. When sending MDI commands, it > increases ok, but keeps the initial number of motions until it is > completely done. Unfortunately, this prevents progress tracking. > > Perhaps a different issue, but at the same time the IDs of subsequent > motions are not updated, but always == 0. They get reset to 0 in > emcmotCommandHandler(), for example just above the tpAddLine() call (it > is done 4x at other places as well). > > I'm not sure if this is desired behaviour, a bug or if I'm doing > something wrong, for example should I use something else than MDI mode > for the task? > > If it's a bug, I prepared a tiny quick fix which solves both issues for > me, but it might not be appropriate, incomplete and cause unintended > side-effects. Perhaps, someone with a thorough understanding of the > inner mechanism knows how to fix this properly. > > https://gist.github.com/ibressler/2693a5a225606121aef385420c984f7f > > Thanks for any hints!
Hi Ingo! That sounds like an interesting project. What you describe about the motion queue and the motion id definitely sounds like regression. There was a big change to the trajectory planner in 2.7. Can you test the final 2.6 release and see if that one is ok? I bet it is. This would help us focus our debugging effort. src/emc/motion and src/emc/tp are the Motion controller controller and the Trajectory Planner (which is part of Motion). Motion is quite far removed from the Interpreter, which is where MDI lives. The architecture diagram here tries to explain it: http://linuxcnc.org/docs/2.7/html/code/code-notes.html#_architecture_overview The block labeled "EMCMOT" is Motion, and the block labeled EMCTASK is Task, which includes the Interpreter. (Sorry about the scaling of that image, if it doesn't fit in your browser you can scroll left and right to see the sides...) It sounds like maybe you care about MDI queue depth rather than trajectory planner queue depth, if so look at Task and the queuedMDIcommands stat struct member. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
