I also encountered the same problem on KSS8.6.4 and KSS8.6.5.
And we must use hibernation mode.
Can someone help us?
Thx!
fail to see why one must use hibernation. why do you need it? some configuration (like roboteam) don't even allow it.
also i don't think KRC4 has any issues with it, usually it is the users that complain.
and if KRC4 could, it would complain about the users... for example not doing maintenance as bad batteries lead to problems (data loss, corruption, mastering loss etc.).
fail to see why one must use hibernation. why do you need it? some configuration (like roboteam) don't even allow it.
also i don't think KRC4 has any issues with it, usually it is the users that complain.
and if KRC4 could, it would complain about the users... for example not doing maintenance as bad batteries lead to problems (data loss, corruption, mastering loss etc.).
We are not an industrial application, and the operating mode is EXT.
The equipment needs to be powered off every day. If cold start is used, a brake test must be done every day (This is very unnecessary)
So we need to hibernate KRC4 and then cut off the power.
In addition, I think since KUKA has opened the hibernation function, it must have been tested. So I don't know what caused the current problem.
If cold start is used, a brake test must be done every day (This is very unnecessary)
That's only a question of comfort. Just do the brake test every day, and you have no problems. That's no reason to use the hibernate.
if brake test is used, it will need to be done periodically no matter what... even if controller is never switched off.
Err... OK, so what do you guys recommend as the "best" way to switch off a KRC4 contoller ?
I have a main cabinet and a secondary one with my Beckhoff which has a separate power switch.
Would this be a proper sequence for shut-down an start-up ? :
-Shut down control PC
-(once control PC is shut down) Switch off the power on the main cabinet
-Switch down the power on the secondary cabinet
And for start-up :
-Switch on the power on the secondary cabinet
-Switch on the power on the main cabinet (thus cold-starting the system)
I really don't understand why panic mode always has some stupid comment. most of his replies don't actually answer the question, they just express his opinion.
From Panic mode =
"That's only a question of comfort. Just do the brake test every day, and you have no problems. That's no reason to use the hibernate."
If Kuka didn't want hibernate mode, they would not have it. Its really frustrating reading this guys answer. almost every post he answers, but, says nothing.
But, yes we have issue with the following:.
Besides the brake test, and mastering (reference switch) to be done if power is lost. We noticed that if there was a power outage, or someone purposely shut off the power without going thru the shutdown procedure on the pendant, then the robot losses the program. Worst of all, the outputs to the gripper turn to off state, which is scary, as the robot could be holding a part = 260kg.
Is there a way to be able to retain the output state in this scenario? (power loss, or manual switch cycle of power)
From Panic mode =
"That's only a question of comfort. Just do the brake test every day, and you have no problems. That's no reason to use the hibernate."
This is not from panic mode, but from me. 
Don't blame him for my posts.
If Kuka didn't want hibernate mode, they would not have it. Its really frustrating reading this guys answer. almost every post he answers, but, says nothing.
from your profile i see that you are a 14 months old baby. should not be playing with industrial robots or using internet. also you are forum member almost as long as me - something does not add up.
maybe you have problem understanding. but do not worry, you are not alone. few others have also expressed similar sentiment. this is usually from people that do not have proper background, cannot read or communicate well, do not clearly state issue and related info, do not post link to specific post that they are quoting, confuse who they are quoting, etc.
so who knows what else you may be getting wrong?
and while there are handful of people who may not like what they get from me, my posts in forums are free. there are many hundreds that seem to be very thankful for my posts. at least few hundreds of them also decided to not just say it but endorse me (see reaction count). More than that, some thought it would be a good idea to promote me to a moderator position, and after that to an administrator. so you are in minority, get used to it.
btw. what are your contributions and who did you help? what are your posts? of the 38 posts you made so far, only 3 are showing. could it be that you are simply a disgruntled spammer? or one of those who keep deleting own posts because they are ashamed of their own posts?
about your actual interests - hibernation and understanding what i write:
KUKA controllers do support hibernation and yes there is a reason for that, but in my experience most people are better off without it. several KUKA option packages do not work with it (roboteam...). also cold boots are required when doing changes, upgrades etc.
case 1:
i recall visiting client where our service team was doing preventive maintenance and some scheduled updates. and one of controllers would no longer run the application after cold boot... it was the same program that was unmodified for over a year. client and our tech were getting nervous so i came to check it out. found out that crash was a result of bad programming. parts of the program were copied (but not correctly, parts in DAT file were not duplicated) so data used by message display functions was not initialized properly and in some cases it would fail. it would work if good program was run first (so good program would initialize it). but the client believed that our techs did something wrong. the reality is that problem was there for a very long time but it was unnoticed. if they did cold boot, they would find out much sooner. but contractor entered data manually or simply called good program first then run some tests and left. so problem was dormant until much later when the cold boot was done by our tech. by this time contractor was long gone. so both client and the tech were happy that i came by to fix it for them.
case 2:
all software versions may contain bugs. some are small and unnoticeable. but some bugs result in memory leak. this means that controller uses more and more memory over time. if that is the case, hibernation is the last thing you want to use. because with hibernation, system saves memory content, reboots then loads back the saved memory content. in other words instead of starting from same point on every reboot, reboots make no difference, your system is getting slower and slower. depending on type/size of the leak problem will hit you eventually (in days or maybe in weeks) and when that happens, unpredictable situations may arise.
but who am i to argue. i am sure no forum user will find this useful... because someone from your club may still think i said nothing.
Okay so besides all these counter arguments --> does any one ☝️ try to suggestion solution to the problem ??
As Slamcity ask - in case of sudden power lost - how robot output can be retain in Kuka controller - like the Fanuc / ABB robots - it does not lost program pointer or output retain their values ..
Yes , Hibernate does work - but not in the event of sudden power lost ..
Does submit interpret is a solution -- where program running keep update some array of boolean to track of all output state and running some logic to in the event of power lost .. robot - re run the critical IO section of output such as EAOT IOS.
what is the problem?
i see several people adding their problems into same thread but they are actually complaining about different things - one has issue with smartPad reconnecting, one has issue with brake test, one chimed in just to complain, and you are talking about output retaining values after reboot... that is way too much of diversity for a thread that gathered only 10 posts over two years.
this is typical noise surrounding questions masked as XY problem. obviously someone is doing something wrong.
i would suggest to stick with usual recommendations:
start own topic, describe problem sufficiently (software version, configuration), how to reproduce it and what would desired behavior be. one problem - one topic. then we can talk.
and if the topic does not get replies in a day or two, it is fair to bump it up. do not hijack other threads and do not insist on implementing your approach as a solution because it may not work. keep an open mind and consider responses. maybe your question is not understood. maybe there is not enough info. maybe you are pursuing certain approach (hibernation or whatever) when it may not be even needed.
Worst of all, the outputs to the gripper turn to off state, which is scary, as the robot could be holding a part = 260kg.
Is there a way to be able to retain the output state in this scenario? (power loss, or manual switch cycle of power)
This is a design issue. There's no way to ensure that the robot outputs don't change state -- even if the programming somehow prohibited it, simple power failures can happen, operators hit Program Reset, etc.
The gripper should be designed to mechanically latch, so that loss of signals cannot cause it to loosen. On the electrical side (assuming pneumatic valves), valving should be wired such that creating a dangerous condition (in this case, opening, or just loosening, the grip) requires a positive I/O action -- at minimum, each valve (grip and release) should require an active voltage to actuate, so that a loss of all signals (robot reboot, power loss, cut cable, etc) does not create a dangerous condition.
Likewise, the gripper needs to be designed such that even with a full loss of electrical and/or pneumatic supply, the gripper retains its grip.
