How can i use Zelio Logic PLC to control KR C2?

the Zelios are smart relays (low end PLC). you will be spending 5x that much on a gateway....

not sure what your goals are. i would just add I/Os to the robot and program everything in KRL. no need for small device like Zelio

both robot and Zelio have only standard IO (gray logic). neither of the two have safety I/O. so if application requires safety you need something external or use safety rated PLC with safety rated IO.

KRC has handful of safe signals but those are not programmable, they have fixed functionality that is locked in. you cannot change it - you just have to live with it.

Quote from Temp22

KUKA robot with a KR C2 controller. From what I’ve been researching, the Zelio Logic has two communication modules: Modbus RTU and Modbus TCP. However, the KR C2 uses Profinet and DeviceNet.

What options does this KRC2 have installed? KRC2s have DeviceNet by default, but ProfiNet is an add-in hardware&software option. Then there's the "advanced" DeviceNet option that adds additional bus cards.

Above and beyond that, you need remote I/O modules to connect to either of those buses to bridge between the bus and real-world discrete signals.

Quote from Temp22

So, to use the robot's I/O I'm gonna need this documentation? https://www.robot-forum.com/attachment/24694-krc2-peri-en-pdf/ or do you have any other tutorial you could share?

That document addresses the KRC2 Safety signals using X11. Using your DeviceNet or ProfiNet I/O each have their own manuals. The ProfiNet manual should be on the KRC's D: drive, under KUKA_OPT. DeviceNet has multiple manuals and discussions in the Forum archives.

Probably the cheapest and simplest way to connect two incompatible networks would be an AnyBus Bridge module. Be careful, though -- at least one version I ran into needed an expensive piece of configuration software before it was anything more than a paperweight.

Quote from Temp22

What do you mean by 'advanced'? I still don't understand how DeviceNet works.

Okay, short version: KRC2 "naked" comes with zero "hardware" I/O, and only a single DeviceNet port, built into the MFC card. That DN port can only act as a DN Master, but it's fine for connecting DN Slave devices like this.

The "advanced" DN option adds one (or up to three) LPDN cards, which each have two DN ports which can be configured as either Slave or Master. But you have to buy the cards and the software package, and KUKA no longer sells parts or software for KRC2s.

Quote from Temp22

So, we're exploring options to make them compatible, and I found that we could use Profinet with the robot,

Only if you buy that option. Buying 2ndhand robots, especially old ones, is risky. They're often stripped of any/all options and sold in minimal configuration. In the case of KRC2s, the only place to find parts or software is on the used market, and ensuring you have 100% compatibility isn't easy. There were at least two different "generations" of KRC2s, three different motherboard generations, and 2-3 generations of MFC/DSE/RDC. And that's just scratching the surface -- don't get me started on "special" versions like the Volkswagen customizations. Getting details from whomever is offering this robot for sale is vital. Or else you're setting yourself up for failure.

Quote from Temp22

Oh, I thought the controller would have some I/O pins. In the university lab, there was a Kuka arm with those pins, but it had a different controller.

Some of the KRC2 and KRC4 Compact series came with built-in I/O, but I believe it had to be ordered, it didn't come as part of the "bare minimum" KRC. Some of the small robots, like the Agilus series, also had a small number of I/O built into the arm itself, but it was quite limited.

Quote from Temp22

That's baaaaad. Do you have any advice so this doesn’t happen to me and I don’t get fired?

It's all attention to detail. Before you buy anything in this market, ask those questions. The good news is, Anybus still sells and supports these modules, so you should be able to ask them and get an answer.

As for the KUKAbot... I love KRC2s, I spent decades working on them, and I wouldn't mind owning one... but only if I could buy an identical unit to use as a spare-parts source. And I wouldn't count on being able to find advanced software or hardware options for sale.

On a related note, that Zelio "PLC" doesn't appear to have any sort of bus/network communications. And only a handful of simple relay-style I/O built in. And it appears to require a special programming cable and software to actually program it, though there's mention of being able to program it by hand from the front panel? Look at the tech documents: https://www.se.com/us/en/product/…-clock-display/

Also, that Zelio has no Safety rating. If you want to operate a robot without killing someone, you'll need to attend to wiring up the Safeties correctly, using Safety-rated components.

Quote from Temp22

Regarding the safety part, at first, i'm going to use the x11 port and a safety relay to monitor the e-stop and gates.

Gate and E-Stop need separate relays -- E-Stop disables the robot entirely, Gate only disables the robot in auto modes (AUT or EXT), but allows operation in T1 and T2.

Quote from Temp22

Thank you all for your answers. Now i'm convincing my boss to use couplers instead of that plc, it seems to be a lot easier that way.

Couplers? You mean I/O modules? That can work, if you plan to have the robot operate in standalone (AUT) mode, with no PLC managing the overall operation.

Quote from Temp22

I was thinking about that. The gates need to open to remove the pallet, but that doesn’t necessarily mean it has to be an emergency stop, and that might even damage the robot. To avoid that, there is a dedicated pin for gates on X11, right?

Yes. E-Stop has one set of channels, Safety Gate (also called Operator Safety or Safeguard) has a separate set.

Note: when the robot is in AUT or EXT, opening the Safety Gate circuit will have the same effect as hitting an E-Stop. So if you want to avoid that effect, standard practice is to use a standard non-Safety $IN input signal to have the robot pause before opening the safety gate.

Quote from Temp22

Yes, that's what I meant. I thought they were called couplers.

Depends. Many I/O modules are just that. "Couplers" are (at least, in my experience) bus couplers that are part of a "sliced" I/O, like the image below. The unit on the far left, with the RJ-45 and RS-232 ports and the status LEDs, is the Bus Coupler, and each "slice" to the right is a specific type of Input, Output, or Power module. The entire package together is usually referred to as an "I/O Module".

That said, different regions probably use different terminology for the same items, so...

fieldbus modules come in different varieties.

"fixed" fieldbus nodes include in same unit handful of I/O points and a communication module. this is handy when I/Os are distributed, but... it is more expensive since each and every node needs to have own communication module built in. this is specially not practical of you need whole bunch of IO points in one place. term fixed suggests that functionality as well as number of I/O points per module cannot change.

"modular" fieldbus module address this by separating IOs from the communication module. this way you get cheap IO modules. you can connect whole bunch o them to a single communication module. in this case communication module is called "bus coupler" it is used to connect (couple) plain IO slices that have no fieldbus awareness to a suitable fieldbus. IO slices are always the same regardless of fieldbus (easier to keep in stock). or when converting project from one fieldbus to another (say from DeviceNet to EthernetIP or whatever), you only need to replace single component - the bus coupler.

Quote from Temp22

Is that because it would stop suddenly when the gate opens? So, the best option would be to make the robot stop in a controlled manner before stopping due to the door signal?

Pretty much. "Stopping distance" and Stop Category (0,1,2) is an entire subject of its own. But as a general rule, it's preferable to avoid safety-stopping the robot while it's moving quickly too often. A Category 0 stop will slam the motor brakes on instantly and wear the brakes down. Cat-1 tries to use electrodynamic braking first to reduce (not eliminate) break wear. Cat-2 is not safety rated.

yes... every single stop for a robot (or whatever machine you control) should be programmed/handled (a controlled stop).

safety stops are not meant to stop or pause process. they are there to protect human life and limb... at any cost... even if the machine or robot themselves get damaged or destroyed.

if it "had to" come to a safety stop - it means someone did screw up...

and that is why some companies take it very seriously, they don't want their production to be run by or relying on screwups.

leaving on a coffee break does not constitute an emergency so it does not justify pressing EStop or tripping light curtain... normally this is all addressed by proper training but when users are abusive, one may implement modifications that require pass code or a physical key to recover/resume. this way when safety devices are tripped, supervisor or authorized employee will need to come out to confirm if use was justified and if any further actions are needed (training , process change, disciplinary actions for repeat violators who just want to use shortcuts...).

this is why keyed emergency stop buttons exist. you can use them any time - press the button and robot or machine stop. but you cannot release it... it may take 10min for person with the key and clipboard to arrive but the upside is that equipment does not get abused, operators are following procedures as trained, without taking shortcuts.

similarly, instead of acknowledge button, a key switch can be used. or if ack is on HMI, it may need an authorization code.

Quote from Temp22

I can imagine performing a Category 0 and 2 stop, but how would a Category 1 stop be done? Is it through programming or a dedicated pin? Is slowing down the velocity enough?

read the manual...

stop0 and stop1 are safety stops - you do not program them - they are "hardwired" into safety of safety inputs.

stop0 is normally performed when safety stop is triggered but malfunction or misconfiguration are detected. in that case robot applies brakes and motors are short circuited. this produces very violent stop and robot is in no way able to stay on programmed path. if initial velocity was high, robot may end up quite a way from programmed path. (like a derailed train)

stop1 is normally performed when safety stop is triggered but other than that system is healthy. in that case robot will try to perform controlled stop for about 1 -1.2 seconds (KSS version and KRC hardware dependent). it means robot is decelerating while staying on the programmed path... until the mentioned time of about 1-1.2 second is expired. after that system switches behavior to that of stop 0 (brakes applied, motors short-circuited so no control). if robot did not come to a stop by now, it will derail too, but - since the speed by now is reduced, it is not going to get too far from path.

stop2 is when programmed motion reaches target point (robot comes to stop and it is on path). this is NOT safety rated response.

it is also possible that malfunction occurs during stop. for example Estop normally triggers stop1. but in case of malfunction (motor or drive burns out, or X20-X30 cable is disconnected or mains power goes out or similar) that occurs short time after stop was triggered (shorter than this ~1sec.). for example this happens after 0.378 seconds then situation is changed and system is defective or in no condition to continue controlling motors (and staying on path). in that case stop is promoted to stop0 immediately. normally this would mean quicker stop but earlier "derailment". in some cases stop may take longer too - for example if the brakes have failed