I’m fighting an intermittent issue: 1105 / 1422 errors. This has been a reoccurring issue mostly on one Robot. I have a pair of Kuka’s palletizing layers. The error occurs when the Robot is at place, when the trap doors are opening (external axis).
Error 1105: $IN_POS_MA was not reached within the set positioning time $TIME_POS &
Error 1422: Read access to a variable that has not been initialized or has an invalid value $POS_INT
Is the one error a condition of the other or do I have different issues????
This has nothing to do with the thread you posted it to. As such, I have split this to make its own topic.
By your mention of "trap doors," I assume this is a Grenzenbach "layer-picker" robot -- probably a KR500 running with the Palletizing option turned on, and a huge box-shaped end effector with servo-driven "sliding doors" and rollers.
1105 occurs when an axis should achieved it's target position within a certain tolerance ($IN_POS_MA) -- normally it's caused by having the $IN_POS_MA value set too small. Or it could be something where the axis is just slightly blocked, not enough to cause a current error, but enough to prevent it from making the last fraction of a mm to its commanded position. The message should list which axis is the source of the error, but you don't mention it.
1422 is harder to explain -- it shouldn't be related to the 1105 error. On the layer-picker end effectors, the only interrupt I recall is the light-bar sensor across the bottom opening. This error shouldn't be able to arise from a hardware issue -- normally it can only happen from poor programming. Is it intermittent? Can you describe the circumstances where/when it occurs?
Thank you for splitting the thread!
KR470 - Trap doors, sliding away from each other when dropping a load and closing to pick another load. Small uhmw roller beds for the load to slide into when the doors are closed. Ploychain driven external axis.
The 1105 is occurring on the external axis when the Robot is at place and opening the doors. The doors are always in the open position when the error occurs. Sometimes we get a 108 error also.
One of the other issues was a Z-sensor, external axis outside software limit. We opened up the software window. Before we opened the window I would have to re-master the external axis to clear the fault.
1422 seems to be occurring when in the same position but doors are not open. The original design used a break beam across the bottom of the EOAT to determine the position of the pallet but I thought the original commissioning programmer removed it from the code. Now I use a 3D sensor looking down from the top when the Robot is a pick to determine the place position. does this make any sense?
Which external axis is the 1105 occurring on? You'll need to examine that axis closely. Running an O-Scope trace on the commanded vs actual position might also be a good idea.
The 1422 error is going to be entirely software-dependent. I don't know how this sensor is configured or used, or how the Interrupts were arranged to make use of it. But it sounds rather as if someone made a hardware change, but failed to 100% clean up the software that still relied on the old sensor.
First I want to say thank you for pointing us in the right direction!!!!!
Once we reviewed your response to the 1422 error we investigated the original cabling in the bottom sensor. The cable on Robot A had be tampered with. Someone screwed in the sensor just enough to intermittently cause the error. We disconnected the cable and have ran since 2pm yesterday W/O a internal fault!!!!!!
The external axis is E1. My partner has looked into the O-scope trace but we haven't done one before. Any tips?
Thanks again for the help!
Well, it's been a loooong time, and I don't have a KRC2 to check my memory against. But...
Monitor>Diagnose>Oscilloscope. Select "Configure". You'll need to enter a name for the trace, a time length for the trace recording, select the DSE as the data source, and select a recording mode (that part will be tricky).
In the "Values to Record" you'll have a list of options of what to record. You'll want to deselect anything besides your E1 values, probably just Following Error, Commanded Position, and Actual Position.
For recording mode... you should be able to set it up to trigger on an error, and record "back in time" by a certain percentage of the total time. That'll help you capture the events leading up to the error. You have to set up and select the O-Scope configuration by hand, but you can start it in your program by using $TRACE.MODE and checking $TRACE.STATE.