ProfiSafe communication error

not hard drive... i was not talking about servo drive configuration editor... when working with KSS8.2 there is no servo drive configuration editor - only newer KSS version have this. so when integrating external axis etc on a KSS8.2 one has to use a workaround - select and manual insert into project one of the drive configuration templates (known as "wagon driver configuration"). check Work visual help on this.

reading messages in order of occurence:
1. KSS00404, common message when safety related issue is present. this is just a catch all type of message, it is not detailed, other messages are meant to provide more info.
2. KSS00203, login as expert, goto menu Home>Config>AutoExtern, change move enable input to 1025 and this will go away.
3. 4. KSS00205 Software limit A2/A3. This does not prevent you from moving robot. If it did, mastering robot would be impossible. This will go away once you can move the robot (Assuming present software limtis are correct)
5. KSS11011, connection to PLC timed out, this will be there until you have connection to PLC. this does not trigger breaking reaction, it does not block motion or program execution.
6. brake test required is normal when SafeOperation is active. does not prevent you from moving robot.
7. KSS15004, I/O error in safe device. Suggests that some (unspecified) safety device has a problem. This message DOES prevent you from moving robot...
8. KSS00001 EStop... messages suggest that issue is related to smartPad EStop but this is not necessarily the case. this may simply be a result of safety error mentioned in previous messages.

This is as far as things can go based on interpretting screenshots or looking at archive. For further diagnostics collect KrcDiag and send it to KUKA. This will contain additional details such as hardware logs etc. Most of things in KrcDiag used for troubleshooting are proprietary and need correct tool/resources to parse. If you like you are welcome to read them too. btw, in KSS8.2 it is recommended to ignore first KrcDiag - just make second one.

I know you are eager to make it work... when dealing with complex issues i like to rule out software. so deploying clean image would be high on my priority list since:
a) this is pretty quick if you have right things at your disposal (USB recovery stick and good backup).
b) this replaces thousands of files and there is no knowing which of them could have been the problem. so replacing the entire image mcleans the slate and gives pretty good confidence that software side is fine (if one has good backup or clean image).
c) no hardware is needed.

If you do not have known good backup image of that robot, create one now (even if possibly suspect) then try restoring image from hidden partition.

if that still does not help, contact KUKA and ask them to prepare link for your KSS+software options.

if the issue still remains, it is likely that problem is in hardware.
you can try checking diagnostics screens and compare results to a known good values or reference. but this is hard and meant for insiders. the best and fastest way to proceed is to simply start swapping parts. this means need to have access for replacement parts or another KRC4. Note: in KRC4 everything is safety rated - smartPad, RDC, KPP, KSP, CCU... so technically anything could be the problem.

so if you have access to another robot you can try swapping parts.
easiest to swap is smartPad. but... read pinned topic READ FIRST on this... smartPad firmware has to match... Normally this upgrade/downgrade is automatic, just let it run and give it some time... but ... that is not the case on KSS8.2. so if the replacement smartPad is not from system also running KSS8.2 the only way to upgrade/downgrade is manually. and that is risky... you can end up with bricked smartPad.

Quote from xlyanyura

1. opened a basic project that was at work .

Doesn't make sense at all.

Go back to your old project located on robot when delivered.

you are still not sharing important details and my patience is also reaching limits. so lets try this one more time:

whatever direction you choose, you need to have a plan - and follow it. and you should keep track of things you tried and keep track of what works, what does not. there is no sense in repeating mistakes.

and if things reach dead end, start from scratch and confirm every step taken. chances are something was skipped.

also the order of steps matters.... it is pointless to work on auto-external signals if you still don't have I/Os working or cannot move robot because of wrong safety configuration.

and every step taken need to have a goal, reasoning and justification. this is essential for any plan to work. without that, making changes is just stumbling in the dark and blindly bumping into obstacles. and trying to do everything in ONE shot is possible but very unlikely to work - and you are fighting on too many fronts. try modular approach, solve things in smaller steps, then move onto the next one:

in AutoExternal configuration i would just make sure that move enable is set to 1025 and that's it. all other settings are irrelevant until later - after you have robot working.

i would not activate safeop monitoring until everything else is working fine. because this ties your hands and only puts more constraints that is more hoops to jump through. aim smaller, do it in steps.

you can also try to setup only standard IO connection - gain experience and get some response from PLC. then add ProfiSafe...

examples about having a plan:

3V coin cell battery is used to store CMOS ram settings. this is what BIOS uses to backup key hardware settings like memory timing, enabling of peripherals, etc. this is all low level (hardware) settings related to motherboard. justification to replace battery is fine but reasoning about expectations is wrong. this has nothing to do with application settings. this is not where IP address is saved (post #21).

also this is an English forum (post #32). as suggested in READ FIRST, language and screenshots in this forum should be in English. if you wish to use other languages, i can move this topic to Other languages. maybe you will have more luck there. your call...

about what to try next:

to provide help, one need to understand what you understand... and what you have shared. unfortunately - both are lacking...

the very first step of ANY networking is to ensure that nodes have compatible network settings and that they use correct ports. maybe you got this part right but i have seen nothing that CONFIRMS that.

ProfiNet connection must use KLI port and relevant settings are tied to virtual5 and one MUST use static addresses. Looking at KLI config i see that settings there appear typical/default. KLI is using static IP 192.168.168.205 and subnet mask is 255.255.255.0 so your PLC must be in the same subnet - subnet mask must be the same and IP address must be between 192.168.168.1 and 192.168.168.254 but not 192.168.168.205 because that is used by the robot.

screenshot in post #19 also shows same IP suggesting that your computer is also connected to KLI. (no other choice in KSS 8.2). but that also means you must be either using an ethernet switch, so that PLC can be on that same network... OR... you are constantly reconnecting cable to KLI port. are you?

if you are using Ethernet switch you should be able to PING both PLC and KRC from your computer. did you ever do this? what are the network settings of the PLC?

and what are the network settings of your PC? I often assign multiple IPs to my machine so i can talk to different things quickly. you may have the same thing on your machine - so you can talk to both PLC and KRC even if they are on different subnets and cannot talk to each other. so do not make us guess... tell us what you are really using.

and what are the settings of your Ethernet Switch? are you sure that it is not interfering with what you are trying to do? Is it even suitable for this application?

and that is just the first step....

as you can se it takes a lot of effort and digging though 30+ posts to piece things together. we should not need to waste time on basic things like this. this is exactly why topic READ FIRST exists. since you don't present data in an organized fashion, it is not easy to help which is why most have given up.

the very next step would be to decide role of each node and amount of data to be exchanged. since using ProfiSafe, roles are fixed - PLC must be master and KRC must be slave. also size of safety I/O is fixed to 8 bytes and device (slave) stack is enabled but size of standard data is not confirmed or matched. in one of the posts i saw it was set to 256 on the robot side. no clue what it is on the PLC side... or if PLC is even using safety IO... it MUST have a safety task in which reserved bits are set to TRUE. i still have not seen any sign of this.

Quote from panic mode

in AutoExternal configuration i would just make sure that move enable is set to 1025 and that's it. all other settings are irrelevant until later - after you have robot working.

Only the signal move_enable is relevant for moving robot in manual mode, when it is set to 1025 you have everything done regarding aut ext signals, until you want to use aut ext for production.

Quote from panic mode

i would not activate safeop monitoring until everything else is working fine. because this ties your hands and only puts more constraints that is more hoops to jump through. aim smaller, do it in steps.

This doesn't mean to uninstall safety operation, that means you should set it to inactive! That's just one mark in the configuration. So:

Quote from xlyanyura

I uninstalled 2 safeop ....

Wasn't intended by panic_mode. But should be ok.

You need a safe program on PLC that sets the safe outputs like e-Stop and so on to robot (see manual for profisafe). On plc you must use the FC for reintegrating the safe I/O's of robot.

Last week I spent some hours to do it, profisafe and profinet betwee siemens S71200 1214fc and robot from Mercedes. Tomorrow I can share the backups with you.