KRC4 Profinet Controller

Quote from robot-cnc

This PLC to replace X11, what settings need be made with TIA portal?

Those for Safety functions via Profisafe regarding input byte 0 and byte 1?

I'm a robot programmer, not PLC, but from what I recall, you need to import the correct GSD files for your KRC4 into TIA. These GSDs are in the WorkVisual directory on your computer. There are several to choose from, depending on the KRC4's configuration and ProfiNet driver version -- you may have to try more than one to find the correct one.

The KRC4 should appear to TIA as two "blocks" of I/O -- one Safety, the other non-Safe. The number of bytes the robot uses for the non-Safe ProfiNet is configurable through WorkVisual. The Safe I/O is fixed -- 2 bytes for basic ProfiSafe, or 8 bytes (I think) for ProfiSafe with SafeOperation. The first two bytes should be the X11 signal, IIRC, and bytes 2-7 should be the additional SafeOperation signals.

Quote from robot-cnc

Having Profinet and Profisafe, no I/O module needed as SM 1226 input or output.

Only the Safety PLC S7-1200F

not exactly... you cherry pick what you want to hear instead of taking what was actually said.

what SkyFire said was:

" If you have ProfiSafe, then no Safety I/O hardware modules are required between the KRC4 and the Safety PLC. X11 and X13 are replaced by ProfiSafe signals.".

what he said is true... but... you also want to have an EStop wired to this PLC and for that your PLC does need inputs that are safety rated.

and i don't care how the cell looks like, it will need to have some sort of operator safety (a door or light curtain or whatever). and that will need safety inputs too because you need to wire it...

you could cheat and just use S7-1200F without any safe IO or safety devices... it would make it possible to configure system so that robot can run in full auto without operator safety or estop... but that is illegal and you would be violating safety standards and be the one responsible for any outcome.

you REALLY need to stop messing with things you do not understnd, specially when they involve safety - at least until you get proper training... and forum is NOT the substitute for formal training.

you are going to harm someone.

standard IO and safety IO are two different things (in fact VERY different) - they serve different purpose and are handled differently.

standard IO (aka gray logic) is the usual, cheap, plentiful, not safety rated and not redundant IO such as robot inputs and outputs. they can be manipulated any way you like and anyone is allows to mess with them as those are (in case of KRC) just SRC and DAT files...

safety rated IO (red or yellow) are safety rated and serve to protect human life. their signals are redundant, use monitoring, cross checking, etc. it is not enough to just "have safety IO". they also must be used in special program called safety task where you can program logic using special instruction set - safety rated and certified instruction set... once you start working with safety rated devices - everything need to be safety rated.

you are NOT allowed to mix safety and gray IO.

you are NOT allowed to mix safety and gray logic.

you are NOT allowed to map gray logic IO to safety inputs or use gray signals in safety logic.

the only exception is that you are allowed to copy state of some safety variable or I/O to a gray block of data (or IO) for the purpose of diagnostics. for example so that you know which of ten EStop buttons was pressed. this way you can display suitable message for the operator and save him some time so he does not need to go around the cell with 10 robots checking each and every button or safety device.

but... once the safety signal is cast into gray signal, it is a duplicate or clone of the safety signal... but... this duplicate is no longer safety rated and cannot be used in safety logic. and thankfully, WoV is trying to stop you from doing something really dangerous and stupid.

Quote from robot-cnc

I am trying to I/O mapping and cannot connect KR outputs with Fieldbus Profinet Safety outputs.

You don't do that. The Safety I/O are pre-mapped, and cannot be altered in any way. All you do is connect the KRC4 Safety I/O in TIA Portal. Each Safe Input and Output is at a fixed, permanent address, and NO customization is possible (or legal). You can write the Safety Program in your Siemens PLC any way you like, but the Safe I/O mapping is set in stone.

Only the non-Safe I/O can be remapped as you wish in WorkVisual.

as SkyeFire stated... on the robot side safety signals are already mapped and that arrangement is fixed. you cannot rearrange the safety signals and you should not touch them at all. the only thing you need to do on the robot side is create configuration that connects to PLC. since you only need ProfiSafe, there is no actual need for standard IOs - therefore there is no need for any IO mapping.

that was on the robot side.

on the PLC side you need to create network configuration compatible with KRC. PLC will be ProfiNet master, KRC will be PRofiNet slave. you cannot change the roles in this case since you are using safety.

in the PLC you need to map safety IOs and of course this has to match bit-by-bit the safety signals that KRC uses. on safety interface there are 64-bits in and 64 bits out. if you are not using SafeOperation, you only need to focus on first 16bits in and 16 bits out.

all signals from PLC to KRC will need to be TRUE for robot to move. so you can write code that simply keeps them TRUE all the time - except for EStop and OperatorSafety. there you need to add logic where those signals to KRC are set by PLC signals coming from safety inputs.

and safety inputs need to be configured correctly. not just to 'work' but to work correctly (redundancy and all).

in practical terms you will want your safety inputs configured and wired as at least 1oo2

no...

Master/Slave only tells who is managing network (data exchange).

this has absolutely nothing to do with what the actual signals and logic are or how they are used.

Think of the "Master" as someone responsible for maintaining a bus schedule. It keeps track of vehicles and their sizes (some busses could be bigger than others), knows the list of all bus stops and tracks arrival/departure times. basically it only organizes traffic.

It does not need to know or care who the passengers are.

so in this case

the buses are messages (some are bigger than others)

the roads are cables (all busses use same roads)

the nodes are bus stops (not every bus need to stop at each station)

the "Master" is just the extra duty (responsibility) assigned to one of the nodes. you can think of it as a central station, but really it is just another bus stop that happens to have added duty of managing traffic, instead of just being place where passengers can get on/off the bus.

bus service is just that - a service... allowing messages to travel around. what you do with messages is up to you.

so if you want to connect PLC and KRC, one of them need to take the role of a Master, the other must the role of the Slave.

KRC can act either as Master or Slave or both at the same time.

if can be master of few nodes that are local (tool control) and at the same time be slave to a PLC that manages entire shop floor.

PLC needs to exchange some data with robots... when to run.. what type of process to run etc.

but PLC does not need to be micromanaging everything that robots do. for example it does not need to know if Robot 24 has gripper open or closed. it can (if this is important to you) but normally it does not need to.

you need to choose which information is shared among which nodes. and you need to choose how each node handles information at hand...

but...

That is for standard signals (gray logic).

What robot cannot do is manage safety traffic... or manage safety logic for other nodes. for that you need a Safety PLC.

You can still have robot act as a master to some non-safe nodes. But when it comes to safe fieldbus, KRC can only be a slave.

in case of a Beckhoff PLC, the standard PLC is processing non-safe logic and managing all traffic (both standard and safety). but processing of safety logic is done elsewhere, in one of the block like EL6910 or even one of safe IO modules that have capabilities to process safety logic.

so what happens if the non-safe CPU responsible for organizing traffic stops doing that? what happens when safety messages are not delivered on time?

well, in that case, each and every safety node (every safe IO module) checks on its own if the safety message is on time or not. when it is not on time, each of them enters tripped state and shuts down.

Quote from robot-cnc

but since the PLC is master , robot slave...means the robot will be completly controlled through PLC....meaning using just as automatic external?

No. Master/Slave, in the context of ProfiNet/ProfiSafe, only means who controls the communication bus. It's entirely possible to have a ProfiNet setup where the robot is the Master, the PLC is the Slave, but the PLC is still controlling the robot in terms of when to start, stop, and what process to run. This is unusual, but possible.

For example, the signal $MOVE_ENABLE works the same way, in both the KRC and PLC, regardless of which unit is the Master and which the Slave on the ProfiNet connection.

Safe I/O is a bit more limited, b/c the Safety certification for a Safety Master device is much tighter than for non-Safe communications. So KRCs are capable of acting at ProfiNet Master or Slave, but only has a ProfiSafe Slave. But the same rule applies: if KUKA brought out a new version of the KRC4 tomorrow that could function as a ProfiSafe Master, the Safety I/O signals would still work exactly the same way. The only difference would be in the communication configuration in the PLC and the KRC.

Quote from robot-cnc

only automatic external possible if using Profisafe.

Not in my experience. Any robot must be capable of operating in T1 and AUT or EXT modes, at minimum. A robot that can only operate in EXT and no other mode would be nearly useless.

With ProfiSafe, the robot sends a different signal for each Mode to the Safety PLC. Typical Safety PLC Programs are written to allow the robot to operate in T1 even with the safety gates open or light curtains broken. But in AUT or EXT, none of those safety elements should be bypassed.

T2 Mode... well, everyone has different opinions on that, but an increasing number of users just disable it entirely.

E-Stops, of course, should work 100% of the time without regard to KRC Mode.

Now, a KRC cannot be switched between AUT and EXT mode at will. At minimum, there are system settings that must also be changed -- the setting of $MOVE_ENABLE being the primary one. To operate in AUT mode, $MOVE_ENABLE must be set to $IN[1025] (a special "always True" input), but EXT disallows this -- EXT mode requires that $MOVE_ENABLE be mapped to a non-Safe Input sent from the PLC.

But Safety does not limit the working modes of the robot -- I've used KRCs in all modes with X11, ProfiSafe, CIPSafe, it makes no difference. The critical factor is how the Safety PLC is programmed. It's possible to write a Safety PLC Program that bypasses all safeties, just like jumpering all the contacts on an X11 (this will get someone killed, don't do that). It's more work, but entirely practical, to write a Safety PLC program that manages Safety properly in accordance with the KRC Modes and the safety perimeter conditions.