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

More
5 years 10 months ago #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
Code:
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
5 years 10 months ago #193023 by PCW
Nope, its all in the servo drive/ mechanics

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

More
5 years 10 months ago #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
5 years 10 months ago #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
5 years 10 months ago #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...

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

More
5 years 10 months ago #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.

Time to create page: 0.268 seconds
Powered by Kunena Forum