Discussion

Left ArrowBack to discussions page
SebastienSebastien Posts: 219 Handy
edited November 2016 in Applications
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?

Comments

  • Tyler_BerrymanTyler_Berryman Posts: 122Beta Tester Beetle, Wrist Camera URCap 1.3.0 Handy
    @Sebastien Are the three deburring zones linked to the same part or are there 3 different parts being deburred? 
    Sebastien said:

    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. 

    From this sentence, I understand that you are deburring 3 specific features on the same part.
    Sebastien said:
    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. 
    And from this sentence, I understand that you will be running one deburring program for a specific part. Could you clarify this part of your question and so I can get a better understanding of your application? 

    Thanks!
    Tyler Berryman
    Robotiq Integration Coach
    [email protected]
    1-418-380-2788, option 3
  • SebastienSebastien Posts: 219 Handy
    @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?

  • Tyler_BerrymanTyler_Berryman Posts: 122Beta Tester Beetle, Wrist Camera URCap 1.3.0 Handy
    @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
    Tyler Berryman
    Robotiq Integration Coach
    [email protected]
    1-418-380-2788, option 3
  • matthewd92matthewd92 Posts: 931Founding Pro, Tactile Sensor Beta Testers Handy
    edited November 2016
    @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
    
  • SebastienSebastien Posts: 219 Handy
    @matthewd92
    could idea! that make a program more neat than what we have right now!

  • LoïcLoïc Posts: 22 Handy
    edited November 2016
    @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 I'm not familiar with UR but as you will finish a part before you'll start the express part and in order to make it easier, won't it be possible to do something like this :
    
    if expressPartSensor:
      sub runExpressPart
    else
    switch currentStep case 1 sub runPart1 case 2 sub runPart2 case 3 sub runPart3 if currentStep == 3: currentStep = 1 else currentStep = currentStep+1
  • matthewd92matthewd92 Posts: 931Founding Pro, Tactile Sensor Beta Testers Handy
    @Loïc yes that would be a cleaner way to do it.  Thanks for the suggestion!
Sign In or Register to comment.
Left ArrowBack to discussions page