On Sunday 13 June 2010, Slavko Kocjancic wrote:
>Gene Heskett pravi:
>> because the output process to tell you adds to the problem. So it is
>> occurring later even if not reported.
>>
>> Set your BASE_PERIOD for say 50us, and the servo loop time for at least
>> 10x that. Try this, and reduce the BASE_PERIOD 5u-secs at a time until
>> you can just barely note that the machine feels busy and keyboard
>> response loses its instant feel. Add the last 5u-secs back and leave it
>> there. This has worked well for me, on an old Athlon running at 1.6Ghz.
>
>My machine work happy with 20us and mouse doesn't stick. So I have 25us
>as safe. The motor's sound's good but in 30uS the some noise start
>appearing and goes worse till 45us when motors stall.
>
>> Longer BASE_PERIODs will have a noticeable effect on how the motors
>> sound at higher speeds because it limits the size of the speed step
>> available and you hear the motors stepping up and down like 2 or 3 key
>> gaps on the piano keyboard. The shorter BASE_PERIODs will make this
>> smoother, and because the motors can follow these smaller steps easier,
>> you can get higher speeds. I have also, at least on my little machine,
>> found that setting the accelerations to smaller values so you hear the
>> motors winding up and unwinding, also helps to achieve the higher
>> speeds. This, like everything else has trade offs because the smaller
>> motions never get to a very high speed.
>>
>> Your broken bit because Z didn't retract was probably caused by the
>> combination of a too high acceleration setting, combined with MAX_VEL
>> also being too high, and when one of those latencies hit, the motor went
>> out of sync & stopped, and the next pulses after the latency hit were
>> too fast for the motor of follow from a dead stop.
>
>I don't know why. The machine worked without problems. Just got that
>single 'hickup' once in aprox half of year.
>That's the reason why I ask for latency error message. Is that apear if
>latency is longer than base thread or what.
>I assume that acceleration is ok as work now without problem. I think
>the error can be some EMI interference
>or just one bad jitter on computer. So the question is is EMC capable to
>say that jitter is longer than base period?
>
>> So the first thing is to find out where the latency is. Personally, the
>> least interfering video driver (which causes 75% of these problems, and
>> poor APIC hardware is often found) turned out to be the vesa driver.
>> The nvidia driver was by far the worst, the nv driver was better, and
>> the vesa driver was hand downs the best. YMMV of course. I haven't
>> ever had an ATI card in that machine, just a series of nvidia cards,
>> which have a limited lifetime, those with fans only last as long at the
>> $0.65 fan they use on them.
>>
>> APIC related problems are best treated with a different motherboard.
>>
>> Somewhere in all the above rambling might be something helpful. I hope
>> so at any rate.
>>
>>
>> The latency error is only reported once, the first time it happens,
>> mainly
>
>How to change driver?!? I had what is on live CD and works.
>
>Slavko.
That driver its using will generally be reported in /var/log/xorg.0.log, so
look there, trying to see as it weeds out the choices. (It will not
generally show up in an lsmod report) You may have to play with
/etc/X11/xorg.conf, adding a stanza (if its missing), specifying it is to
use the vesa driver. My machine is shut down ATM, or I'd suck my xorg.conf
in and post it, perhaps someone else has access to theirs?
This machine has an ATI card in it.
========================
Section "Device"
Identifier "device1"
VendorName "ATI Technologies Inc"
BoardName "ATI Radeon HD 2000 and later (radeon/fglrx)"
Driver "ati" <---------change this, check the rest against man page
Option "DPMS"
Option "AccelMethod" "EXA"
EndSection
Section "Screen"
Identifier "screen1"
Device "device1"
Monitor "monitor1"
EndSection
==========================
Which shows how the driver is specified (Device) , and how its linked
(Screen).
The vesa drivers maximum resolution is 1024x768 IIRC, but I believe the
figures you get from latency.test will be much better.
The problem is that most of the other video drivers get their (perceived)
better performance by locking out the IRQ's so they be be serviced quicker.
And its this IRQ lockout that gives the large jitter & latency figures.
This is one case where one will have to throw away a small hit on video
performance to make the motors perform right.
Servo systems can normally tolerate such shenanigans whereas steppers need
that steadier heartbeat. But servo systems also run the cost up. Within
the stepper drivers limits (I use xylotex drivers), steppers can do an
excellent job.
>--------------------------------------------------------------------------
>---- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>lucky parental unit. See the prize list and enter to win:
>http://p.sf.net/sfu/thinkgeek-promo
>_______________________________________________
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
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)
Q: How does a hacker fix a function which
doesn't work for all of the elements in its domain?
A: He changes the domain.
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
