Yaskawa servo options

arvidb wrote: No, I cannot choose for him/her. But I can point to EtherCAT as a possibility so he/she can make an informed choice. That's why I also explained the cons in my post and pointed out reading the manual before taking this path.

Besides, with EtherCAT you don't need to know the difference between analog and step/dir. Steejans will have a lot of reading to do regardless of choice.

One thing that maybe I should have made more clear is that with EtherCAT, you will not find nearly as much help on the forums, since analog and step/dir is much more common. So again, read the manuals, forum etc and make sure that you're comfortable with taking that route before buying anything. That said, I had no knowledge of EtherCAT before, and managed to read up on it (using the Servo Drive manual and this forum) and get it working on my own, so it IS possible.

Is the ethercat realtime HAL driver up to date or did you roll your own?

I modified the existing Omron G5 driver in the linuxcnc-ethercat package to support my drive models (by simply adding the correct device ID:s). My modifications have since been accepted upstream so they are now in the package.

I have also experimented with running a drive in velocity mode using halrun, based on the generic EtherCAT driver from the same package. It worked well if I remember correctly.

Basically what's needed to run a drive with the generic driver is to write an EtherCAT description .xml file that tells the generic driver how to find the drive on the bus, how to configure it, what data to send and receive, and how to map the data to hal pins.

Edit: The specific drivers in the linuxcnc-ethercat package can be thought of as a convenience layer that lets you ignore things like specific device ID:s, PDO/SDO addresses, watchdog settings and such. The Omron G5 driver configures the servo drive for basic position control; if you want to do more advanced stuff (like feed-forward of velocity, or just run the drive in velocity mode) then you need to set it up using the generic driver.

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.

eerr... what do you mean? didn't get it. what's "our driver"?

and i don't break anything with my patch - without that ini option everything behaves the usual way.

the thing is i currently support 8 servo control protocols and i'm not really thrilled having 16 sample ini files and more are on the way...

i've been using absolute encoders with MR-J2S-B's on my home mill for 10 year now... when i turn on the machine linuxcnc always comes up already homed. so i don't have a habit to rehome it. though it won't bring a slightest problem if i do it by accident or intentionally...

dm17ry wrote: eerr... what do you mean? didn't get it. what's "our driver"?

Typo. Should have been "your driver".