Leaderboard

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.

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. 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. 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. 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. No debug or live-tools for interacting with a Slave. 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.

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.

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

So I wanted to make a VIM that was essentially "Convert input into 1D string array". If you passed it a 1D array of anything it would convert each element to strings (similar to the debug VIM that ships), but passing in any scalar would do assorted things depending on the scalar (single item array for things like numerics, but a Path would split into each component, and different methods for other types). I thought it would be a good idea to have an option that if an enum is passed it, the array passed out would be the list of all of the options converted to strings. They way to get this is "Get Numeric Information" on the Data Type Parsing palette, but it uses a Variant input and therefore allows any input. And there was no "Assert enum" on the "Assert Type" palette. So, I've made one: It seems to work with every data type I can think of, because I don't know what besides an enum is a valid input both for a %s input to a "format string" node, and can also be an input for the "split number" node. I was wondering if anyone else can think of anything that is a valid "%s" conversion (like string, path, VISA reference, assorted DAQmx references) that is also valid for "split number". I am hoping to avoid discovering a data type later on that I didn't think of that also accepts this case and breaks "Get Numeric Information". Assert Any Enum Type.vim