Something like the above program is runing.
You really should post not something like your code, but the exact code. 
Hi,
1) There is a system variable that dictates the default override value when enabling the TP. I think that this is set to 10% by default. $SCR.$tpenbleovrd
2) Your BG-logic checks if UO[8] is OFF, in that case it will set the override to whatever the PLC sends through the Group Input.
When you ENABLE the TP with the TP ENABLE SWITCH (note, this is NOT the same as the AUTO/T1/T2-MODE SELECTOR ), your UO[8] will per definition be TRUE, thus your BG-logic IF-condition will not be satisfied.
These 2 facts are probably the explanation for the behavior you are experiencing.
From the description, it sounds like a BG logic issue. I would suggest using condition handlers instead, but you can try to keep using the BG logic. I think the issue is that there is a race, of sorts, between when the controller changes the speed to 10% and when UO8 turns off. If the controller sets the speed to 10% before turning off the UO8 signal, then the speed will be set to GI5. You need a different set of conditions to prevent that from happening. For example, you could have it conditioned off of UO3 so that it is controlling the speed whenever the program is running (you could run into the same issue if you enabled the teach pendant while running though).
From the description, it sounds like a BG logic issue. I would suggest using condition handlers instead, but you can try to keep using the BG logic. I think the issue is that there is a race, of sorts, between when the controller changes the speed to 10% and when UO8 turns off. If the controller sets the speed to 10% before turning off the UO8 signal, then the speed will be set to GI5. You need a different set of conditions to prevent that from happening. For example, you could have it conditioned off of UO3 so that it is controlling the speed whenever the program is running (you could run into the same issue if you enabled the teach pendant while running though).
I was going to say exactly the same, it's likelly an issue with the temporitation of the signals.
The event triggered by switching the robot from Auto to Manual or enabling the TP is likelly occouring before the UO signal is updated, so the override is likelly put to 10% by the controller but inmediatelly afterwards, the BG logic loop is putting it to 100% again.
I neved tried to do this using the GI directly to write the overriide, I usually use the "Override select" function, there you can select 4 different speeds using 2 bits, it fits the major part of the applications, if this is not ennough, i suggest you to check this other signals instead of the UO8 as they are internal system variables that are probably updated faster than the UO signals.
$CR_AUTO_DO
$CR_T1_DO
$CR_T2_DO
