I'm running into a rather silly issue that's proving to be annoyingly intractable. Basically, I'm changing between different tools, and each tool has its own Cognex camera. I have to allow ~60sec for the Cognex to boot up when the tool is picked, but I want to bury as much of that time as possible in robot motion time.
So, I created a Clock var and hit it with ClkReset and ClkStart as soon as the tool is attached. The robot moves back Home, then moves to a vision operation robtarget, and at this point I have a wait for the Clock to exceed 60sec. And when I tested this, it worked.
HOWEVER! After this test completed successfully, I left the robot overnight -- no reboots, no manual mode operations. And in the morning, when I tried running the vision operation program again, the robot got stuck on the wait for the Clock variable. It's as if the value of the Clock got reset or lost overnight. The Clock value shows as Unknown in the RobotStudio Watch Window (even when the test worked), and N/A in the pendant Program Data window, so I can't see what's going on. I've done a sweep of the entire program module to ensure that there's no stray ClkReset commands that might be sneaking a reset on me.
At any rate, I need a way to make this bulletproof. Either I need a way to make the Clock value bulletproof, no matter what happens between the Tool -Pick program and the Vision operation program, or I need an alternate method to determine that 60sec have passed since the tool was picked up. I've looked at CTime and GetTime, and my rough thoughts are to try something like:
PERS NUM PickTime;
! At tool pick
PickTime := GetTime(\Sec);
PickTime := PickTime + (GetTime(\Min) * 60);
! At vision position
WHILE (GetTime(\Sec) + (GetTime(\Min)*60)) < (PickTime + 60) DO
I'm sure this isn't bulletproof, though -- for example, if the Pick event was at 15:59:59, I've just created a wait time of an hour. Does anyone know of a good algorithm for handling this issue?