On 8/11/2013 8:19 AM, Charles Steinkuehler wrote: > 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.
Video or it didn't happen: http://www.youtube.com/watch?v=cciYCMCfR3M It's a bit hard to hear/see in the video (it's better towards the end), but I verified that the "hiccups" *ARE* happening in the middle of long single gcode command moves (I used the "splash.ngc" LinuxCNC logo, which is lots of long and slow lines and arcs). You can see and hear the stepper motors stuttering in the video. I'm not sure yet what's causing the problem, but I don't think it's at the HAL servo thread or below. As mentioned, if I just killed the HAL servo thread, the PRU would keep the motors happily cruising along at their last commanded speed. So something in the trajectory planner or ??? is actually commanding the servos to do this glitchy hiccup thing, the question is how does that happen? UPDATE: I captured a hal-scope image of the commanded X and Y positions, along with the corresponding HAL position feedback from the PRU step/dir generators: https://picasaweb.google.com/lh/photo/Sb3VkD8vG3lBz15uFTMWztMTjNZETYmyPJy0liipFm0?feat=directlink The ramp for the two axis should be a straight line up to the plateau on the far right-hand side, instead there are two flat spots that occurred when I enabled the backplot display in the mini gui. It clearly shows motion stopping for 100+ mS and then starting back up again. I'm not yet 100% positive the entire real-time thread isn't stalling for that long, but I _really_ don't think that's the problem. I'll have to drag out a real oscilloscope / logic analyzer and verify the xenomai HAL thread timings, but I don't see how the system could behave this way if the 1 mS servo thread was seeing gigantic latency spikes like this (more than 100x the typical value!). I also know it is virtually impossible to get the xenomai thread latency over about 70 uS even with huge system load (including lots of network and disk I/O...via the "dohell" xenomai test script). This may turn out to be a BeagleBone specific issue, but I'll be somewhat surprised if it's not a bit more fundamental, related either to running on the ARM architecture, a bug in the new real-time code, or perhaps even a bug in LinuxCNC that only manifests itself on a very underpowered system (by today's standards) like the 'Bone. Note that even with the backplot turned on, the CPU usage shows about 25-35% idle, it's just the initial load that seems to put a large stress on the system and cause the problem. -- 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
