Running servos in position mode instead of analog

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

Michael wrote:

It's great he sent you a picture of a 1ms delay. But he told me the same thing. And when I asked why it's 5ms he could only point fingers at Linuxcnc but couldn't articulate any particular thing to look at that caused the delay.

 

You can't either because it's not "5ms". Using the HAL analog output command as your starting reference is not the right way to do that because nobody knows what voltage you have the drive set to respond to. At best the 3ms delay between encoders is valid.

Plenty of other setups use Linuxcnc and a 7i77 board but don't have this issue. I couldn't find a single example of someone using DMM with accurate encoder feedback. The only ones I found were using galil controllers and they used filters to remove the delays they were getting back from the encoder section. 

I use a DYN4 with encoder feedback and it's plenty accurate. I use a 5000k rpm motor on my spindle controlled with step/direction from a 7i76e, it rigid taps all day. Analog control shouldn't make a difference except what is calculated as the deadzone. The analog command doesn't have an effect until the voltage is above/below the deadzone which is why you can't use the first blip of your HAL analog output command as a reference. If there was no deadzone you wouldn't be able to stop the motor but nothing about that is unique to DMM.

And regardless of using a scope or not the servos would over current fault attempting to catch up to their commanded speed .I could never get them to run full speed in velocity mode with a closed loop.

Again sounds like you didn't tune the deadzone out of your PID. I'm assuming that because A, that's exactly what would happen as the drive just reached the Analog input threshold and B you never mentioned the deadzone then you posted the halscope image and the only way you come up with 5ms from looking at that is if you don't account for the deadzone at all. The size of the deadzone is dependant on other parameters set in the drive, it's on P78 of the manual

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. 

Well built compared to what? Are you expecting a $250 servo drive to be as good as a $1k drive? If the "issue" is the "delay" then we gotta figure out what the actual delay is and if it's unreasonable. I have a DYN4 setup on a motor stand coupled with an encoder so I can test this. I didn't feel like setting up a Windows VM last night to re-configure the drive but I'll do that at some point today maybe. Like I said, I would expect a "delay" on the encoder output because of the nature of how it's generated. 3ms seems excessive, 1ms is probably fine but realistically it has to be compared with other drives doing the same thing.
 

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

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

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.

blazini36 wrote:

Do you have or can you get a measurement of the "lag" of the encoder output of whatever you have laying around?

yes, i can do it. i can couple a ABZ encoder directly to a motor and plot positions i get from the encoder and the drive. give me a few days to make a rig and i'll report back

the Sihong kb kr ka servo drives are similar " I bet all these drives share 90% of the firmware and board design. Anyway, in the Sihong drives p00.06 is the " command integration time" and this effect the response time of the servo drive to velocity commands.

www.dmm-tech.com/Files/DYN4MS-ZM7-A10A.pdf

top of page 38 is accel rate
Acceleration / Deceleration Soft Start
In Speed Servo Mode, the Max Acceleration parameter in the servo drive can be used to soft start/stop the
servo motor. If the analog speed command is sent as a step reference, it is often desirable to ramp up/
down this command to smooth motor motion. Without soft start, the servo motor can accelerate/decelerate
instantaneously. Soft start creates a smooth s-curve motion with conistent acceleration/deceleration.
The relation to physical acceleration / deceleration time is measured as the rise time from 10% of the target speed to 90% of the target speed.
Rise from 10% to 90% time = 59.98/(Max Acceleration)
2 seconds
Physical acceleration time = 1.2 * 59.98/(Max Acceleration)2 seconds

page 43

integration gain
max accel
max speed

if I am a betting main, the integration gain is the 5ms delay you are experiencing. try lowering it, and see what happens, the Sihong servos have a defualt of 50, which is 5msec.