On Monday 12 August 2013 11:34:12 Kirk Wallace did opine: > On 08/12/2013 05:51 AM, GP Orcullo wrote: > >> * 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. > > > > I have noticed this issue on RPi as well, the motors would slowdown > > or pause whenever the graphics load is too high. Axis is prone to > > this problem and is not easily reproduced. For mini, performing a > > refresh on a complex backplot or manipulating the zoom slider will > > trigger this problem. > > > > Note that I'm using the rtos-integration-preview3 version and there > > are no realtime errors whenever this happens. > > > > Cheers > > ... snip > > I haven't followed this thread very closely, but ... am I missing > something? I thought the whole idea behind a real-time system is to > provide and reserve enough resources for the real-time tasks to complete > them on-time. All other tasks get what's left over.
+1 (or more) > This has been my > experience in the past. When resources get sparse, the display gets > jumpy, but motion is not affected. If motion does get affected, you > don't have a real-time system. If motion gets affected and there are no > real-time errors, that seems worse. To me too. > I mention this because, from my perspective, there seems to be a > disconnect between the stated problem and the areas being looked at to > find the problem. The problem may be with my perspective? I don't think so Kirk, I see it from the same angle. That said, even with the latest 2.5.3, I see a realtime error advisory, but it may not show up until the next day of uptime for LCNC itself. And I have never detected that the machine itself, if in motion at the time, was ever affected. OTOH, the mill usually has, in addition to LCNC, a session of Konversation and of firefox, several konsole screens and a kcalc running on other windows. As to what triggers it, I have not been able to correlate it with anything going on such as switching workspaces or firing up a session of gedit to adjust some code for the next attempt. I'd be worried perhaps if it occurred within 2 or 3 seconds of starting a machining operation when LCNC itself had a 30 second uptime, but here its usually many hours later. Perhaps this advisory, rather than turning itself off after the first occurrence, could write its timestamp to a logfile, to be submitted or studied in an attempt to locate the source? If that could be done w/o triggering a storm of them that is. Or increment a "from LCNC startup" counter that could be interrogated later so as to get an idea of the magnitude of the problem if indeed there is one. 2 counters actually, number of occurrences, and the maximum error encountered in this uptime? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> Round Numbers are always false. -- Samuel Johnson A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ 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
