this lesson doesn’t contain how to grasp the object after certain rotations of the table. Following this logic explained, the robot is grabbing the clyinder including the table (it seems like being stuck to the table). How do I change it to just grab the cylinder instead ?
Because to and from the table involve the same concepts, and the video was about the table itself. Good that you asked the question on how to pick from the table.
Hopefully, the attached layout steers you in the right direction.
All I did was modify the layout file of the tutorial:
Add another conveyor to layout and move it within reach of robot.
Turn off looping of robot executor, (Component Properties > Executor > IsLooping.
In robot program, copy and paste subroutine for picking and place parts.
In copied subroutine, remove statements used for picking parts from conveyor, but keep the ones for placing parts on table.
Modify the signal action for releasing part on table to have a True value to grasp the part.
Teach robot to place the part onto other conveyor.
In Main routine, add inputCounter variable of type integer.
At start of robot program, set inputCounter to 0.
Create While loop and use If-Then-Else statement that executes either pick and place from conveyor to table, or from table to other conveyor based on value of inputCounter.
If placing on table, inputCounter is counted up by 1 until it reaches 5, the number of horns/branches on table.
If picking from table, inputCounter is counted down by 1 until it reaches 0, thereby robot knows to place parts on table.
As you can see, all of this stuff was about robot programming not the table.
If the robot is picking up the entire table… check the detection volume of the tool frame being used for the grasp action. If the detection volume is too high, when the action is signaled the table would be detected, thereby the whole table would be grabbed. Since the parts are attached to the table (parent-child relationship) the parts move with the table.
If you attach your layout I can look at it to see what is causing the table to be grabbed.
I need to place up to six different parts on those horns (each process step some parts will be added). This ain’t a problem, but merging all six parts to one after the last process step is. Considering this situation I want to pick the assembled new object as one part after the last step with a robot and place it on a conveyor. Trying to find different ways to solve it were not successful.
I would need to see your layout; hard to visualize what you are trying to do since the parts on each horn are so far a part. If you don't want to share the layout then send it through VC support.
But if I had to guess, you are adding parts to each horn every step of the way, so after the last step you want the robot to pick up the assembled part. That is doable. I will make another layout that shows one approach… there are several.
Used Works library to create five parts and programmed other robot to stack those parts on top of a cylinder on a table horn.
In this case, the robot uses a detection volume and gravity direction that are very small to account for part size. Generally, you would adjust gravity direction if part below top of stack is being picked. You can test this by changing the volume size in Z-axis direction for signal 1 to 50! That is, yellow part is picked before green part.
Gravity direction is lowered to form a descending tree: the part below each part is its parent.
Connected IO between both robots to relay tasks, e.g. robotA 1 tells robotB when to start its stack process, robotB tells robotA when stack is done. This is done using IO 110 in both robots.
Modified subroutine in robot to pick the stack of parts and place them. This required the use of another tool frame, Tool2, because the detection volume size had to be increased to detect the bottom part of stack, e.g. 201mm in Z-axis direction. You can set the value to 200, but you will notice occasionally that some of stack is picked but not all of it, so 201 will avoid that issue.
And that’s about it. You, of course, would optimize the solution, so the robots better coordinate work. For example, robotA places part, rotate table, pick stack if there is one; robotB places parts to form stack, signals that stack is ready, waits for next rotation to make new stack, and so on.
The concepts at work here are basic, fundamental, and advanced:
BASIC
Signal grasp and release actions
Wire inputs and outputs, set and read IO values
Pick and place components using robot
Move base frames of robot to different locations in 3D world
Teach positions to robot using different tool and base frames
FUNDAMENTALS
Modify detection volume size for grasp action to pick intended components
Modify gravity direction for release action to place component and attach it to intended parent (component, container, or world)
Use While and If statements and routine variables to evaluate conditions for robot tasks
Use Works Process component to create different versions of same component and teach different locations to form stack
ADVANCED
Use different base (robot coordinate system) and tool frames for picking and placing components
Change base frame location during simulation to simplify robot positions
We can disagree about what is basic, fundamental, etc. It is just a list of what skills and knowledge were used to make the attached layout of this post in a relatively short period of time. The process itself of making the layout involved iterative tests using:
Halt statements in robot programs to stop simulation. This was done to test signaling of robots, and teach robots positions for picking and placing parts.
Changing the warm up time of simulation. This was done to quickly get the simulation to a desired state. For example, I used 2 minutes when I was teaching robotA to pick and place the stack because a) a Halt statement stopped the robot around 1:45, and b) the first stack gets to robotA around 1:40.
Terms:
robotA - robot that picks parts from conveyor to table, and picks parts from table to other conveyor
robotB - robot that picks parts from Works Process to part on table horn.
Let me know if you have any more questions about the indexing table and the tutorial. Hope this all helps.
Thanks for the quick response. The solution explained is coming close to the issues I have. Still I coudn’t find a solution. Therefore, I attached my model I’m working on so that you get an better idea of what is needed. Mainly the model describes an welding process where after step 5, the baseplate and the 6 blades should continue as one component. The robot is just grasping the baseplate and leaves the blades on the horns.
It generally goes a bit complicated when mixing Works library components with non-compliant ones… like in this case.
I’d recommend to stick with Works in this case and replace the Indexing Table with the one found under Visual Components -> Works. Then adding “Works Robot Controller” to all robots.
Then add Tasks to this Process in the right order, starting from the first station to the last and finally clone and connect the Process to all the stations. In order to turn the table, add necessary task calls to the other processes as stated in the tips below.
Finally some tips:
After creating the vanes in a process component, rename the created components with "ChangeID" task according to the names used when teaching locations.
After having all the components on the Works Process, you can merge them all with the "Merge" task.
Call MachineProcess task in order to rotate the table (change direction and the number of stations from the table's properties if needed). Note: before the table rotates, all stations have to call the same MachineProcess task in order to "agree" with the command i.e. table is waiting until all stations call the task.
Call RobotProcess e.g. for the welding to just run a robot program sequence named after the TaskName. Remember to add the TaskName to the Works Robot Controller.
For more details refer to the attached layout. You can also take a look for the "Indexing Table Layout" under "Demo layouts" in eCat.
P.S and if one really wants to stick with the original Indexing Table, Works Processes can be attached to the Horns and “WriteSignal” task can be called in order to rotate the table around. It requires some checking of the state of all stations or some timing in order to work as supposed.
Hope this helps and sorry for the late reply if you’re still fighting with this application!
