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. 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? * 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. * Also, could someone on a traditional x86 system try this test? I suspect it will work OK, but it would still be interesting to know if the problem shows up or not. -- Charles Steinkuehler [email protected]
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
