Am 11.08.2013 um 15:19 schrieb Charles Steinkuehler <[email protected]>:
> On 8/5/2013 11:29 AM, Charles Steinkuehler wrote: >> How does LinuxCNC behave under heavy CPU load? >> >> I am experiencing some errors in my 3D prints that look very much like >> part of the gcode got lost or skipped over* (I'll try to post pics or a >> video). This is happening a few times in multi-hour prints, so I >> haven't yet actually _seen_ this happen, I just see the results in the >> final print. >> >> I have not gotten any real-time errors or warnings, so I don't think >> it's anything at the HAL level or below, but on the BeagleBone, the CPU >> usage easily hits 100%, and the SD-card "hard disk" is also pretty slow >> (note that I am printing gcode files in the 2 MB to 10 MB size range, >> with lots of small line segments). > > I am revisiting this issue after experimenting with some alternate user > interfaces and a discussion with David Bagby. > > David indicated he would repeatedly run a familiar gcode program on his > shapoko and it would sometimes just "sound wrong". I have also tested a > variety of interfaces and noticed that if I am running a program in the > mini interface and I enable the "backplot" display, it causes the > steppers to dramatically slow down and/or stutter, and change from their > 'singing' tones to more of a 'grinding' type noise while the backplot is > initially loading. > > I'm pretty sure the problem isn't in the hard real time xenomai HAL > thread. If the PRU code is running and the xenomai task is blocked or > halted the steppers would just keep going at their current speed, likely > resulting in a following error once the ARM core 'catches up'. The fact > that the motors are 'stuttering' as they slave to the commanded position > indicates to me that the HAL servo thread is running properly but the > planned motion points are not being properly updated. > > I am also fairly certain the motion queue is being kept full by the > user-mode code. In particular, the issue can happen in the middle of a > long G1 move, so the queue shouldn't be a factor. if this is a fact so, I think everything 'above' the motion.control thread function can be excluded, because control would be chewing on a line segment which was tpAddLine()'d in the upper command handler well before, so I think it wouldnt matter much at this point what the upper layers are doing because the lower layer ignores them until done anyway. 1. maybe you'd be able to halscope the behavior 2. generate a trace of timestamps and commanded positions by halsampler, hoping that will catch it 3. bigger hammer: devise a filter on variance of the commanded position and output time stamp as they are output to the pins, and plot those (It'd be great to have hal rings available at this point already for a really fast trace buffer, but thats still a few weeks away). the "backplot" hint sounds suspicious. Is there some OpenGL-related code, or feeding of rendering hardware in the kernel which might be less-than-brightly coded? maybe the bug can be observed in latency spikes with glxgears too? > > Questions: > ========== > * What exists between the motion queue and the HAL servo thread that > could potentially be blocked under high load conditions? AFAIK, > everything from the motion queue down to HAL is supposed to be hard real > time, right? the command handler, which dequeues from the task/motion queue is in the motion RT comp, although that wouldnt be required AFAICT. The control handler definitely is, and that's where I'd look. > > * Can anyone else running a BeagleBone system try using the mini GUI and > enabling the backplot while a program is running? I'd like to know I'm > not the only one seeing this issue. can I do that with no steppers connected (how would I hear the bug ;-?) -m ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
