On Friday 20 October 2017 04:55:01 andy pugh wrote:
> On 20 October 2017 at 02:43, Gene Heskett <ghesk...@shentel.net> wrote:
> > Got that done, hooked it up and fixed the network (damned udev) and
> > then ran the mills config. Exact same problem. That leaves me with
> > a stack of bad 5i25's, or a config problem, but I have spent my time
> > the last 3 days disabling one or more functions at a time until I
> > was clear down to nothing but the 3 axises. w/o effecting the
> > problem.
>
> You could try going even simpler. Test at the command-line
>
> loadrt hostmot2
> loadrt hm2_pci
> setp hm2_5i25.0.stepgen.00.position-scale 1000
> setp hm2_5i25.0.stepgen.01.position-scale 1000
> setp hm2_5i25.0.stepgen.02.position-scale 1000
> loadrt threads
> addf hm2_5i25.0.read thread1
> addf hm2_5i25.0.write thread1
> start
>
> setp hm2_5i25.0.stepgen.00.enable 1
> {might need to setp a GPIO for enable here too)
> setp hm2_5i25.0.stepgen.01.position-cmd 0.5
>
> (and so on)
Before I spend any great time doing that, I need to put a fan in the
psu, its running warm. Or go move a cable and check it on the other
smaller, somewhat slower machine that also is exhibiting the problem.
First of course is do something about my caffiene/blood ratio, I'm about
a quart low this time of the morning, 07:35.
This seems to be a problem, according to my poking around with halmeters
and the halscope, of a PID problem. The pi-3b is running that 11x36
sheldon lathe without any PID's. PID's, it seems to me, are mainly for
servo's, and the only real "servo" in this machine is the spindle.
So I may cobble up a 3rd config that drives the steppers using the same
hal hookups the pi is using. This way the joint co-ordination isn't subject
to the rubber band effect in the pid's.
example for Z from the pi's hm2-7i90-stepper.hal:
# Z position command and feedback
net emcmot.01.pos-cmd <= joint.1.motor-pos-cmd
net emcmot.01.pos-cmd => hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-cmd
net motor.01.pos-fb <= hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-fb
net motor.01.pos-fb => joint.1.motor-pos-fb Z-axis-track.in
# axis enable chain
newsig emcmot.01.enable bit
net emcmot.01.enable <= joint.1.amp-enable-out
net emcmot.01.enable => hm2_[HOSTMOT2](BOARD).0.stepgen.00.enable
And the pi runs it great. With the vfd, I don't even have the pos-fb path
hooked up, and the rigid threading is all slaved to the spindle encoders
output.
The extra Z-axis-track.in is part of the overshoot tracker, which on the
lathe with its vfd spindle drive and a heavy chuck, takes much longer to
effect the end of a g33.1's reversal, so I needed a way to quantify how
much overshoot there is. So practically, I can't run a g33.1 at more than
200 rpms unless the hole is drilled thru. So now I can run it cutting air,
watch the overshoot with a halmeter, convert it to distance and subtract
that from the #<_z_depth> value fed to g33.1. No more broken taps from
hitting the bottom of the hole. (if I don't forget...).
The newsig might not even be needed since the net command creates it anyway.
I think thats a leftover from the example I started with.
Now, first things first, coffee.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
