Linking errors are normally result of either target program not compiled or missing, for example due to renaming etc.
You have bunch of programs that have red X across icons. You should focus on those...
Linking errors are normally result of either target program not compiled or missing, for example due to renaming etc.
You have bunch of programs that have red X across icons. You should focus on those...
just follow the manual (SafeOperation - chapter 8).
if SafeOperation is not activated, you only need to worry about first two bytes of safe IO.
and the default is to keep the signals TRUE unless there is a trip.
And one thing about ProfiNet is that device name must match...
it should... your screenshot shows red banner on top of the smartPad so some safety interface is obviously defined...
do you have X311 jumper plug in the CCU?
did you activate safety configuration?
does deployed WoV project configuration match actual hardware and connections?
hermann meant StartUp Mode (IBN). that is always an option - as long as safety interface is defined. in other words one can move robot and do some setup even before safety PLC is present and programmed. btw, you are likely to need some safety outputs as well.
I am asking if PLC has to be programmed to be able to enable robot safety circuit RDC, KRC, Smartpad....and all starting cycle to enable robot move
Yes, PLC must be programmed - PLC to KRC communication need to be established, PLC IO module(s) integrated, safety task created and programmed...
Check SafeOperation manual. It details what signals are necessary / available.
If you are not using SafeOperation, you only need to focus on first two bytes worth of signals to and from robot.
you are free to declare own variables using KRL naming conventions.
but.. inline form motion instructions use specific format that is a subset of the above...
the position variable that is to be be used in inline form instruction must have a prefix 'x'. for example xHOME. also note that prefix is to be omitted when typing variable name in the inline form editor (you would only enter HOME, not xHOME).
on newer KSS versions one can also specify that point is a global point (global touchup must be enabled). then the point gets prefix gx instead of just x.
you only stated robot arm hardware version and WoV version, neither of which tells if your controller is capable of using this. also you did not provide info how you typed in the point name. as mentioned, prefix is to be omitted. if you declare point as gXPickClear then in the inline form editor you need to only type PickClear
don't blame robot. blame person that selected that configuration. each variant has its uses. buyer beware...
ok so PLC is safety rated but the input module SB1221 is not. this is just standard input module.
if you want to wire EStop, you need safety input module like 6ES7226-6BA32-0XB0
see pinned topic READ FIRST. all user documentation is on Xpert (KUKA documentation portal). all programs are application specific. the only part that is robot specific is MADA and that is already created by KUKA.
profisafe? this is not ProfiNet... the hardware you talk about is all EtherCat.
It looks to be complicated this Profisafe.
this is not ProfiSafe. ProfiSafe is done over ProfiNet. all of this is EtherCat.
It looks to be complicated this Profisafe. And not cheap if is needed CX 8090, EL1918, EL6910.
Versus X11.
Should I consider better conversion to X11 with standard SIB?
If you are comfortable with X11, stick with it. Using fieldbus requires different skill level. For simple cells that only have one robot for example, it makes sense to use parallel safety interface. For large system that would be not very practical. Using fieldbus is a better option. Choice of fieldbus and PLC type depends on selected safety interface.
There is any simple way for Profisafe E-stop?
If you want to use ProfiSafe, you need Siemens safety PLC, and related programming software. also your robot controller will need ProfiNet option. and PLC will need to have suitable safety rated inputs.
If you want to use CipSafety, you need AllenBradley safety PLC, and related programming software. also your robot controller will need EtherentIP option. and PLC will need to have suitable safety rated inputs.
If you want to use FSoE, you need Beckhoff safety PLC, and related programming software. also your robot controller with EK1100 and EL6695-1001. and PLC will need to have safety suitable rated inputs.
Attached three slides illustrate what i understand of using Beckhoff safety IO with KRC. I hope it is simple enough. The important part is to identify:
a) each network
b) master of each network
c) type of bridge
d) correct connection of the bridge.
Notes:
bridge connections can be swapped out if KRC already has safety interface (not using FSoE).
network topology as shown is simple bus (nodes just daisy chained). it is possible to make different arrangement using other or additional hardware.
some of the TwinSafe IO modules have built in logic. This may replace EL6910 (Depends on program size).
both EL6910 and EL1918 are Ethercat terminals
...
They are not independent modules.
Am I wrong?
pretty sure that part is correct.
they (EL6910 and EL1918) are inserted in a block with EK1100 coupler that allow communication between KRC and terminals in both directions.
pretty sure that part is not correct if you are thinking of Ek1100 with EtherCat bridge because that unit is normally slave to the KRC.
so EL6910 and EL1918 need to be placed next to PLC CPU (such as CX8090) ...or.... next to the EK1100 that is slave to the mentioned PLC CPU.
EL6910 accept analog input, which could serve for an E-stop.
i am not sure where that comes from. what do you mean by analog EStop? also, if i recall EL6910 has no terminals.
keep in mind that bridge can be obtained both through Bechhoff and KUKA. Hardware is the same but the firmware is not. whichever version you get, use the device description file from that manufacturer.
btw EL1918 is an IO block with safety inputs.it also can process safety logic just like EL6910. it too is just a terminal block that on its own is useless - it NEEDs some PLC CPU that will talk to it and to outside world.
as far as i know EL6910 is a safety controller ... and only a safety controller... meaning that while it can process safety logic... that is pretty much all it can do...
in other words it cannot communicate. It supports TwinSafe but knows nothing of fieldbusses (Profinet or EtherCat)... so it needs a PLC CPU to be the bus master. i doubt that it can do anything even with the local safety IOs without actual PLC CPU.
once you use fieldbus safety, all of the signals are available in the safetyPLC and you can do with them as you please. any safety inputs/outputs that you may need, now need to be part of safety IO of that safety PLC.
if you don't need external enabling switch, you force the relevant bit to true. if you do need external enabling switch (or 2 or 3 or 4...) you need safety inputs so you can wire them. then you would write safety program for your safetyPLC that suits your needs.
the fieldbus safety interface has more signals than parallel safety interface. this allows you to evaluate operating mode in a safety logic and enable robot(s) as needed. also you can select different safety tools etc.
ooops my bad... i missed that one, you are correct- all is good...
The X311 is used to handle/route some of the safety signals.
when using parallel safety interface. signals from X311 are connected to X11. (X11 has signals both from X311 and from SION-SIB-STD).
when using fieldbus based safety interface (CipSafety,PRofiSafe,FSoE), X311 signals are still evaluated (because they are always evaluated). And since they are present in the message from PLC, the X311 needs those inputs jumpered.