Am 09.12.2013 um 20:20 schrieb Robert Ellenberg <[email protected]>: > Hi All, > > During testing of circular arc blends, Sam and I have noticed a peculiar > crash in the trajectory planner on RT builds. What seems to happen is that > the velocity of the current segment suddenly jumps to a huge negative > value, despite the many checks in the code against unsafe velocities. To > help debug this, I have a few questions about how the servo loop runs in > the context of motion and the rest of linuxcnc: > > 1. Does any other part of the code besides the TP have write access to > the motion queue? I don't see any, but I could be missing something. Not that I know of.
The flow is: segment comes in as linear or circular move (EMCMOT_SET_LINE, EMCMOT_SET_CIRCLE) from task (emc/task/taskintf.cc) the motion-command-handler thread function writes to the motion queue via tpAddLine() and tpAddCircle the motion-controller thread actually works on that queue those two functions are assumed to execute in sequence > 2. What happens if emcmotController runs too long? Is there a > higher-priority thread that can interrupt it? this depends a bit on the thread flavor being used but the general flow of an rt thread is: while true do: run through list of thread functions, recording times wait for end of thread period *) (this is the gist of the thread_task() function in hal/hal_lib.c). *) in case of a thread function running too long, in the RTAI case this wait function - rt_task_wait_period() - will return RTE_TMROVRN, indicating that the the function returned immediately because the release point for the next cycle was already missed. This condition should cause the - somewhat imprecise - dmesg entry "RTAPI: ERROR: Unexpected realtime delay on task %d\n" "This Message will only display once per session.\n" "Run the Latency Test and resolve before continuing.\n", from here: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/rtapi/rtai_rtapi.c;h=d647d080db96db7b4d3d1de116a9e04570d6ca9a;hb=d4d4b07fb3a95459c5e41069825a5036e127586a#l835 you might want to look in halcmd at the motion-command-handler.time motion-command-handler.tmax motion-controller.time motion-controller.tmax values; this could give a hint if something takes too much time. In unified-build-candidate-3 you have much more fine grained control over what happens on "realtime delays" of various forms and shapes, and may redirect action to a user-defined HAL component (example: rtfault.comp), for instance cause an estop, print a message, or handle the condition in a more intelligent way altogether. > 3. I'm occasionally seeing a "tcqPut Failed" error on simulation runs. > My understanding was that the queue margin was implemented to fix a race > condition, and shrinking this margin makes this more frequent. What is the > sequence of events that causes a new segment to be added to the queue? > Would this be affected if the kernel processes were hogging CPU time? I would suggest tying the motion queue free space to a HAL pin so you can scope it; the usage and out of space condition should show, also in relation to other variables -m > > The other cause of a huge jump that i can think of is a divide-by-zero or > use of uninitialized data, but this would seem to be an algorithmic issue, > which would show up in the simulator as well. Since I'm only seeing this > problem on RT builds, this seems less likely to me. > > Thanks! > Rob > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
