In regards to motion stopping during the "unexpected real time delay" popup - It doesn't. I can test this really easy with my laptop. My laptop has a intel chipset that has issues with rtai. http://www.captain.at/rtai-smi-high-latency.php
The emc developers found this patch and We got my system working. The patch was rtai_smi.ko. I can do a 'sudo rmmod rtai_smi.ko' during the running of emc - and within 64 seconds I get the popup. Now I did this while I was running the 3d-chips program I started it - sudo rmmod rtai_smi.ko then waited for the popup noting where the cutter was. The screen paused when the popup appeared. I let it stay there for a good while and then hit ok. - at that point the preview instantly showed that the program was half done instead of just starting. btw... I was not figuring that my laptop would be able to run emc2 realtime. One of the developer (jmkasunich) had a motherboard with the same chipset as mine with the same problem. He and alex_joni worked through making the kernel patch and testing that it worked. I asked for it to play with and low and behold it fixed my issues also. Been running 3d-chips for days now with no rt issues. They are working on integrating it into the next release. these guys are a great bunch - Thanks again. sam sam On Tue, 26 Dec 2006 20:17:20 +0100 Mario. <[EMAIL PROTECTED]> wrote: > 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 ------------------------------------------------------------------------- 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
