Yaskawa servo options

SPH wrote: Just make sure you don't get Mechatrolink drives. They're essentially impossible to control.

that's not exactly true... actually, the protocol is mostly documented and was pretty straight-forward to implement. yaskawa sells custom ASICs and interface transformers for OEMs, but an FPGA and ethernet magnetics seems to be doing just fine.

control bus connection is dead simple with off-the-shelf USB-A/A cables. the protocol offers all the usual goodies like position/speed/torque feedback, absolute encoder support, drive parameters transfer, alarms/warnings codes report, torque limiting etc. without any additional wiring required.

yurtaev.com/ymtl2p.html

dm17ry wrote: that's not exactly true... actually, the protocol is mostly documented and was pretty straight-forward to implement.

Do you have any interest in adding your HAL driver to the LinuxCNC distribution?
We already include the drivers for many other hardware interfaces (Motenc, Servo-to-go, Pico, Mesa...)

i do. and i remember you even kindly offering help a few years ago...
yet, i'm still maintaining my own fork. i have two excuses for that:
1. me procrastinating on the task of cleaning the things up, documenting and fixing a couple of source tree integration issues. before i can propose a submission of my stuff.
2. i still handle absolute encoders (i.e. virtually every mitsubishi) in my own unorthodox way. nowhere a perfect solution, but somewhat less evil for me than the linuxcnc's method. need to discuss what to do with it...

dm17ry wrote: 2. i still handle absolute encoders (i.e. virtually every mitsubishi) in my own unorthodox way. nowhere a perfect solution, but somewhat less evil for me than the linuxcnc's method. need to discuss what to do with it...

When did you last look at how LinuxCNC handles absolute encoders?

If the driver reports absolute position, with the correct INI config, that should be all there is to it.

last december i believe, when i was merging in and patching 2.8.1 and master...

kinda off-topic, but.. we already talked about it a while ago. and i still don't like the fact that HOME_ABSOLUTE_ENCODER and all other homing settings are mutually-exclusive. i prefer having both simultaneously available without keeping multiple INIs or implementing homing to switches/index on my own...

the patch is trivial: all it does
- adds a new joint.N.set-homed pin to immediately set the "homed" state for a joint
- changes the contents saved to the position file on shutdown from a current joint position to a motor-offset. as it breaks compatibility i've added a new [JOINT_n] flag which is ugly...

Well, I think it would be simpler, at this point, to get our driver to work with LinuxCNC and the LinuxCNC way of doing absolute encoders.
I find it hard to believe that the two can be absolutely mutually incompatible.
The reason is that there are configs out there using the existing behaviour, and it seems best not to break them.

FWIW I actually quite like having to load a subtly different INI file to re-home my absolute encoders. It stops me doing it by accident.