EtherCAT System Implementation of JMC Ethercat Servos

Also i got from JMC the Manuel and their product portolio for the Ethercat moduls, I would attach them here, but the problem is the files are too big.

if the nema 23 worked before then the 180w servo should work too. personally find servos better too. They are more dynamic and easier to tune if you have good manuals. but tuning these jmc servos is not easy. rod is right it's going to be a long road with ethercat. I also only started with a laptop, one servo and the Mesa 7i76e on the table. and when that worked i bought more. a servo with a brake is recommended for the z-axis.

if you want to try ethercat then try one and see what works. but there are not many ethercat users here who can help. otherwise a Mesa 7i96s and step/dir servos would be good choices for this machine

@Smitherman

I'm a big fan of JMC for few years now; I was not aware that they finally did manage the EtherCAT implementation;
Those drives sound great, and at that price... Jesus.... and they are cia402 so they say;

For implementation of EtherCAT I'm going a different way all together using an industrial software-plc with a Linux Runtime that provides an EtherCAT Master besides other interfaces.
Please have a look here for use case:  look at minute 0:50

 
Best Regards
udoS

the JMC integrated servos are not very robust, I have seen more than a few failures, I would skip those and find a more robust motor setup else you may regret your decision when you have drive failures.

tok a few days to get the drive but here we go;



not so bad.

Good morning udoS!

would you mind sharing your configuration?

@Hi gueee78

thanks for your interest;
I'm using an industrial PLC with my own interface to tap into LinuxCNC;
In LinuxCNC my setup is gantry.mm sample. No changes at all;

For more information you can contact me by email:
uschlicher@t-online.de

Best Regards

udoS

If this helps anyone, I have successfully used a JMC JASD7502-20B-EC EtherCAT servo drive with LinuxCNC, if you use the generic driver the standard CiA402 registers will just work. However, I was not seeing the greatest performance with the self-reported velocity feedback, and similarly I was getting following error ripple that looked to me like a synchronization problem. Because of this I didn't bother tuning the system, I was just doing preliminary testing to make sure it was protocol compatible.

I am still trying to get a Yaskawa EtherCAT servo drive to work so that I have a Japanese quality reference to compare against. However their drives do not support combined read/write datagrams, the reads must be separated from the writes. This means the LinuxCNC driver needs to be tweaked a little bit unfortunately, and I am currently working on that...

The integrated EtherCAT edition of the JMC servo motors w/ integrated servo drives uses the same documentation PDF as their standalone EtherCAT servo drives. I have the EtherCAT PDF posted here:

www.cncwiki.org/index.php?title=JMC_JASD...es_Servo_Drives#PDFs

 I was not seeing the greatest performance with the self-reported velocity feedback, and similarly I was getting following error ripple that looked to me like a synchronization problem. 

Can you elaborate on that;

udoS
 

udoS wrote:

 I was not seeing the greatest performance with the [color=

Attached are screenshots of "halscope" in LinuxCNC showing the performance of a JMC vs Yaskawa EtherCAT drive in open loop velocity mode, and also of a JMC drive in closed-loop analog velocity mode and the Yaskawa EtherCAT in closed loop as well, and finally a Yaskawa analog drive in closed-loop for completeness. I did not have any screenshots of the analog drives in open loop, and I don't feel like hooking them up again right now

You can see that the JMC analog drive is a lot smoother than the EtherCAT one. I believe the EtherCAT edition drive isn't properly synchronizing the reading of the serial encoder to get consistently spaced positional readings, and the velocity is calculated off a simple position-delta per EtherCAT cycle rather than reporting the internal calculated velocity, which would be done at a higher sample rate with some better filtering. I speculate this because I've coded this stuff before, and run into the pitfalls...

The Yaskawa drive is on a whole different level of quality as you can see from the screenshots... The EtherCAT and analog drives perform similarly, and they both perform extremely well. The EtherCAT reported velocity feedback is rock solid.

Here is the text from the annotations in the screenshots (in case you need to search, translate, comment, etc.):

JMC JASD EtherCAT servo drive in open loop velocity mode
(this is why the white following error is so bad...)

Notice the noise in the teal EtherCAT reported velocity feedback, I am seeing a sawtooth wave noise component in the following error which indicates a sampling synchronization problem (like a bicycle wheel under a fluorescent light)

~~~

JMC JASD analog velocity servo drive in closed-loop velocity control mode (modulating velocity to keep positional tracking), and notice that the following error has no sawtooth component and the feedback velocity has low ripple too.

~~~

Yaskawa SGD7S EtherCAT servo drive in open loop velocity mode, the purple is following error (look, no noise component!) and the white is EtherCAT reported velocity feedback (should match the command), and the gold is the simulated quadrature encoder output feedback velocity read by a Mesa card (to make sure EtherCAT itself wasn't causing problems, and it isn't...)

The Yaskawa drive performs much much better than the JMC!

~~~

Yaskawa SGD7S EtherCAT servo drive in closed loop velocity mode (modulating velocity to keep positional tracking), as you can see the green EtherCAT velocity is solid while also the gold Mesa quadrature encoder feedback matches it (time shifted slightly), and the purple following error is minimal due to LinuxCNC's PID being tuned decently (as well as the drive itself having been auto-tuned).

~~~

Yaskawa SGD7S analog velocity drive in closed-loop velocity mode (modulating velocity to keep positional tracking). Notice the green velocity feedback closely matches the red command and there isn't any perceptible ripple in the white following error.