KCB is Control Bus... so drives etc are on it. if any single node has loose connection, bus will fault out. one thing i saw few times is loose connection at the data cable between KRC and RDC (X21-X31) due to missing O-ring, but the same could be on any of the KPP/KSP as well.
i would suggest to make fresh KRCDiag at the moment this happens and send it to KUKA Support. there may be things to check like firmware and software compatibility etc. Perhaps something need to be updated.
well how often you see it, is it easy to reproduce? what axis is this, what KSS....
KCB can be a problem but i doubt that it is KCB issue, it is was, it would be affect random things, not always the same brake channel and likely whole bus would stop.
to me it sounds more like tripped brake monitoring...(perhaps LED indication there is slower).
usual problem is brake wiring (loose connection for example) or toasted brake channel (overcurrent, for example).
as a test you could try unplugging brake from the drive, of course that axis will not be able to move since brake circuit is open but... open circuit also means no overcurrent which may help trace the problem to internal problem for the drive or external (wiring).
actually there is more to it. i did some tests maybe 2 years ago and CWRITE can start and run program without $EXT_START (checked on 8.3 and 8.5). drives are on and move enable is on, "RUN PROG()" does both select and start functions. also in this case $DRIVES_OFF did not work either. if i recall the only thing that did work as expected (and all the time) was move enable...
read manual for CREAD/CWRITE about selecting/stopping program
you can press START/STOP program manually or use these commands, does not matter what line of code instruction pointer are at.
code shared by Hermann is correct. it still uses EXT mode as usual but has added feature tht program can be aborted. if you select program again, it is automatically reset. the thig to watch with any of this is that you really really need to know what you are doing to prevent collisions (there is no BCO in EXT mode). in other words the safe return to home must be programmed and called after each abort. example is covered in KUKA training Programming3
LEDs are grouped next to feature they represent. LEDs close to brake channels tell about brke. those close to bus cable are for bus activity.
OFF = No power
RED = Bad
Flashing green = Trying, not there yet
GREEN = Ok
I recommend a
WAIT FOR TRUE
after RESUME, to prevent the advance run pointer to leave the sub-routine
why?
ISR does not need that. this should be added at the end of a subprogram that is aborted by RESUME.
Now that's a proper ambition for an engineer
Inspirational!! Thank you.
been there, done that 
you need to interpret error... which line of code it really is... line numbers in message and display rarely coincide with KUKA.
so clearly interrupt does get triggered but ISR is not exactly your regular program, there are some peculiar things about it to keep in mind.
btw. i see no instruction that should be a problem in ISR so you are doing something wrong in the main program, probably not initializing motion parameters since we stripped them out from ISR. also you need to ensure BCO before doing anything else anyway. are you sure you did?
here is an example of RESUME command in action. note that motion parameters are initialized and BCO is done BEFORE doing anything else (like using interrupt). since i did this in OL, i used jog speed as a trigger because did not want to bring variable display. i also display messages so you can check timestamps of each part. and interrupt is edge triggered... so the jog speed was already high (at or above threshold) so first it had to be reduced bellow 50, then increased to trigger the interrupt.
Juar check older discussions, this was posted several times.
Yeah, KRCDIAG is only on KSS 8.x.
KUKA has older versions too but they were not included as standard feature befor KRC4.
KRCDiag V1.x is command line utility created in 2005 and it runs on older controllers (Win95 and WinXP)
"pointer" here is an instruction pointer.
an example of pointer is a little arrow that follows program and shows you what line is being executed. but there are actually two of them....
the arrow you see on the HMI is a main instruction pointer which executes motion and few other things.
another is advance run pointer, it is a scout or GPS that runs ahead and gives clues for motion planner to compute path for robot. this is happing (and maybe it also executes few things so main pointer does not have to). if you think of a advance run pointer like a dog on a leash, $ADVANCE variable tells the length of the leash (0-5 motion instructions, other instructions are ignored). default is 3. so advance run tries really hard to be ahead... at least one motion.... which is good enough to have smoothly blended motion segments)... but once it is ahead, pressure to run forward and explore drops so leash is not always stretched to that permitted length.
if the pointers are in different blocks of code at them moment RESUME is executed, it is possible (and very likely) that program will crash and burn...
btw you can also declare signal and look at group of inputs as an integer. then you don't have to have all those IF statements before SWITCH.
it is also cleaner, your code does not seem to account for more than one input on at any time (missing cases in SWITCH?)
you mentioned reading manual but not specifying which one. i have several version of programming manual for system integrators for KSS8.5. one i normally refer to is V7 from 2019. chapter 11.10.5 has example with RESUME.
oh, and you should not use $POS_ACT_MES to check position. by the time program gets there robot already traveled some distance. use $POS_INT, even if instruction is processed later (you have there 1 sec delay), it will still tell you same position ... not where robot is now but where robot was when input was triggered..
based on what i could dig out, it looks like they do not have calibration procedure to measure tool. so one has to enter tool data manually.
parameter1-Parameter6 are tool frame (XYZ and three rotation angles). also regardless of units selected (metric or imperial) tool data is always in mm.
check pages 9-10
i did not see the subject, it did mention OTD DR... those are controllers from 2000 or so. sorry,i never used Daihen but judging by what search engines can find, links to manuals only show specs or catalog info.
that will depend on the type of the robot.
first of all, do your programs work otherwise - if interrupt logic is removed? this is easy to check and confirm if messages are result of something else or interrupts.
also your interrupt strategy simply cannot work for several reasons.
you can NOT use RESUME command with GLOBAL interrupt.
you are not taking care of advance run pointer.
you are using input 22 to trigger start of the search, instead of using it to end the search, so if the search is started robot would keep on moving and crash into target it looks for. etc....
that is the simplest and most common way to upgrade. it means no hardware changes on the controller and there is no leftovers, you just need to by things that are needed. connect resolvers of all external axes to new RDC.
when editing project EMD can be on either of the RDC, don't forget to link robot and KL kinematics and setup transform for your robot.
but ... who knows, i may be purposely trying to deceive from time to time. what if you are the lucky winner... 
yes... cascadable has two connections so it can be in the middle between robot and KRC. i think it may already have FSoE assigned as default...
just contact KUKA, there is a little utility that can reset passwords to default
