Running servos in position mode instead of analog
Actually, it's not uncommon to have delay issues when using drive generated feedback.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.
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
Please Log in or Create an account to join the conversation.
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.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.
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.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.
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 manualAnd 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.
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.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.
Please Log in or Create an account to join the conversation.
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:
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 DMMsi'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.
- tommylight
- Away
- Moderator
- Posts: 19219
- Thank you received: 6440
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.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 19219
- Thank you received: 6440
Jumping the gun a bit Blazini, he explicitly mentions "not the pulse train ones":OK, so you're refuting what dm17ry said? Like I wouldn't do that, not with Yaskawas or Mitsus
Apparently it does matter, but that would require much more testing and with a pool of devices.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.
Please Log in or Create an account to join the conversation.
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?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 concerned about specific drives, this whole DMM thing just needs a baseline for what to expect from other drives emulated encoder outputs.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
- smc.collins
- Offline
- Platinum Member
- Posts: 677
- Thank you received: 117
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.
Please Log in or Create an account to join the conversation.