Running servos in position mode instead of analog

Aciera wrote:

You have to ask yourself "why is no one else having the same issue running Linuxcnc and servos in closed loop". Maybe the issue is with DMM servos not being well built.
 
Actually, it's not uncommon to have delay issues when using drive generated feedback.
I had the same issue using  Mitsubishi MELSERVO J4 drives with step/dir.

There is a whole thread about that here:
forum.linuxcnc.org/10-advanced-configura...pain?start=30#193073

From that thread:

dm17ry wrote:

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...
 

Isn't dm17ry the guy who makes LinuxCNC controller cards for Yaskawa/Mitsubishi servos? He's also the guy with the infamous pick and place machine right? These guys are talking 5-10ms delay on the encoder outputs on much more expensive Mitsubishi servos so maybe we should lower our expectations a bit for DMMs

I have used older Yaskawa drives with proprietary encoders, encoder outputs from drive to Mesa 7i77, the response was instant, to the point that PID tuning took about 3 minutes.
That encoder feedback was generated on the drives at 2000 PPR while the encoders were 8092 PPR or thereabouts, no lag.
Most of the other drives i used are/were velocity with tacho, so encoders go to Mesa directly.

OK, so you're refuting what dm17ry said? Like I wouldn't do that, not with Yaskawas or Mitsus

the delay i was talking about is present in mitsubishi drives in position control mode. when i tested a MR-J3-A drive in speed control mode with my own YAO2 +-10V analog out and ABZ feedback - i had absolutely no problem using linuxcnc's PID. despite serial communication to YAO2, then SPI DAC on it, and then again ABZ encoder position transmitted back to linuxcnc via a serial link...

blazini36 wrote:

OK, so you're refuting what dm17ry said? Like I wouldn't do that, not with Yaskawas or Mitsus

Jumping the gun a bit Blazini, he explicitly mentions "not the pulse train ones":

dm17ry wrote:

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.

Apparently it does matter, but that would require much more testing and with a pool of devices.

dm17ry wrote:

the delay i was talking about is present in mitsubishi drives in position control mode. when i tested a MR-J3-A drive in speed control mode with my own YAO2 +-10V analog out and ABZ feedback - i had absolutely no problem using linuxcnc's PID. despite serial communication to YAO2, then SPI DAC on it, and then again ABZ encoder position transmitted back to linuxcnc via a serial link...
 

I'm not familiar with Mitsubishi drives, I've dealt with Yaskawa black box servopaks and Sigma V's but that was OEM/industrial use over serial because of their indexer. Do you have or can you get a measurement of the "lag" of the encoder output of whatever you have laying around?

I'm not concerned about specific drives, this whole DMM thing just needs a baseline for what to expect from other drives emulated encoder outputs.