WorksProcess & TCP

anon37562268 · July 9, 2018, 2:40pm

Hi.

I am use WorksProcess for moving around part with robots in a robot cell. Need to use a double gripper (TCP1 & TCP2) but cannot get the robot to pick with TCP1 and TCP2. Just the TCP1 or TCP2 and the flans.

Anyone know how to change between those two?

Thank you!

WilliamSmith · July 9, 2018, 2:51pm

Reference a different tool name in separate tasks. Like the attachment.

But do you mean you want the robot to pick two things and then place them?

Works-Different-Tool-Frames.vcmx (2.71 MB)

WilliamSmith · July 9, 2018, 3:03pm

Here is the same thing but with Pick and Place tasks. You can see that you can use the same task name in some cases, but the tool frames in the tasks are different. Serialization is used to make the robot pick both parts first before placing them. However, you can undo this by using “pick1,place1,place2” instead because the “pick1” task that is in the queue would not be defined to use the first tool frame of the DTool all the time (same task name, but different arguments).

In a nutshell, serialization in the Works Robot Controller is this:

Tasks are executed in order if they can be executed. What does that mean? If list is this: a,b,c. The logic is first try a, then b, and then c. If a cannot be done, executor goes onto b. If b can be done, execute b. If c cannot be done, loop back and try a. If a can be done, execute a. And so on.

In the attached layout, first Pick task references TCP1, and when it is executed, that task is added to queue in Works Robot Controller. Second Pick task references TCP2, and when it is executed, that task is added to queue in Works Robot Controller. Sorry for belaboring the point: the difference is the same task is being assigned to controller but with different arguments.

Works-Different-Tool-Frames-w-PickPlace-Tasks.vcmx (2.72 MB)

anon37562268 · July 10, 2018, 9:59am

Thank you very much for this info. it helped me alot.

I will need to pick up with the double gripper TCP1 before the robot leave on the same place with TCP2. Should I use Pick & Place for that?

What is the difference between using Pick & Place and Feed & Need ?

Thank you!

WilliamSmith · July 10, 2018, 10:45am

A Feed task will not be executed unless there is a corresponding Need task. For example, there is a need for ProdID 111, so a Feed task serving parts with a ProdID of 111 can be executed to service that request. If the ProdID was 222, the Feed task would stay in queue until there is a need.

A Pick task is executed regardless of need. Same is true for Place task, but a resource would need to have the part requested in the Place task in order to execute it. And no, you cannot use a Feed task with a Place task. It is either Feed and Need or Pick and Place… as far as I know.

What are you leaning towards? I can tell you that if you want to “prepick” parts before there is a need for them then you have to use a Pick task or RobotProcess task. Feed and Need definitely make life easier, but in your case I think you need to use Pick tasks to execute two picks before the robot moves away.

P.S. I have no idea how the multipick stuff works these days. In the past, the parts had to be super small and very close to one another. What I do know is that the resource does have logic to prioritize tasks, so if it knows something is close by or far away then it will make a decision based on a cost, e.g. movement, unless there are certain parameters in place, like reserve and LIFO/FIFO

anon37562268 · July 10, 2018, 3:22pm

Thank you again for your help.

I will need to first pick up frompos1 with the double gripper(TCP1) and when leave another part on the same pos1 with TCP2.

According to you I need to use Pick & Place or robot Process Task.

I tried to do it with Pick & Place, the same thing as you did but the robot do not move.

Can you see whats wrong?

Thank you!

V1_pos111_pos222.vcmx (3.13 MB)

V2_pick-and-place-pos.vcmx (3.07 MB)

anon37562268 · July 10, 2018, 3:35pm

Looks like I used the wrong line.

I used Tasklist but it should be SerialTaskList, my bad:-(

Thank you anyway!

msd · January 27, 2022, 9:33am

I have encountered a problem/bug when using RobotProcess: in a Works Process. If I change the item’s material with the Works Process (ChangeProductMaterial:) before the RobotProcess: it immediately changes back to the default material when the TCP grabs it. Is there a reason this is happening or is it a bug?

Thanks!

keke · January 27, 2022, 10:01am

Python in Works Process sets NodeMaterial and MaterialInheritance and not the component/geoset material. NodeMaterial is somewhat of a temporary material that overrides original material. And then when robot grasps the part the action script does something to the part that resets NodeMaterial or specifically the MaterialInheritance.

There are few ways to try to fix this. If you have access to modeling you can try the following. Make sure your products’ geometries use component Material (so clear all geoset materials). Then modify “OnRun” script on the works process that changes the material. Comment out the two lines shown in the image below and insert the new code line below the commented lines. This change makes process change component material instead of using node material. Component material is more permanent and it should not be effected by robot grasp action.

If you don’t have access to modeling then you could try the following. Instead of using ChangeProductMaterial delete old products and create new products (CreatePattern) with different base color.

And the best way if you are using newer VC versions is to replace works with Process Modeling. In PM there’s no problem like this for changing the appearance of a product.

-k