Request for testing: Can someone with a "traditional" x86 system test master and one of the RTOS integration previews to see if you can reproduce this problem on x86 with RTAI?
More details inline... On 8/12/2013 11:56 AM, John Kasunich wrote: > > On Mon, Aug 12, 2013, at 12:09 PM, Charles Steinkuehler wrote: >> On 8/12/2013 10:48 AM, John Kasunich wrote: >>> >> Whatever the actual cause, this sure seems like a problem that needs fixing. >> >> I'll post more details once I've dug out the logic analyzer and captured >> some real-world data. >> >> -- > > You might also get some useful data with hal-scope. Connect a ddt > block to the commanded position coming out of motion, and scope the > output of that. If you are only using one channel, I think the default > halscope buffer is 16K samples - that is 16 seconds at the default > servo rate. I created an oscillator using a NOT gate with direct feedback and routed the output to a free physical I/O pin. This has verified that HAL is running as expected with no glitches or real-time errors. I have also verified that turning on the backplot display in the mini gui results in a commanded stop of motion, even showing a (very) small bit of acceleration on entry and exit from the 'paused' state. Note my acceleration is currently set to 3600 mm/s/s, so I wouldn't expect to see much at the rates splash.ngc is running. :) There are typically two pauses for each enable of the backplot display, usually around 120 mS or so in length (the last two I measured were 112 mS and 127 mS). So, there is absolutely something between the motion queue with the "draw a line" commands and the HAL axis output of the trajectory planner (which feeds the PRU step/dir generation) that is gumming up the works. The question remains exactly what and which flavors of LinuxCNC it affects. QUESTION: Has anyone running a "traditional" RTAI system recently tried to abuse the system to verify there are no latent real-time problems? Running something like the xenomai "dohell" testsuite script will generally flush out any problems. I'd be very interested to know if this is a general LinuxCNC issue or if it's specific to the ARM ports. Note that in all of this, I never get a "Real time error" message, and the HAL hard-real-time code functions completely as expected. It looks like the commanded motion just stops for some as-yet unknown reason. -- Charles Steinkuehler char...@steinkuehler.net
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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
