Summary
Programming feature: jump flag node that can be inserted in the program and then ‘jumped to’ using a jump to flag node.
What is it?
Other robot manufacturers have the feature jump flags that allows the program to skip to different sections based on input from sensors etc.
Why is it needed?
This would be a useful feature in addition to switch cases and if statements to aid in simple organisation of the program. Can avoid the use of nested loops and if statements. Would be simple to implement.
While not an explicit Polyscope Node, you can already achieve this functionality using a combination of Switch/Case and subprogram calls (or script function calls). Let your main program consist entirely of one large switch/case, and let sensors (possibly put in threads) set the switching variable. Each case can contain a single line, a Call Subprogram instruction. The only downside to this method is that subprograms cannot be called from within subprograms. (Not cleanly through Polyscope, anyway. You CAN get around this by calling a subprogram via a script line, and that will work for some reason)
This does not involve any nesting of loops or Ifs, and helps keep the structure organized, as you will be creating the “jumpTo” instructions as their own URP files. So if you needed to touchup “Gripper_Dropoff” or something, you just open that job, make adjustments, save the job, and reload it from within your main program.
The reason you don’t see Goto/Label commands like other languages is because it is not typically safe to assume you can jump around and execute different lines of code, because the robot may be in motion. I have limited experience with other industrial robots, personally, but our main robot technicians here configure programs the same way on them.
Here’s a brief example of what I’m talking about. You can use threads which monitor inputs to act as your jumping criteria instead of programmatically assigning “Robot_Step” sequentially. This is also a nice way of preventing undesired robot moves, as the Switch will only care about the state of “Robot_Step” after it is done executing the subprogram (which likely would end by sending the robot to some Home or Perch position.
Thank you for your response,
I have used the switch case structure with sub-programs like in your example before with over 100 cases and it worked well for what I needed. However, if I wanted to ‘jump’ within one of those sub-programs I would still have to use a loop and if statement and these structures could get quite complex.
Agreed jump nodes could cause unexpected behaviour but this just needs to be tested.
This might be closer to the behavior you are looking for then. Essentially, the subprograms label1 and label2 are your “Label” instructions and the script lines “lable1()” and “label2()” are your Jump instructions. These can be called from within each other as well.
To insert a subprogram without the “Call” instruction, first select the main “Robot Program” line and then click “SubProg” from the left panel. Then just rename it to whatever you want to type in to jump there.
That is exactly what I was looking for! Thanks for taking the time to explain this, and showing a great example too.