# System keeps exiting on a WaitTime command, err code 10125

**URL:** <https://tech-community.robotics.abb.com/t/system-keeps-exiting-on-a-waittime-command-err-code-10125/10769>\
**Category:** RobotStudio\
**Created:** [June 14, 2022, 11:38am UTC](https://tech-community.robotics.abb.com/t/system-keeps-exiting-on-a-waittime-command-err-code-10125/10769 "2022-06-14T11:38:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ktarabein](https://avatars.discourse-cdn.com/v4/letter/k/7feea3/32.png) [@ktarabein](https://tech-community.robotics.abb.com/u/ktarabein)\
**Post date:** [June 14, 2022, 11:38am UTC](https://tech-community.robotics.abb.com/t/system-keeps-exiting-on-a-waittime-command-err-code-10125/10769/1 "2022-06-14T11:38:12Z")

</div>

Howdy,

We are using an IRC5 compact controller and the system is exiting on a waitTime 3; command at random. It only lists 10125 which infers something to do with one of the stop commands, but we don’t use any and none of the Signal In/Out for quickstop are engaged at the time this happens. We used to have a stop routine trap triggered by a cyclic bool ,but we removed the cyclic bool. I only bring this up because I remember a year or so ago certain aspects of cyclic bools remained despite removing them and the removecyclicbool command wasn’t cutting it so we had to just delete the whole task and start over.

Any idea what is going on? Code is pasted below, with the WaitTime it ends the task on in bold. It seems very strange for the program to stop there at random. Has this happened before and do you guys think it may have to do with CPU or heat?

PROC StartMachineCycle()  
VAR num count := 0;  
Initialize\_1208;  
GSDRequest\_Homing:=FALSE;  
SetInternalDoorRequest:=FALSE;  
GraceShutdownCompleted:=TRUE;  
ISleep PauseCycleSignal;

IF bBufferWheelReplaced=TRUE THEN  
bDiameterFault:=FALSE; !Reset Fault Bools when buffer wheel is replaced  
bDiameterSensorFault:=FALSE;

AutoCal\_RunningSum:=0;  
AutoCal\_RunningAverage:=0;

FOR i FROM 1 TO 5 DO  
RecordDiameterSensor;  
AutoCal\_RunningSum:=AutoCal\_RunningSum+nCurrentBufferDiameter;  
AutoCal\_RunningAverage:=AutoCal\_RunningSum/i;  
ENDFOR  
BufferOn;  
for i from 1 to 5 DO  
count := count + 1;  
IF count = 4 PulseDO\PLength:=.5, DO\_34\_Polish\_Spray\_Nozzle;  
**WaitTime 3;**  
ENDFOR  
BufferOff;  
nLastBufferDiameter:=AutoCal\_RunningAverage;  
KnifeSharpened:=0;  
bBufferWheelReplaced:=FALSE;  
DiameterRunningAverage:=0;  
DiameterRunningSum:=0;  
ENDIF

IF (nLastBufferDiameter \> nMaxBuffDist) OR (nLastBufferDiameter \< nMinBuffDist ) THEN !If there sensor shows a distance that shows less than 2" radius left on buffer wheel, we know the data is false and throw a fault  
ErrWrite “Buffer Error”, "Bad sensor reading or small buffer: " \RL2:= “Check buffer enclosure for buildup”, \RL3:= “Possible issue WITH DAQ”, \RL4:=GetTaskName();  
bDiameterFault := TRUE;  
ENDIF

ENDPROC

Thanks,  
-K

---

<div class="post-metadata">

**Author:** ![lemster68](https://dub1.discourse-cdn.com/flex005/user_avatar/tech-community.robotics.abb.com/lemster68/32/1945_2.png) [@lemster68](https://tech-community.robotics.abb.com/u/lemster68)\
**Post date:** [June 14, 2022, 12:07pm UTC](https://tech-community.robotics.abb.com/t/system-keeps-exiting-on-a-waittime-command-err-code-10125/10769/2 "2022-06-14T12:07:46Z")

</div>

This seems unnecessary:

count := count + 1;  
IF count = 4 PulseDO\PLength:=.5, DO\_34\_Polish\_Spray\_Nozzle;  
**WaitTime 3;**

Why not:  
delete Count:= count +1;  
IF i = 4…  
WaitTime 3;

BTW Incr is better that count + 1

---

<div class="post-metadata">

**Author:** ![zsessenw](https://avatars.discourse-cdn.com/v4/letter/z/dc4da7/32.png) [@zsessenw](https://tech-community.robotics.abb.com/u/zsessenw)\
**Post date:** [June 14, 2022, 3:05pm UTC](https://tech-community.robotics.abb.com/t/system-keeps-exiting-on-a-waittime-command-err-code-10125/10769/3 "2022-06-14T15:05:19Z")

</div>

We have had one that would kick out of its program on random WaitTime commands and it turned out to be a broken solder on the CMOS battery terminal in the CPU. Check hardware log for a CMOS battery low voltage warning.