I had a rather simple question on how to program 3 separate mechanisms, to explain what I mean, I have:
If Object 1 = True and Count = 0
“Move1” etc.
ElseIf Object 2 = True and Count = 0
“Move2”/etc.
ElseIf Object 3 = True and Count = 0
“Move3”/etc
My counter resets when the object is removed from the digital input (sensor). If the program is executing Object 2, and I place an object at “Object 1”, it starts Object 1, instead of first finishing “Object 3”
The same occurs if I program an “action after palletization”, it always returns to Object 1, before going to “Object 3”
If I program 3 different “If’s”, the machine pauses after Object 1 is complete.
Any ideas? If necessary, I can post the full program tree. Thank you!
Probably you need to use a temporary value to store the reading from the input sensor and/or waiting until the current function or placement is finished.
Small tip: in logic you never need to compare =True or =False, but just “if boolean_variable” or “if not boolean_variable”.
For example:
# gobal variables
global robot_busy = False
global Count = 0 # (is this correct?)
########## Main thread ############
# local variables
temp_obj = [Object1, Object2, Object3]
If temp_obj[0] and Count==0 and (not robot_busy):
robot_busy = True
move1_thread # (is this a thread or is this a function?)
elseIf temp_obj[1] and Count==0 and (not robot_busy):
robot_busy = True
move2_thread
elseIf temp_obj[2] and Count==0 and (not robot_busy):
robot_busy = True
move3_thread
end
########## move1_thread ############
# do stuff
...
# finish process
sleep(1)
global robot_busy = False
Here’s a short example. By placing the switch monitoring in Case 0, we can effectively stop looking at the sensors, because we only care about their result when the Robot_step variable is = 0. We can then decide at which points during our program we want to care about the sensors. For example, if your process is sequential such that if Object 1 is executing, and needs to then do Object 2 and Object 3 EVERY TIME, we don’t want to care about the sensor status until Object 3 has finished executing.
We can use simple Assignment commands to control the value of Robot_step, and the Switch statement will then execute the block of code under the Case line that has the same value as Robot_step. So in this example, I have linked each case together by assigning Robot_step to the next value. This means I can be dropped into any point of the program, and will carry out all steps up to step 3, at which point I go back to Case 0, where I wait for the next sensor input.
Thank you very much. I’ve seen that my workplace often implements Switch/Cases as well.
Prior to your reply and my fooling around, I found that SubProgram’s also work, but I had to remove the subprogram’s within what I desired to run, and implement them manually; because you cannot call a subprogram within a subprogram.
So to explain what I have briefly now that works:
If Tray 1 = True and Counter = 0
Call Subprogram Tray 1 Unload
If Tray 2 = True and Counter = 0
Call Subprogram Tray 2 Unload
If Tray 3 = True and Counter = 0
And so that the robot does not to continue unloading an already unloaded tray:
Event
If Tray 1 = False (digital input sensor)
Counter = 0 (so that when someone removes the tray, the counter resets; so too for the other trays)
Thank you again for your help. I will experiment more with Switch and Cases going forward.
For what it’s worth you CAN call subprograms from inside subprograms, you just have to use script. It’s a little strange. I don’t know why they block it with the actual subprogram node.
Yea i noticed you cant have subprogram NODES nested within one another, I’ve been programming alot in Polyscope but did not know you can just use script to bypass that, is it that straight forward in your link?
//SCRIPT NODE//subprogram2_name()
and it calls that subprogram? Does it return to the 1st subprogram after or does it return to the main?
Yep it’s that straight forward. It returns you to the line the called the function, just like any other higher level programming language. So my example in the link isn’t the best showcase, since there’s nothing else in label1. Main calls subprog1, which calls subprog2. After subprog2 finishes, it returns to subprog1. Because there’s nothing else left to execute in subprog1, it returns to main, since that’s what called subprog1.
