AUT EXT via Ethernet/IP using Schneider PLC M580

in simplest terms there are two steps to it:

Before you can do anything with AutoExternal, you need a bunch of IO between robot and plc. Only after you have that part working and you can confirm that you can send signals both way this step is complete.

Then you can look at actually using those IO for whatever you need - including AutoExternal interface. Btw. the AutoExternal interface is just a handshaking option that is included as a default (hence standard).

About the actual implementation of the connection between two nodes:

1. need to determine fieldbus type (must be something that both nodes can use)

2. must determine role of each node. one of them must be a master and the other must be slave - you choose. communication does not work in any other case (master to master, slave to slave). the most common choice is to to make PLC a master and one or more robots are slaves.

3. parametrize slave. this usually means setting node address and in some cases specifying IO range and mapping it. simple devices (input module, or output module) with fixed function have fixed IO range but more flexible products (PLCs, robot controllers etc.) can be parametrized. in case of EIP you also need to specify instances. normally this is it because slaves are unaware of their surrounding - they do not have info on master or other slaves.

4. parametrize master. master must have info on all owned slaves (address, IO range...). this requires compiling sort of a list or a database. for populating this list slaves are chosen from a catalog (which must be populated by importing device description file for each type of slave). for simple data exchange one can also use generic device description file and parametrize each instance according to specific slave. details on configuring master is product specific. if you need help on some PLC brand, consider contact product manufacturer or searching for help on PLC forum.

Side note:

You mention that your PLC is a safety PLC. If your EIP connection to robot includes CIPsafety, you will want to use AB PLC. Some people have succeeded in using CIP safety with KRC and other PLC brands but unfortunately this was a difficult path with a lot of pain due lack of support. KUKA has info on setting this up with AB PLCs only so users of other PLCs are left to fend for themselves.

Good luck.

Quote from robotninja

It seems all the online posts talk about mapping I/O between robot and PLC, which is easier with the hardwired option. How to set up or map I/O if using Ethernet/IP communication?

Eh? Auto-External I/O works exactly the same, there's just a different adapter in between.

Quote from robotninja

Just to clarify, I'm asking about how to set up things on the PLC side, not the robot side.

Are you trying to set up I/O, or Safety I/O? Those are two different things. We also need to know if your robot has SafeOperation or not.

EIP allows choice of 2 or 8 bytes for safety. if you choose 2 bytes version, you cannot use SafeOperation.

Quote from robotninja

But the AUT EXT communication is not CIP Safety, correct? It is non-safety EIP.

Correct. In the EIP configuration on both both KRC and PLC, you need to set up an equal number of bytes In and Out. Then you need to map the EIP signals to a specific range of $INs and $OUTs in the KRC. After which, you need to assign the Aut-Ext signals to the correct $INs and $OUTs.

Quote from robotninja

@panicmode

When you talk about address range, do you mean modbus addressing?

No, this topic is all about EIP. where did modbus come from?

Quote from robotninja

Schneider tech support suggested using modbus.

not going to happen... did you look at modbus option on KRC4? there isn't one.

CIPsafety is a protocol is used to exchange safety data over EIP.

KRC4 can exchange standard and safety data over EIP if KRC4 is slave.

KRC4 can exchange standard data over EIP if KRC4 is master.

KRC4 can be master (to bunch of slaves) and at the same time also act as a slave (to several masters).

KRC4 must have ONE safety interface. for that there are four options:

a) parallel safety via X11 (or X11+X13) - using whatever you like (no safety PLC, or any safety PLC)

b) CIPSafety (via EIP - using AB safety PLC)

c) ProfiSafe (via PNET- using Siemens safety PLC)

d) FSoE (via ECAT - using Beckhoff safety PLC)

The question is what is the safety interface on your system. Without one, there is no running robot.

I would suggest to Schneider tech to get safety PLC and laptop, call KUKA and arrange for visit, go there and setup safety network, document it (make an application note) and share it with clients and KUKA. If you check forum posts you will find that few people have succeeded in doing that with other PLCs (Omron i think).

Is it possible under the Safety Distributed Bus there are two ranges of bits assigned to be used by KRC4 controller? I'm unfamiliar with Schneider and EIP, but here's what it looks like in Siemens TIA Portal (using ProfiSafe/ProfiNet) if it helps at all. Since you no longer have any safety faults and are able to jog, run programs, etc, it seems like the safety bits are assigned and integrated properly into the PLC program.

EtherNet/IP was developed by AB and it also happens that AB PLCs had the exact same problem for quite some time. therefore on AB solution was to use two network interfaces - one for standard and another for safety interface. This was a problem for many since those things are not exactly low cost and many systems did not have spare slot for second card.

Competition like Siemens did not have that issue - ProfiNet allowed standard and safety data over same interface.

Eventually AB decided to play catch and created workaround that allowed using one NIC for both standard and safety data. It was a software option in form of PLC CPU firmware upgrade and so called AOP (add on profile). If i recall this was made available in RSL5K after v20 (not sure when exactly, maybe V22?).

I would not be surprised that other PLC brands that are licensing Ethernet/IP from AB are also trying to catch up or make workaround.

please share some PLC side settings. i am sure others would find it useful as KUKA does not have examples on this PLC type

Hello,

I have been working on a robot for some time now but I have never had to do modbus with krc4/krc5 to exchange with a Schneider PLC. But I have a client who wants to do it soon so I wonder about the subject.

robotninja can you please tell what you are using as side material. Ethercat---->x?-->x?---> Api schneider.

Thanks in advance.

why not let PLC use the same type of network? pretty sure Schneider PLC will have an EtherCat option. the other option is to use some gateway like AnyBus, then you can match up different bus types

Good morning,

Thank you very much @panicmode for your response.

In fact, my current project setup is:

Schneider QUANTUM PLC: exchange protocol possible in profibus, modbus but no EthernetTCPIP.

KRC4: Exchange protocol to be defined (ETHERNETIP or ETHERCAT+GATEWAY) and security with X11.

The choice currently proposed by KUKA would be to switch to ETHERCAT/MODBUS using a CX8110 from Beckhoff as a gateway. The problem is that with this solution, you have to master and program the CX8110 with Twincat. It is therefore heavy in configuration.

I am therefore looking for a simpler hardware solution such as using a simple coupler which would be supported by KUKA with an XML in ETHERCAT/MODBUS.

On the subject of robotninja, I imagine he is in ethernetIP. ?

Do you know of a solution easily supported by Workvisual with a reliable XML file to communicate with a Schneider PLC that will only be able to do MODBUS?

Thanks in advance.