Servo Purchase Recommendations, Yaskawa?

Once the mechanical issues were fixed the problems went away for me.  (Sent the worn ballscrews out to get rebuilt on 2 machines, replaced bad bearings in the rack and pinion drivetrain on two others.)

I've never experienced these kind of problems on any of the Linuxcnc machines I've worked with.  The above machines with the mechanical issues are all Fanuc controlled machines that worked well when new, but developed vibration issues as things wore out.  I've set up two servo driven machines with Linuxcnc (besides several stepper motor ones.)  One is running analog command signals using torque mode (those servos didn't support velocity commands), the other is using step/dir commands with encoder feedback and the position loop closed in Linuxcnc (behaves more like an ordinary velocity command servo.)

Maybe you should try setting up a dial indicator as you would to measure backlash, then push on the table either by hand or with a pry-bar or something, and compare the deflection measurement of the dial indicator with that measured by the encoder in Linuxcnc.  I'm sure this was all gone over in your tuning thread, but have you tried checking if there are any filter settings in the drive that should be turned off or adjusted?  Have you tried changing your drives to torque commands?  Some people have better results with that, when their drives are giving them delay issues with velocity commands similar to what you're seeing.  Have you checked to make sure the motors move at a constant velocity when a constant voltage is commanded and with a linear response? (ie Does a 0.5v command move half as fast as a 1.0v command?)

I've never tuned Yaskawa servos, myself but I do have a machine running them that I'm considering a Linuxcnc retrofit on. (The old control hasn't quite made me mad enough yet.)

so, basically, you haven't used linuxcnc analogue velocity control.
could have cleared that up first.

Yes and no, To Linuxcnc my step/dir system looks and behaves the same as an analog set up. Linuxcnc is still sending the exact same velocity commands to the Mesa card in exactly the same way as in an analog system. The only difference is in the Mesa card, it uses those velocity signals to create step/dir pulses instead of analog voltages, when the PID tuning is not correct it over or under shoots and will oscillate exactly the same as an analog system. The only difference is that I have to tune the position loops in both the servo drive and Linuxcnc. I was having a great deal of difficulty getting a good tune of the step/dir servos before adding the encoder feedback to Linuxcnc. Adding the encoder feedback and closing the position loop in Linuxcnc gave me 3 things, 1st it let me use Halscope for tuning (vs an ancient analog scope that barely worked) for tuning the servo drive, 2nd let me tune the drive's position loop a little softer for smoother motion and 3rd let me take better advantage of the feed-forwards in Linuxcnc's pid loop.

And for my torque command machine, I am using double pid loops, with the first sending what would be the analog velocity command to the 2nd that creates the analog torque command to the drive. It is PC(Linuxcnc => position PID => velocity PID) => Servo(motor), instead of the usual PC(Linuxcnc => position PID) => Servo(velocity PID => motor) I simply moved the velocity loop from the drive to the PC software, the main disadvantage being limited by the base thread speed where if the velocity loop is in the drive it is usually either analog and not subject to thread speed limitations or if digital running much much faster than is possible in Linuxcnc's thread system.

So Yes I'm using Linuxcnc's velocity commands, but no I'm not explicitly sending an "analog velocity command" to a drive.

interesting on the pulse with encoder feedback. not a common scenario. what servos and drives are you running?

im trying to find a common denominator here - and its NOT mechanical. we went through that in my thread over 40 pages of posts. when the same behavior exhibits at 0.1g acceleration and 1ipm and 700ipm and 1g, its not the 0.0003" backlash, or springiness (which is has none), or anything else, its strictly between the drive and the control.

its hard to recommend anyone else a system when there aren't any direct examples of it working.

i thought you were using torque mode. i remember going through the same loops with you in my thread, only to find out you weren't talking about the same thing i was doing...

Both machines are older Teknic SST Servos. The ones stepping are SST-1500-ACX, and only accept step/dir inputs. The machine originally was setup software stepping using an old DOS PC running Microsystems of Buckannon software (Company eventually became WinCNC.) I eventually converted it to Linuxcnc still software stepping. I was never happy with the servo tune or performance (with either system) and eventually added a Mesa 5i25/7i85S combo to add hardware stepping and encoder feedback, to try to improve the servo tuning. It did make tuning easier but the performance improvement was never seen mostly due to issues of compliance in the drivetrain and general bad design/poor engineering of the machine (what it really needs is about double the gear reduction and stiffer drive train.)

The other machine has Teknic SST-3000-UCX drives Because of the tuning issues I was having at the time with the step/dir servos on the other machine (this was before I added the hardware stepping and encoder feedback) I really wanted to try an analog system. Unfortunately I ordered the wrong drive version and the UCX version only did step/dir or analog torque commands. (I should have ordered the VCX version.) The online documentation I was looking at lead me to believe that the UCX one could have also done velocity commands but I was wrong. The drives came in TCX, RCX, UCX, VCX, and YCX versions and their descriptions seemed very ambiguous and incomplete to me. I've digressed.

My main point here is if there was any problem with delays inherent to Linuxcnc or the Mesa analog 5i25/7i77 system I'm using, my torque command machine set up would not be usable at all. (A torque command system is much more response time sensitive than a velocity commanded one.)

interesting