Real-Time ETS etherCAT supported chipsets

[St3ve]

Hi,

I've done a bit of looking and can't seem to find a list of supported chipsets for the etherCAT driver. The readme (v2.2) has a reasonable list of NI hardware that is supported but no details on the actual chipsets. Is this information available or is it the same as the chipsets for RT ETS?

Many Thanks,

Steve.

[Lewis_G]

Hi Steve,

Ethernet adapters that use the same chipsets as our recommended hardware should work on your ETS system.   However, since we only tested with NI products, we can't guarantee anything.

Below are the NI products that we tested and suggest to use in your RT Desktop system as EtherCAT master. The chipset info is also available on ni.com (in the adapter's data sheet).

• PCI-8232 (Intel 82540EM Ethernet)
• PCIe-8231 (Intel 82572EI Ethernet)
• PCIe-8235 (Intel 82572 Quadport)

Hope it helps!

[St3ve]

Lewis,

Thanks for the info. We're looking into using NI controllers as etherCAT bus masters which leads to another question:

Is Fail Safe over EtherCAT (FSoE) supported?

Many thanks,

Steve.

[Lewis_G]

Hi Steve,

As far as I understand, Safety over EtherCAT (or FSoE) defines a safe communication layer, to transfer safe process data between Safety over EtherCAT devices and to use the FSoE protocol, the device must be a FSoE device.

After looking at our EtherCAT devices like the NI cRIO-9074 Master Controller and NI 9144 Slave Chassis they do no list support for FSoE and after more searching, I can’t find any information to say we support FSoE.

Is there anything else I can help you with?

Thanks,

Lewis

[sahpe]

Hello Steve, 

I believe Lewis is correct in regards to Safety over EtherCAT as far as NI products are concerned. Have a look at the ETG website for vendors that are members and support this protocol:

EtherCAT Technology Group - Safety

In regards to your question on chipsets, I believe this article will help:

Requirements for Desktop PCs as LabVIEW Real-Time Targets

Hope this helps!

Kind Regards,

Michael S.

[sahpe]

Hello again, 

Scrap my last post, here's a better one! 

EtherCAT Safety products allow you to embed the safety logic onto the modules/slices themselves, or have a safety master slice on the system. You can use that vendors System Manager or configuration utility to create your safety logic and then deploy it onto the safety hardware. You can then incorporate access and communications to that safety master from your PLC code, or LabVIEW in this case  (if necessary). I would suggest then, that the NI master you are considering to use does not need to be compatible with SoE, as the safety logic will not rely on the LabVIEW code or the EtherCAT master. This gives the SoE hardware the advantage over non-safety-specific hardware, as it does not rely on the LabVIEW code or the PLC itself to be running; in the event of a crash of any kind, the safety hardware will continue to work independently. There is a lot more information on the ETG Safety FAQ site. So, hopefully this helps a bit more on the SoE side of your question. 

Your ethernet chipset question confused me a little though, and this is why I read the thread again after I posted my first response! 
If I understrand it right, you want to use NI hardware as masters and use slaves from other vendors, is this correct? In this case, there are EtherCAT compatible cRIO controllers (you will need to use the second ethernet port to connect to EtherCAT slaves), or you can use a normal PC with one of the ethernet PCI/PCIe cards that Lewis kindly mentioned. You can try other ethernet devices with the same chipset as these three cards, but obviously it's not guaranteed that they would work flawlessly, as Lewis correctly mentioned.

Now, the link I posted before points to ethernet chipsets that will allow remote access to a LabVIEW Real-Time PC target, however this doesn't directly relate to EtherCAT compatibility. I believe what you will need to do is cross-check this list, with the list of EtherCAT compatible ethernet chipsets. Proper real-time communications are guaranteed only with certain types of network cards. It could be any standard brand, what matters is the chipset used. So basically, it will have to be an Intel chipset. You can enable EtherCAT on a compatible card and get true real-time comms; the system will allow you to use an "incompatible" card, but real-time capability will be limited. I would personally avoid this last option altogether for reliability's sake!

To summurise:

- if you are looking to use a cRIO as a master, there's no problems as long as it has a second ethernet port, which will be EtherCAT compatible, and this will use the NI IndComECAT driver.

- if you are looking to use a PC with LabVIEW Reat-Time as the main OS, then I would suggest using one of the NI cards for reliability. Otherwise, select an ethernet card with one of the latest Intel chipsets from the list on the aforementioned link, there is a chance that this might work as well. 

- if you are looking at non-NI embedded controllers, then you should see if one of those controllers has a chipset that is the same as one of the 3 cards that Lewis menaioned previously. Alternatively, you can check the above list again, and see if you can find a matching chipset on the ethernet card on the controller, which again is not guaranteed to work, but just might.

I do hope that this post helps a bit more! But let us know if you have any further questions. 

Kind Regards,

Michael S.

[St3ve]

Michael,

You are correct, I would like to use NI hardware on a variety of EtherCAT networks as bus masters. I think for most applications an NI industrial controller will be adequate but for some projects I'd like to be able to use some high horsepower i7 desktop hardware hence the question about supported chipsets.

Regarding the SoE I agree that the saftey logic is implemeted on the saftey PLC slice and is independant of the bus master. However, according to this link (section 4.2) a master is required to copy the SoE frames and should also provide a config interface for the SoE nodes. Obviously the config interface would be nice but is not really required. Could you find out if the NI driver supports this?

Regards,

Steve.

[sahpe]

Hello Steve,

Apologies for not getting back to you sooner.

I read the section of the article you refer to, and I expect that members of the ETG will comply to both these points. However, NI is not part of the ETG as far as I know, even though they make EtherCAT products, so let's look at how you can reach the required result with a workaround.

I am speaking to one of the developers of SoE and will get back to you on how compliance to your first point can be achieved, as I believe it's not that clear in the document.

On your second point, what you can probably do is see if you can use LabVIEW to create an interface to the System Manager or configurator of the vendor of the Safety hardware. I know that some vendors will offer an API to their configurator, e.g. Beckhoff have an API you can use to pull the System Manager's interface into your code, and expect this can be achieved in LabVIEW as well.

Hope this helps for now, I will get back to you on the "copy the safety frames" point.

Kind Regards,

Michael S.

[sahpe]

Hello again Steve,

Here's clarification related to copying frames...

The Safety master is not an EtherCAT master, so someone has to copy the process data from the logic terminal to the safety input terminal and vice versa. This is not a safety related feature, but an EtherCAT feature. In the EtherCAT specification it is called “copy statements” I believe. When you create an EtherCAT configuration with the “EtherCAT configurator” with a program under the safety master, you will get an xml-file with all required information for the third-party master. In this xml-file the “copy statements” should also be included. These copy statements must be supported by the EtherCAT master in principle.

Hope this helps,

Kind Regards,

Michael S.