My question though is if the BINPICKING_TPV() is running on SPS.sub, how does the program know to reset if it gets stuck inside BINPICKING_TPV()? I thought the interpreter could only process what it's currently executing plus the advance run. Is it able to continue checking SPS.sub, or does this only get checked after you've finished running through BINPICKING_TPV()?
That's not how this works. The SPS runs in the Level 0 interpreter, and the "normal" programs run in the Level 1 Interpreter. Each interpreter can issue $CMD Run/Cancel commands against the other interpreter, but not against itself.
So when the SPS is triggered by some event to issue a $CMD RUN for BinPicking_TPV, that program gets loaded into the L1 Interpreter, and runs there. It is not run as a subroutine of the SPS, and if BinPicking_TPV gets hung waiting for something, the SPS keeps right on going.
(or should -- a well-written SPS has no WAIT statements or "blocking", but runs as a state machine. A badly written SPS could be written in such a way that a WAIT in the BinPicking_TPV program could cause the SPS to hang)
However, there are a few caveats: $CMD RUN does not actually start program execution -- it works more like the Select button on the teach pendant. The robot must still receive $EXT_START (for EXT mode) or have the start button on the pendant pressed (T1, T2, AUT modes).
Also, issuing a $CMD RUN when the interpreter is already occupied won't work. That is why the example program uses $PRO_STATE and other $CMD commands, in proper sequence, to first Cancel the current program in the L1 interpreter, then load BinPicking_TPV.