EtherCAT Survey- NI would love to hear about your experiences!

[ZKami]

Admins- if this isn't appropriate for these forums, please let me know!

Hello Lava forums,

I'm a Product Support Engineer at NI and I'm part of a team trying to gain a better understanding of what customers want out of their EtherCAT systems. We want to know what kinds of systems customers use in order to improve NI’s EtherCAT software offerings in the future. If you or your company uses EtherCAT, whether NI or 3rd Party, we would love to hear about your experiences.
 

This survey will be completely anonymous and should take less than 10 minutes, depending on your particular setup. If you have a lot to say about EtherCAT, we’re here to listen! There will be a space for your contact information at the end of the survey. You can also feel free to comment on this post, as well as send me a private message. 

https://survey.sogosurvey.com/r/PNeq9E

Thanks for taking a look!

Zofia Kaminski

Application Software Product Support Engineer | NI 

[MarkCG]

Hi Zofia we talked before but I'll all add my bit here to see if anyone else has comments. EtherCAT is very powerful but so many of those features are held back by the NI EtherCAT master. For example you can get diagnostics on each individual link slave to slave but NI doesn't show that. No official support for topologies other than line or ring. I have gotten it to work with an EtherCAT junction but nothing displays correctly in the project. No hot-connect groups like with TwinCAT. Configuring slaves with CoE is difficult. I use TwinCAT for that. Just the bare minimum is there in the master to get it working. I use the Beckhoff EP series modules to vastly reduce the wiring in my control systems, because I can place the modules next to the things bein controlled and run a cable directly to them, often with jsut off the shelf connectorized cables. This beats the traditional way of bringing everything back to the control cabinet with your compactRIO or PLC in it. I don't think NI is that interested in industrial control and automation and that's why I'm slowly moving everything toward beckhoff/TwinCAT. Just a much better system for what I need to do

[PiDi]

1 hour ago, MarkCG said:

I use the Beckhoff EP series modules to vastly reduce the wiring in my control systems, because I can place the modules next to the things bein controlled and run a cable directly to them, often with jsut off the shelf connectorized cables. This beats the traditional way of bringing everything back to the control cabinet with your compactRIO or PLC in it. I don't think NI is that interested in industrial control and automation and that's why I'm slowly moving everything toward beckhoff/TwinCAT. Just a much better system for what I need to do

Same story here. We've just started to standarize on Beckhoff. EtherCAT is nice medium for realizing distributed systems. We use EP boxes for distributed IO (just as your case - a great way to reduce wiring; add IO-Link sensors and actuators to the mix and you save A LOT of work with the system assembly and testing and gaining unlimited flexibility). EL terminals for the control cabinet - you can basically build any system capabilities you like, and add anything any time in case you'd forgot. Also, you get safety-rated terminals and boxes (and you can build distributed system with that, no need to bother with all those cables from curtains and interlocks from the other side of the machine). And motion control with EtherCAT based servodrives. And everything integrated within single TwinCAT environment (and they even know and care what source code control is). And you can have everything deployed on Windows based industrial PC with real-time TwinCAT capabilities and have some other applications running side-to-side. Well, if you haven't noticed yet, I'm in love with this whole system

That being said, I still consider LabVIEW ("old-gen" one, mind you) to be superior environment. It's sad that NI never had and still doesn't have too much to offer in terms of machine control and industrial automation.

[sam]

Hi Zofia,

In short NI's implementation of EtherCAT functionality is not on par with other NI tools as I've experienced.    I'll try to explain on this as best I can.  

 

1. NI only Supports CoE, CANOpen over EtherCAT.  This is just fine as I (perhaps most devs ) has CAN/CANOpen experience.    This is not an issue as I stated but I thought to add just so we know that we are talking only about CoE in following points below.
2. NI's Server implementation is not ready for Non-NI hardware.  It seems the server was solely designed with other NI-Slaves in mind.  
   • Connection to Slave devices either succeed or fails.   The ones that fail show no indication the reason for failure.    A connection to an inverter took me three weeks because of this lack of feed back information.  Contacting NI support was not so helpful as it seems NI AE are not very familiar with EtherCAT.    I asked the AE if they can some how get access to lower layers to know why we could not connect.    If there's a failure connecting to slave devices we need to know the reason.  Obviously there is a series of checks and balances that return a false.  what exactly caused this check to be false.
     • First reason we found out from AE was that the ESI (XML slave information) was a multi-level document, and NI only support a certain type.  Why could we not get that information when importing the XML?
     • Second reason was in process of changing the XML slave information to a format that NI prefers, we did not update the version.    Again we failed to connect but didn't know why.  The failed connection is exactly the same as these two problems.  
3. The CoE is partially implemented.  There is programmatic SDO read (via invoke node).  Bur there's no PDO.    Only way to get PDO to work is editing the XML file.  Why?   I guess this is related to scan engine, but if there's anything  I'd like is have PDO read/write functionality same as SDO.
4. No debug or live-tools for interacting with a Slave.
5. No Windows version.  I know that we need RT OS for EtherCAT but for development we could/should be able to use our dev PC/laptop.   This is possible, and I can refer you to free software like EC Engineer can run on Windows (without RT clock ) and Open Source projects can do Windows SOEM

 

I hope this helps, as I'm just going of my memory.  I'd be happy to discuss this further as CoE is an important communication bus for now and future.

 

 

 

[Michael Aivaliotis]

I will complete the survey but wanted to add here as well. I use EtherCAT primarily with 3rd party slaves and only use NI hardware\software. I have limited time resources and prefer to stay within one environment, so I choose NI software whenever I can. I just don't have time to learn all the 3rd party tools. Maybe others can help me here. if anything, at least this thread has brought other ECAT experts to the surface, I can DM for help 😉. I have come across a few limitations but I have been able to work around them because I have no choice.

One thing that is frustrating is there is no way to define a topology with NI tools. I'm sure there is an algorithm that defines this under the hood, but it's not controllable by the user. If you have a daisy-chain setup, then it follows that, however if you add a switch to the mix then I have no clue how it's determined. This is critical to the software development side since device IDs matter and they change. If you pull out a device from the chain, then the downstream device IDs change. this can get frustrating from a configuration management perspective. Device IDs are settable on some 3rd party devices with physical switches but the NI tools cannot query these IDs for some reason. This would help make the topology a little more predictable. Another limitation I ran into recently. FOE is not fully supported. FOE WRITE is supported but not FOE READ. I think in general the ECAT tools need a higher level API that can be used within LabVIEW. For example, the EtherCAT Library for LabVIEW from Ackermann Automation is a good example. It seems NI put in the bare minimum required to meet the standard and support one or two of their own hardware with little consideration for third party devices. As others have posted, basic error handling on faulty ESI files should be baked-in.

[ZKami]

Thanks all for these great and detailed responses! I'm definitely aware our current offering has a lot of areas of improvement. 

MarkCG - Yes, I still have all the notes from our interview, but appreciate the summary reiterating what we talked about. 

PiDi- Thanks for your summary of your system. I'm glad to hear you like LabVIEW, though understandable that the lack of machine control and industrial automation is disappointing.  NXG is where a lot of investment is now, so most likely (and I can't say anything definitively at this point) any improvements in this area will happen there first. 

Sam- This is really helpful, I appreciate that the feedback is so logically laid out. You mention that it supports only CoE. Would there be other protocols/CAN implementations that you would would also like to see? It does seem like CAN isn't the problem. 

Michael Aivaliotis- Thanks for this insight. I've heard many mention the topology as a problem, but appreciate the way you've spelled this out. For testing I only have one 3rd party slave device (working from home like many people, it's harder to get equipment). Having a description of the behavior is very helpful.