Hi Pros,
we are about to elaborate a program for a specific application and I was curious to see how you would handle the following production sequence.
We are looking at a project where the UR will be set on a table. It will continuously run a certain task on one side of the table deburing a plastic part in three different zones. Once in a while, the operator will be able to come in, on the other side of the table, to run a single part that we call the 'express part', because the first deburing pass was not correctly done or for a different part to be deburred immediately. There would be one express station where there will be one proximity sensor to tell the robot when an express part has been loaded. So the question is, how would you have a robot program, running continuously, deburing parts on one side of the table a jump to another section in the program when it senses a high signal from one of the proximity switch. We are running different model of parts to debur in the cell. Identification is made via Barcode reading.

Overall, the way we thought of doing it is to have subprograms containing deburing trajectories for the different part models. Then the main program loop simply alternate between the three normal stations and calls the appropriate subprogram based on the barcode reading. We also have a thread running which is constantly monitoring the express station sensor. In that thread loop we are monitoring change in the proximity sensor signal to see when a piece has been placed in the station and when it happens this changes a variable in our main program called is_express_rdy which is checked at the end of each loop to see if the robot needs to do the express station before moving on to next part. 

Any tips, or anyone else have a different idea?

@Tyler_Berryman
We have 5 different parts that we need to debur and we can identify each part (to see which model we are about to debur) using barcode reading.
So at the 3 'normal mode' zones, I can have any of the parts their. The robot will simply read the barcode on the part before calling the correct subprogram. Once in a while, an operator can insert any of the 5 different parts in the express zone for deburing as soon as possible. So when this happens, the robot needs to go do that part before continuing on production in the 3 'normal mode' zones. If when a part is placed in the express zone while the robot is deburing a part in the normal zone, it can wait until that part is finished before moving to the express part.

Does that make more sense?

@Sebastien Thank you for the explanation, this makes sense! 

I agree with you that the easiest way to get this program would be to use a digital input from a proximity sensor to tell the robot that the "express part" is ready for deburring. Other ways to do this could be to use a camera to locate the part. An external camera could be used to continuously looks for the part, or a wrist-mounted camera could be used to look for the part, but this option would add time to your cycle time since the robot will have to go to a snapshot position to see if there is an "express part". Not to mention that integrating a camera will be much more expensive than a proximity sensor. 

I think that running a thread to continuously monitor the state of the proximity sensor is the most logical way to get this done. 

Anyone else have any other ideas? @matthewd92 , @Grady_Turner , @Ryan_Weaver

@sebastien @Tyler_Berryman The way I would approach this problem is to use something like this inside the main program, you can then define the 4 sub programs that are required.  This would also not require the need for a thread to be executed.  This is assuming you would not do the express part until the current part is finished.  Allows you to resume operation once the express part is finished where you were.  You would need to have the program loop indefinitely, each loop of the program would only execute one subprogram.

switch currentStep
  case 0
    sub runExpressPart
  case 1 
    sub runPart1
  case 2
    sub runPart2    
  case 3
    sub runPart3
if expressPartSensor:
  currentStep = 0
else if prevStep == 3:
   currentStep = 1
   prevStep = 1
else
  currentStep = prevStep+1
  prevStep = currentStep #This allows us to resume where we were when an express part breaks in

@matthewd92
could idea! that make a program more neat than what we have right now!

@Loïc yes that would be a cleaner way to do it.  Thanks for the suggestion!