So, if it is a warning, not an disaster-meaning message, why does it put the machine to a halt without decelerating down? It could at least slow down and say: your machining has been paused... Steppers with large inertia may lose step. I think it is time to program in some predefined shutdown management. Different shutdown behavior for different causes.. If we implemented restart schemes, one could easily do EDM machining with regulations and protection.
I run it with: Menu Applications/CNC/EMC2 So, the whole problem is "artificially fabricated"? Just that the interface is overreacting that one period is 10% shorter than a period that follows it 5 miliseconds after that? The message said it is an error, not a warning... and it causes a halt of the machine run. I found an USB key, so here goes the data: test script: #!/bin/sh sudo mkdir /dev/rtf; sudo mknod /dev/rtf/3 c 150 3; sudo mknod /dev/rtf3 c 150 3; cd /usr/realtime*/testsuite/kern/latency; ./run RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns RTD| -1903| -2021| -796| 12479| 13733| 0 And I include rest of the error log files here: http://kotuha.com/file/116716058850.html On 12/26/06, Alex Joni <[EMAIL PROTECTED]> wrote: > Hi Mario, > > thanks for the detailed report. I'll be waiting for the exact > messages. > But until them some clarifications: > > > So, what the problem was: > > > > 1) I made a new computer and a fresh install Ubuntu 6.06LTS, > > +EMC2.0.5, +axis > > I assume you used the debian packages. How do you run emc? (var1: from > the menu, var2: open terminal, go to a dir, issue: scripts/emc) ? > > > 2) The Geforce 6100 VGA was installed as vesa in xorg.conf > > 3) When I changed the VGA to GeForce 7300 GT, all problems/features > > remained exactly the same. > > 4) Meanwhile... I made 2 new setup configurations (canon.ini), all > > went OK > > 5) I discovered a bug: when trying to move the slider of Feed > > Override > > to even 105%, I got message "Unexpected realtime delays, check dmesg > > for...." Tried tkemc and axis - same results. > > The unexpected realtime delay works like this for emc2.0.5: > > I). it records 5 of the last runs of the motion controller > II). it looks if the current time to run the motion controller exceeds > any previous run by more than 10% > III). if more than 10% is seen, it triggers that error. > > So in your case the motion controller should run at exactly 1msec, and > the difference which you showed (much more clearly in the logs you'll > hopefully send us soon) of "0.957ms, 1ms, 1ms, 1ms, 1ms and last one > 1.053ms" is the explanation for the unexpected realtime delay. If you > check the difference between 0.957ms and 1.053ms you'll see it's > exactly 10%. > > The 10% have been chosen quite arbitrarly, it could be that in your > case it's only a bogus error message. > Does anything else noticeable happen? Motors failing? do you hear a > certain bang in the sound from the motors? > > > 6) dmesg said that there were numerous delays of about > > (recalculated) > > 1 milisecond > > 7) I changed processor frequency up/down - the delay and bug > > remained > > the same - 1 milisecond... > > > > 8) When changed the video driver to "nv" for magma core, deleted > > many > > useless input devices in xorg.conf, the bug is much, much harder to > > cause. Two minutes playing with the slider and system loaded to 100% > > by other applications. > > > > I suspect that the bug *could* be caused by issuing too many feed > > override commands in short time. > > If I made the above clear (not that sure I did), you'll understand > it's not a bug. Merely a Safety feature, that tells you something took > a bit longer to work than it should. > > > > Will try this... Chenge servo period to some long time... > > I suspect that if you increase the servo base period, you won't notice > the anomaly anymore (10% in 2msec is a lot more than in 1msec). > On the other hand, I'm not sure that's such a good idea. It all > depends what else is failing (if anything). > > Older versions of emc2 (before 2.0.4) had no idea how to tell if there > was a "Unexpected realtime delay", so you would have just worked along > without knowing any of this, and it probably would have worked OK. > > Regards, > Alex Joni > > > > > On 12/26/06, Alex Joni <[EMAIL PROTECTED]> wrote: > >> > >> > >> Hello Mario, > >> > >> I still don't think I understand your problem. > >> I've been reading through all your emails (at least the ones I > >> have), and it seems like one email at least got lost. > >> There is no email describing what the actual problem is. Sure you > >> talk about 1ms something.. but it's not clear at all what the > >> problem is. > >> > >> Regarding the 1msec, I see you have the SERVO_PERIOD set to > >> 1000000 nsec = 1msec > >> So any change you send to the motion controller would happen at > >> 1msec (including the feed override changes). > >> > >> Maybe try again (from the beginning, and with assuming we know > >> nothing) to explain what exactly the problem is, and what you are > >> doing to show it. > >> > >> Regards, > >> Alex > >> > >> PS: when you move the slider (either AXIS or tkemx, or any other > >> GUI), a NML message gets composed then sent to task (emctask), this > >> one queues it, and when it's ok it send it to the motion > >> controller, which sets the new value by calling a TP specific > >> function. > >> The other way (display of the current feed override) happens by > >> means of the status structure, and later on with a NML status > >> message. > >> There is _absolutely no way_ the moving of the slider per se to > >> cause the glitch (if that's what your problem is). What can be, > >> and I am not ruling it out, is a problem when applying the new > >> feed_override in TP, maybe some accel which is too high, and > >> causes motors to stall (if your setting of 450 mm/s^2 is not > >> appropriate). I also notice you have some BACKLASH configure in > >> there, might want to take that out during testing (to rule out > >> every possible cause of problems). > >> > >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
