Step/Dir servos + Encoders = follow errors... and so much pain.....

More
23 Dec 2020 21:07 #193022 by jhandel
So if I am understanding you correctly if I get something back on stepgen feedback that is a committment from the MESA card to have sent the pulses to the servo to do that thing..

So if we look at the following raw data from the scope of a movement
hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-fb -0.00680662536621 <-- No move
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.99995833333332	 hm2_7i76e.0.stepgen.00.position-fb -0.00680662536621 <-- Start command move
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.99962499999998	 hm2_7i76e.0.stepgen.00.position-fb -0.00677217102051 <-- StepGen has started the move
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.99858333333333	 hm2_7i76e.0.stepgen.00.position-fb -0.00648828125000
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.99658333333332	 hm2_7i76e.0.stepgen.00.position-fb -0.00556071472168
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.99358333333333	 hm2_7i76e.0.stepgen.00.position-fb -0.00367330932617
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.98958333333331	 hm2_7i76e.0.stepgen.00.position-fb -0.00051603698730
 hm2_7i76e.0.encoder.02.position -56.00000000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.98458333333332	 hm2_7i76e.0.stepgen.00.position-fb +0.00387779235840
 hm2_7i76e.0.encoder.02.position -55.99950000000000	 hm2_7i76e.0.stepgen.00.position-cmd -55.97858333333335	 hm2_7i76e.0.stepgen.00.position-fb +0.00952809143066 <-- Encoder has responded with movement

That its less than 1ms (one sample period) request to MESA card issuing pulses, but that it is an additional 5~6 samples (at 1ms each) for the encoder to respond that it is moving..

So I really are hunting for 4 to 5 ms between the MESA card and the servo... The issue could be in the issuance of the move command to the physical servo, or it could be in the read/process time for the encoder signal.. either way.. there is a lag somewhere in those settings..

Please Log in or Create an account to join the conversation.

More
23 Dec 2020 21:10 #193023 by PCW
Nope, its all in the servo drive/ mechanics

Please Log in or Create an account to join the conversation.

More
23 Dec 2020 21:19 #193028 by jhandel
The encoder is connected to the servo drive... so it is one black box from pulse in to encoder movement out.. If I had glass scales on here or something that would almost make this easier as, you are right, the delay would be just in the servo.. But because the Servo Driver is handling the encoder too.. I can't say that the lag is on the way to movement, or if the lag is after movement and on the way back to the MESA card.. its just somewhere between the two points..

Please Log in or Create an account to join the conversation.

More
23 Dec 2020 21:35 #193031 by PCW
I was thinking that you did have linear scales, as most people that
want encoder feedback on step/dir systems use linear scales.

If the encoder signal is from the drive, the drive may delay that also.
Unfortunately 6 (or more) ms of delay will make it almost untuneable
for closed loop operation

It still looks like the drive itself is not very well tuned. This will affect open loop
operation also. The error during accel and decell indicates that the drives
velocity loop has not been tuned to match the inertia of the load very well.

Are you using encoder feedback just for homing to index?

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 03:06 #193059 by jhandel
actually the servo does follow the intended movement really well when you set P to 0... Its just 6ms behind.. it does everything its asked to... just 6ms behind..



I am tempted to set P to 0 and then set the f-error and fmin-error so high that they will never trip.

the only thing this time delay may slow up is the touch probe and tool touch... but like both of those are 5 to 10ms slower too (even as physical switches) so I am inclined to just do all my actual probing super slow.. (slow enough that 25 or 30ms is less than .01mm) so yah I can work around that..

Still wierd.. I guess my servo driver just takes 6ms to start doing its work and there isn't anything settings wise I can do to shrink that..

And seriously I dug through every possible setting...
Attachments:

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 06:59 #193073 by dm17ry
i've been playing with several generations of mitsubishi/yaskawa position controlled servos. not actually a pulse train though, but sscnet/mechatrolink - but that shouldn't matter.
so, they all exhibit similar behavior. there's no way to eliminate this time lag completely with tuning without introducing serious overshoots. but to counteract it, those protocols have a provision to latch the motor encoder counter at encoder z-index or some external signal wired directly to the drive. when that happens the drive raises a flag and controller can read back the latched position. kinda like linuxcnc's index-request...

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 14:26 #193113 by PCW
Note that you cannot use a P of exactly 0 since you will have long term
position drift due to time base differences between LinuxCNC and the
hardware, jitter in position read and velocity write times, and quantization
of velocity setting.

It honestly looks like the drives should be run in open loop mode.

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 15:04 #193118 by jhandel
If closed loop means its pulling position from the encoder count, why would it drift over time, wouldn't it just take what ever the encoder has as the "gospal"? (not saying it wouldn't, just not following the logic exactly..

Either which way if I go open loop I'll need to see if I can reset the stepgen counters on encoder index either through basic HAL logic, Classic Ladder or as a raw C HAL component.. so I got some fiddling to do to figure that out..

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 15:14 - 24 Dec 2020 15:17 #193122 by PCW
If you have P=0 (and I,D =0) the encoders are ignored
FF1 = 1.0 just sets the stepgen velocity to LinuxCNCs
commanded velocity every servo thread.

Sort of like telling someone how to drive to a destination
by just telling him how fast and what direction to drive
every second. Without position feedback there will be
accumulated position error. This is basically "dead reckoning"

I will take a look at index handling for the stepgen
this has been in the firmware for years but there is no
current driver support.
Last edit: 24 Dec 2020 15:17 by PCW.

Please Log in or Create an account to join the conversation.

More
24 Dec 2020 15:26 #193124 by jhandel
would a P of virtually zero have the same effect? like P 1 or .01? just enough to have it be part of the equation..

"I will take a look at index handling for the stepgen
this has been in the firmware for years but there is no
current driver support." <-- are you saying the stepgen count and indexing processes are handled by the MESA card itself and not by Linuxcnc? or is firmware short hand for somewhere in the source of Linuxcnc that I should consider poking with a stick? (though I could also poke the MESA firmware with a stick too, mine is already customized)

(Thanks for all the help by the way.. and Happy Holidays/Merry Christmas!)

Please Log in or Create an account to join the conversation.

Time to create page: 0.191 seconds
Powered by Kunena Forum