I have been to many installs, some have standard programs which must be used, others do not. I was struck by this one standard years ago at a tier1 frame supplier.
CONST jointtarget jHome:=[[-48.11,-1.58,60,-0.01,32.72,-90.01],[9E+09,9E+09,9E+09,-169.572,88.8665,200.013]];This one was just a bit different than others because it had a positioner, or trunnion, as it is sometimes called. Nevertheless, this one part was what I had to ask about:I asked "What is that WaitTime for?" To which the reply was more or less "waiting for the IO to catch up." What? Well sometimes the robot got an initiate without having a valid group input for the style, it would still be 0, which would cause a fault in the CAllByVar which followed. OK, so we throw away up to .25 seconds every cycle? Multiply that by the thousands or hundreds of thousand cycles. Yes, it adds up. So what to do about this program? We do need to Wait, but not an arbitrary amount of time, but for a CONDITION to be met. This condition should be that the group input for style should no longer be 0. It may take .25 seconds, a half a second, or as little as .02 seconds. The condition may already be met, so no waiting is required at all.Wait times because there were no switches to indicate the position of the gun retract. That is no fault of the programmer, just poor controls design. And then they want to push us to get cycle time! Give us the darn switches so we can wait for the CONDITION to be satisfied, and then we can proceed. Not only that, but also, when something is stuck open/closed, we can handle it. Picture this scenario: No switches, WaitTime 1 as a result of poor controls, gun is stuck closed, robot takes off and things get damaged, line stops.So to sum it up, always look at how you can make your program waits CONDITIONAL, not based on an arbitrary time. A good system design will provide for sensors/switches that can indicate the states of moving things before we move the robot or take corrective actions/error handling so we do not crash.