KUKA KRC4 and SICK EFi-PRO CONNECTIONS

is that Sick PLC capable of acting as ProfiSafe master? Did you integrate KRC4 GSDML file in it? If answer is yes to both questions than maybe what you are after is possible the way you want. But that is only the prerequisite, more things are needed such as installing X311 plug, passivating X11...

check previous discussions

Wait, Profinet or Ethernet/IP? Those are two completely different protocols, and cannot co-exist on a KRC.

What options was this KRC-4 ordered with? Which options are installed? If the robot was originally ordered with ProfiNet and ProfiSafe, it won't have an X11.

Did you ever figure out how to get this working? I am also in the beginning of setting up a Sick Safety Scanner with a Kuka Krc4, I cannot communicate to the krc4 when in the Sick Designer Software. I do have a good Tutorial from the Sick Side but nothing on the kuka CIP Safety and how to set it up.

I was told that using the Kuka SafeOperation 3.4 would allow me to communicate with the Sick Scanner and no hard wiring would be required.

Please let me know what you found out Nishant.

Thanks,

you guys really don't pay attention. those are two different fieldbusses you are talking about. pick one, stick with it. read previous topics. this was discussed many times. report problem with YOUR implementation so you get feedback on what is wrong.

Before you can start dreaming about some safety network configuration, you need to have a very clear BIG picture:

* This means understanding that fieldbus nodes can talk to each other only if they are all designed to work with the SAME fieldbus type. You cannot connect directly Ethernet/IP device to a ProfiNet network or the other way around. So pick your fieldbus network type and stick with it. There are gateway devices that may connect two dissimilar networks but... that only complicates things as both networks still must be able to function independently (each one of them needs suitable master). This is usually the last ditch effort to make things communicate and may introduce latency etc. if at all possible stick to ONE fieldbus.

* In order for things to communicate over some sort of fieldbus (Ethernet or whatever), they MUST have compatible settings. all nodes in one LAN must have:

a) Same subnet mask (which must be VALID of course).

b) Same LAN address (first part of IP address as defined by subnet mask)

c) Unique MacID (last part of IP address as defined by subnet mask

* if things are SAFETY rated, they have an additional and unique SAFETY ID, not just network settings.

* Most nodes on a fieldbus are SLAVES but every fieldbus also requires a MASTER. There is no way to communicate MASTER to MASTER... or SLAVE to SLAVE. this is why you cannot have two safety area laser scanner talk to each other, they are both slaves and need a MASTER. MASTER controls everything and SLAVES simply respond when spoken to. Some snowflakes got triggered by M/S terminology so equivalent terms also exist:

"MASTER/SLAVE"

"SCANNER/ADAPTER"

"CONTROLLER/DEVICE"

etc.

but the idea is the same, just some politically correct language police at work...

* MASTER may have different capabilities. Some masters can only support "standard data " (non-safe messages). This is example of any non-safety rated PLC. Safety PLCs support both standard and safe data.

* Just because you have two products with support for same fieldbus and one of them is master and the other is slave - it STILL does not guarantee that they can talk to each other. so... be careful when picking components, and best stay with things that are KNOWN to work with each other. or be prepared for extra cost, delays, pulling hair, hitting head against the wall etc.

If above is understood, we can move onto specifics of KUKA safety interface. This is just a detail that is based on above info.

If you are using network based safety (CIP safety, ProfiSafe or FSoe) you need:

1. removed or passivated parallel safety interface (X11/X13) because KRC4 controller must have exactly ONE safety interface (no more and no less). When NO interface is defined or you screwed up something in controller MADA, smartPad will show GRAY banner. When ONE safety interface is defined but not complete (safety PLC not controlling it), RED banner is shown on the smartPad. remember, red banner is a GOOD sign when setting up safety interface.

2. X311 jumper on CCU or X403 jumper on CCUsr, or wired external enable switch on a passivated X11 interface when jumper plugs are not available.

3. need suitable package installed on your robot. CIP Safety requires Ethernet/IP. ProfiSafe requires ProfiNet, FSoE requires hardware bridge (EK1100 + EL6695-1001, and note that this is the special one from KUKA, not the generic one from Beckhoff that lacks "-1001" sufix)

4. safety PLC that can be MASTER on YOUR safety network. If you are using CIP Safety on the robot, you need safe plc that can be a CIP Safety master. If you are using ProfiSafe on the robot, you need safe PLC that can be ProfiSafe master, if you are using FSoE on the robot, you need safety PLC that can be FSoE master.

5. connect things correctly. ProfiSafe or Ethernet/IP means connect KLI to safety PLC. FSoE means connect CCU X44 to EK1100 and connect EK6695 to FSoE safety PLC. Read schematics. KLI is internal port but may be exposed as X66 or X67.1 etc. X44 is internal port but it may be exposed as X65. Read schematics...!

6. Integrate KRC4 device description file into safety PLC project then configure it. These files are supplied with WorkVisual so check on your laptop WoV folder for Device Description Files subdirectory.

7. If using KLI (ProfiSafe or CIP Safety) make sure that network settings match as explained before. Safety ID must match. IF using ProfiNet, also device name must match - both on Device itself and in corresponding setting for that device in ProfiNet Master.

If using X44, make sure that you use correct device description file for EL6695. in WoW project that would be one from KUKA (not from Beckhoff) and it must be PRIMARY. On safety PLC side also use one from KUKA (not Beckhoff) and make sure it is SECONDARY.

So, how to fail:

1. don't take any training, figure things out on a job and ask for step by step instruction someone anonymous on the internet. after all it is only safety, what can go wrong? it's not like someone can get hurt or you can go to jail. or... is it?

2. ask vague questions without sharing your exact setup

3. don't use correct documentation (manuals and schematics) or correct version.

4. don't understand basics of networking

5. don't connect things to correct port or using correct cable

6. don't assign proper network and safety ID settings

7. don't use correct device description file or settings that are supported by ALL participants. If one device can only respond every 10ms and you are flooding it with messages every 1ms of course things will go wrong. And a lot of people immediately go for 1ms update instead of something reasonable and more conservative, even though they have never read manuals or datasheets and confirmed if that will work. depending on used GSDML, fastest update may be 8ms. In case of KRC4, CIP Safety requirement is that RPI is not faster than some 25ms or whatever. read the documentation or start with conservative values if you want things to work. then you can try to crank numbers until you start seeing failures and back it off a good margin.

etc.

Panic Mode, that is an awesome explanation, lots of good stuff here in your last explanation.

So what I have is a KUKA KRC4 that I ordered with KUKA.SafeOperation 3.4 ( Direct signal exchange between safety PLC and KUKA.SafeOperation via PROFIsafe, CIP Safety or FSoE (not in conjunction with X13))

The SICK Laser Scanner microScan 3 Ethernet/IP with CIP Safety as a Master; Part # in case you want to look at it - MICS3-ABAZ55ZA1P01.

I tried and tried talked to both Tech Support sides but could not get it to work.

I ended up removing the Safe Operation Option then using the CIB-STD and wiring X11 connections. I used the Outputs of the Laser Scanner to go into the PLC as Inputs then used those over Ethernet/IP to the KRC4 to override the speed. If someone goes into the warning zone it is forced to run at 5% in EXT and if they go into the Red it will force it to 0 then issue an EXIT command.

But I had to use wiring and I was trying to accomplish the safety over Ethernet IP.

I am getting a loaner from SICK to try out in the shop with a KUKA KRC4 Compact Agilus I have but that controller does not have SafeOperation but does have Ethernet IP.

I don't think you're going to be very successful with just a scanner as a Safety master. There are a lot of other signals that need to be satisfied such as external E-Stop which you should always provide as a physical mushroom somewhere.

If you're using CIP Safety, you cannot use any X11 connections.

that depends on type of KRC4 controller:

if it is compact or small size type 1, there is nothing to do.

otherwise you need to unplug network cable from CCU to SION_SIB. optionally you can also unplug power to it. and you also need to remove that board from WoV project.

Quote from Nishant Gajjar

If you need to know anything else

1. i know you are struggling but i am not here to pick you up. why don't you do everyone a favour and read pinned topic READ FIRST and search forum on previous discussions on KRC4 ProfNet setup? i tend to get bored and usually loose interest after 3 replies. this is my 6th reply to same topic and there is still no end in sight....

2. what is your question exactly? when asking for help, be specific. don't use vague statements such as:

Quote from Nishant Gajjar

an error saying communication between the PLC and the robot couldn't be established

that was exactly what i mentioned how NOT to ask for help. you are not stating what generated the message (where EXACTLY did you read it) and you are rephrasing it using own words. again, read READ FIRST and ask the right question.

3. why are you addressing me specifically? why are you rejecting help from other forum members? read pinned topic again. (it is in signature, below each of my posts).

4. i have not used it so cannot help you with EFI side, but as i recall there is plenty of documentation on how to set this side up. on the robot side your settings look ok, assuming you did IO mapping, KLI setup is ok etc.

5. there is nothing about ProfiNet setup that i wish to share beyond what is already on the forum. feel free to explore...

I'm not positive, but am pretty sure that the Sick profinet gateway does not support communication via ProfiSafe.