Beckhoff PLC as an EtherCAT Bus

At my current job we have a relatively new system that has an Allen Bradley PLC as the main controller with some local I/O, but a lot of remote I/O including a couple racks of Beckhoff I/O and several EtherCAT devices that talk to the Beckhoff.

Apparently the local Beckhoff Distributor told one of our vendors that the Beckhoff PLC could be used as an Ethernet/IP to EtherCAT bus and you didn't need to write a PLC program.

It does this by creating an Ethernet/IP Slave that gets its own ethernet port and is controlled by an Allen Bradley Generic Ethernet Module. Variables are created and linked to the I/O data points on the EtherCAT network and then written to an ethernet assembly file that is sent to the Allen Bradley.

When I unplug ethernet from the port that is connected to the Ethernet/IP Slave on the Beckhoff, I can see communication loss at the Allen Bradley and I can see communication loss at the Ethernet/IP Slave in TwinCAT System Manager.

The problem is that this isn't causing my EtherCAT devices to de-energize.

I went into TwinCAT for the PLC and found that it's 100% setup in the System Configuration. There's no PLC program. "We don't need one" according to the vendor and the Beckhoff distributor.

I've read the TwinCAT manuals, spoken to my Beckhoff automation specialist, and spoke with Beckhoff tech support. None of them seem to know a lot about getting the EtherCAT Master to go into alarm and de-energize the network of devices. This seems like it should be really freaking standard for what's essentially a PLC configured to be remote i/o bus to not have some canned solution to configure the I/O for last state versus fail to off, fail to on, fail to min/max/predefinied analog output.

As someone who comes from Allen Bradley, I'm expecting to see dip switches, or an I/O configuration setting, but it seems like everyone from the Beckhoff side just looks at you sideways.

In fact my automation specialist got really defensive when I started asking questions and implied that he recommended this solution to our vendor and that there's nothing wrong with it when there's obviously serious problems with it.

The implications are that valves that control hazardous materials will not close upon loss of communication with the Allen Bradley PLC, nor if the Allen Bradley PLC goes into fault, so this REALLY NEEDS to get fixed.

This is my first experience with Beckhoff and while I like the platform there are clearly some quirks that I need to learn all the to work arounds.

I'm working on getting a spare PLC so I can run a test setup in my office. The machine with the Beckhoff is in production right now and doesn't have much if any downtime. I would like to know if I can just link the communication status from the Ethernet/IP Slave to one of the variables in the EtherCAT Master that will just disable everything easy peasy.

Tech support seemed baffled by this question and said I would need a PLC program. Does Beckhoff seriously not know anything about basic I/O configuration or did I just talk to the wrong person? It just baffles me that they would give this Ethernet/IP slave functionality, but not have a way to have status faults cascade into other networks.

Anyway, hoping there's a way I can handle all of this in the TwinCAT System Manager, not so that I have to do less work, but mostly so I can show my vendor so it's easy for them to justify going back to fix this for all the systems they installed improperly.

What I'm looking for is a way to link the Ethernet/IP Slave communication fault bit to some bit in the EtherCAT Master I/O Tree that will tell it to de-energize all the output modules.

I dont know Beckhoff or Ethercat, but I agree with your opinion that the expected behaviour upon loss of the connection to the master, the slaves outputs should go off. At least that should be the default behaviour.
My experience with Profibus and Profinet is that you can specify the behaviour, usually off, on or hold last state. Off being the default.

You are probably using the EK9500 ?
If so, the manual mentions the parameters 'EBus-Fallback-Modus' and 'FBus-Fallback-Modus' with the possible selections 'Set to Zero', 'Freeze', 'Stop Ebus'. Default: 'Set to Zero'

Instead of the EK9500, they installed a CX 8095 and downloaded the Ethernet/IP slave add-on.

I will look into replacing the PLC with the EK9500 and see where that takes me.

Try to investigate if the same parameters are available in the CX8095.

Since the CX8095 is a full PLC, it could also be that there is a special configuration in the CX8095 for setting up the directly connected Ethercat IO as Slave IO for the Ethernet/IP master.
Just speculating, since I dont even work with Beckhoff !

Hello. I have some experience with TwinCAT and EtherCAT, and much more so with EtherNet/IP. I will try to provide some feedback which I hope is useful.

RedSoxFan3 said:

Apparently the local Beckhoff Distributor told one of our vendors that the Beckhoff PLC could be used as an Ethernet/IP to EtherCAT bus and you didn't need to write a PLC program.

It does this by creating an Ethernet/IP Slave that gets its own ethernet port and is controlled by an Allen Bradley Generic Ethernet Module. Variables are created and linked to the I/O data points on the EtherCAT network and then written to an ethernet assembly file that is sent to the Allen Bradley.

Click to expand...

This link is the manual for TF6280. The EtherNet/IP adapter for TwinCAT PLC. I can not find the section which describes "Variables are created and linked to the I/O data points on the EtherCAT network and then written to an ethernet assembly file that is sent to the Allen Bradley." Even if it is possible to map the IO points for the Ethernet/IP assemblies to the EtherCAT IO, what I don't understand is how EtherCAT master application can be made aware of the EtherNet/IP communication status and adjust the control of the state machine of the EtherCAT I/O without a TwinCAT program for this one crucial task. Products like the Hilscher or HSM EtherNet/IP to EtherCAT gateways have precisely this functionality built-in.
If the IO points that are needed for the Logix PLC are not needed by the TwinCAT application, my advice would be to get the product below and connect the IO directly to EtherNet/IP.
EL6653-0010 | EtherCAT Terminal, 2-port communication interface, EtherNet/IP, adapter
https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/el6xxx-communication/el6653-0010.html

Thanks Alfredo.

I’ve been looking at using the EK9500 as those come with an eds and UDT file, but I still need a gateway for the EtherCAT devices.

I’ll take a look at Hirschner and HSM. I was disappointed to see Prosoft didn’t have anything.

Regards,
Derek

Prosoft has very good support for North American (i.e. Rockwell) networks. Support for German networks at Prosoft is mainly Profibus an Profinet.


I think both Hilscher and HMS networks have done a decent job in setting-up their local support in North America. I would recommend using the gateway because it has the gateway functionality built-in. The links below maigh make the search a little bit easier.

https://www.anybus.com/products/gat...-gateway-ethercat-slave---ethernet-ip-adapter


https://www.hilscher.com/products/g...ustrial-ethernet-fieldbus-serial/nt-151-re-re

Looking a bit further on the website for EK9500, the website says that it will connect to EtherCAT terminals AND EtherCAT Box modules, which appears to cover what I need. This implies that it can serve as a true gateway.

I think this should result in a one for one replacement of the CX8095. But I'll have to confirm with technical support.

Yes the EK9500 connects the EtherCat to EtherNet/IP. We have some on a few pieces of equipment. Configureation of the EtherCat terminals is all via webserver. The EK9500 are connected to Compactlogix in our application. They have been in use for about 3 years and seem to be doing fine. Although it is not quite a harsh environment.

The EK9500 is what you need.
https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/ekxxxx-bus-coupler/ek9500.html


The CX8095 is a PLC with EtherCAT master and EtherNet/IP adapter functionaltiy. As per my understanding of your requirement, CX8095 is not what you need.

https://www.beckhoff.com/en-en/search-results/?q=CX8095

You can use the EK series IO with Allen Bradley,
Simple IO works well. Getting the IN/OUT counts can be tricky as each card a different length.

Problems arise when you try and use counter cards they may default to 2x Bi-directional and you may need 1x Combined up (or something) so you have to write MSG string to get it to "boot" correctly (every time) . Also card failure, causes issues as you lose the whole rack of IO due to header length changes.

Personally i'd either use a Bechoff controller with the IO or stick to Allen Bradly IO....

As stated, for what you were doing, using the CX was not the best choice. If you want fully integrated Beckhoff I/O where AB PLC is in full control, even with a comms loss at the remote I/O, then as stated, use an EIP gateway. This was not a Beckhoff problem. Beckhoff provides all the tools you need. It’s up to the machine builder/integrator to choose the best tool for the job.

Now, I know it's neither here nor there at this point, but I'm going to ask anyway - For a new system/machine, why would you specify AB PLC, but then you want third party (Beckhoff) remote I/O??? I know you think you're making it "easier" to support by keeping it RSLogix software (because that's what everybody there knows) while making it less expensive by choosing Beckhoff (or whoever's) I/O. But you've actually made the system more complex and complicated, hence making it more difficult to support. Furthermore, with the different communication protocols you’ve deliberately introduced (EtherCAT and EIP) and the gateways required for that, you’ve reduced the overall performance of the system, and absolutely the data is not going to be highly synchronized. For an already existing sytem that you’re adding onto, doing it that way makes more sense, and sometimes it’s just necessary. I understand that. We’ve done it that way for already existing sytems as well. But…..for a new system??? No!! Why make it more complex and complicated if you don’t have to??

You had the Beckhoff CX and the IO. I would have just stuck with that for the whole system because then you would have had the much better performing EtherCAT (vs EIP), along with a myriad of other benefits over your AB system, not to mention it would have been all one platform making it less complex and easier to support.

busarider29 said:

As stated, for what you were doing, using the CX was not the best choice. If you want fully integrated Beckhoff I/O where AB PLC is in full control, even with a comms loss at the remote I/O, then as stated, use an EIP gateway. This was not a Beckhoff problem. Beckhoff provides all the tools you need. It’s up to the machine builder/integrator to choose the best tool for the job.

Now, I know it's neither here nor there at this point, but I'm going to ask anyway - For a new system/machine, why would you specify AB PLC, but then you want third party (Beckhoff) remote I/O??? I know you think you're making it "easier" to support by keeping it RSLogix software (because that's what everybody there knows) while making it less expensive by choosing Beckhoff (or whoever's) I/O. But you've actually made the system more complex and complicated, hence making it more difficult to support. Furthermore, with the different communication protocols you’ve deliberately introduced (EtherCAT and EIP) and the gateways required for that, you’ve reduced the overall performance of the system, and absolutely the data is not going to be highly synchronized. For an already existing sytem that you’re adding onto, doing it that way makes more sense, and sometimes it’s just necessary. I understand that. We’ve done it that way for already existing sytems as well. But…..for a new system??? No!! Why make it more complex and complicated if you don’t have to??

You had the Beckhoff CX and the IO. I would have just stuck with that for the whole system because then you would have had the much better performing EtherCAT (vs EIP), along with a myriad of other benefits over your AB system, not to mention it would have been all one platform making it less complex and easier to support.

Click to expand...

According to tech support and the distributor, an EK9500 would not work because we have a dozen 3rd party EtherCAT devices and the EK9500 cannot import ESI files. It apparently can only recognize Beckhoff terminals and box modules.

As for why I would want a system like this? Well I don't. If it was up to me all of the Beckhoff and EtherCAT would be replaced with 5069 or 5094 I/O modules and Ethernet/IP devices. But I'm never going to sell that to management. Why was it used? My guess our manufacturer put together a quote with all Allen Bradley I/O and then our project manager decided he could save money and get a better bonus coming in under budget by switching to Beckhoff. Or their automation guy asked if he could use Beckhoff to cut costs and the project manager said sure why not? He wasn't an automation guy.

This system was installed before I started. It's 5 years old, I started about 3 years ago. What I'm working on now is cleaning up some actions from our most recent audit.

To offer some backstory...

This system was jointly programmed by my predecessor and the manufacturer and when I started finding bugs in his program, I was "just a beginner" that never worked on a large system before and he started bashing me in front of my boss over email.

At that point he decided to work remotely for 6 months until his retirement (due to the pandemic) while he was doing a migrate & refurbish of an old PLC5/25 system.

After he left, I inherited this project that he spent 6 months working on from home. His program was half finished and was riddled with UDTs inside of UDTs inside of UDTs... about 4-6 layers deep. 95% of the data structure was completely unused. It's like he pulled a shell program that was written in PlantPAX and then used Studio 5000 to program it. All of the tags were like A.B.C.X.Y. The tag names were not descriptive enough to really describe things in a meaningful way. I had an outside automation vendor take a look at the program and he agreed I should start from scratch, so that's what I did.

As I dug into everything further. I realized that none of the I/O had been verified and there were still mechanical issues with the new install. I received the first draft of the electrical drawings. But he told me he didn't save the drawings he made. "He just printed them once and made copies." Then after he left, the electrical contractor gave me some Rev 1 copies of the drawings that magically appeared. The project manager also never had anyone draw up P&IDs or mechanical drawings of the system, even though they replaced 100% of the plumbing. They just went off pictures leaving behind design flaws from the original system that was designed in the 80s. To top things off we were all out of money and all the electricians we had retired all at once, so there was no one to help me trace out wiring problems. We had probably 8 to 10 junction boxes and the drawings didn't properly show where each device was landed.

I was too busy to take on both this huge mess as well the system I'm working on now, so we had the manufacturer rewrite part of the control system for what I'm working on now. The idea was to eliminate a labyrinth of one-shots and indeterministic logic that I had identified as one of the root causes for overpressurizing a scrubber and other poor controls. If the operator mashed the advance button, one-shot bits could become latched and cause valves to open. This along with a massive vacuum pump, a grossly undersized scrubber, and poor PID controls blew up our scrubber. We blew up 3 scrubbers in the first 6 months I worked here...

Unfortunately someone didn't give them a good specification and the process engineer never reviewed the FMEA to make updates to the interlocks. It was ordered before I could review everything. They only removed some of the problematic subroutines and didn't fix most of the weaknesses in our system. The worst routine which was the output control routine is still full of one-shots and there's no separation between auto or manual.

After spending a ton of money on the new control, its taken me close to a year and a half to finally convince people to let me start making changes, because they didn't want the downtime and wanted to hide the fact that we wasted a ton of money on the "control upgrade". It wasn't until the machine started having issues with sensors that people let me work on the system again. All the things I said could happen were finally happening. The recipe was shutting itself off without any alarm horn or alarm logging.

Several system interlocks could stop the recipe, but would either trigger an alarm for just one scan cycle or didn't have any alarm whatsoever. If a deviation alarm was active when the recipe stopped, the horn would auto-silence itself because he was mapping the alarms to a DINT and was using LES and MOV functions to reset acknowledgement bits instead of an MVM.

The entire system still lacks proper communication alarms, including all the ethernet/ip distributed I/O, not just this ethercat network, which is what I'm trying to button up.