Global request. [PickMaster 5]

Hi again,

I am using PM5 since last week on a real robot an I can tell that it is not so easy to get it works correctly. There is always something wrong. I want to share some of my issues and try to get answer if needed.

1/ The robot is waiting for product to pick, we sent a stop flow but the robot does not stop he wants to finished a pArck place cycle before he can stop. Why? Is it due to the fact that the robot has already ask for product or is it due to a bug?

2/ We are using a gripper instead of succion plate to pick the boxes. But for the slipsheet we are using retractable succion cups. I can tell you that it was not easy to get it works correctly because PM is placing the picktarget in the middle of the carton acording to the tool center point but in our case the tool center point is not in the center of the gripper but we still want to pick with the mechanical gripper in the middle of the carton. It would be really intressting to have the possibilty to adjust the grip location of the pick separalty to the grip location of the place like in PM3.

3/ I have still some troubles between the pick and the place. I explain, we have 2 differents pick positon one for the box short side leading and one for the boxes long side leading. This will mean 2 different infeeders. See layout in attach. Infeeder 1 is for the boxes in short side leading and infeeder 2 is for the boxes long side leading. Between infeeder 2 and outfeeder 1 no problems. But for infeeder 1 and outfeeder 1 I have some orientations problems. I have try a lot of things in the PM configuration to avoid this but the problem is coming from the calculation of the intermediate point. The intermediate point makes the robot rotate on axis 6. I do not now why it is needed to rotate 360A? between infeeder 1 and outfeeder 1. I have for the moment solve the problem by forcing the orientation all the intermid points. Can somebody tell me why is it wrong, is it a problem with my references?
webwiz/622/layout_1.GIF

4/ An other problem is the first place position of each layer. For the 5 first layers it is not a big issue but for the next layer it is really a problem. I explain, when the robot is placing the first row of boxes on layer 6 we see the robot moving to the calculate intermid3 point and then moving up in Z direction before placing the box, it look likes that the first box is palced without regarding if there are already boxes placed on the layer 6 (for the first box I can accept that but why is the robot going up then?) but this is not the biggest problem the biggest problem is that the robot reach the boxes palced when going to the next pickposition. This happend only for the first boxes placed of layer 6 and 7 but I think it happended on each layer. What can I do for this?

To be honest, I think that PM5 is really good and easy to use if you have a succion plate but in our case we have a complex gripper that’s make me loosing my hair when using PM5.

BR,
Fabrice

some comments/suggestions to your list, maybe other users can contribute on these interesting subjects too.

  1. How fast the robot will stop will depend on the selected stop option. You can use stop option “Stop immediately”. This will stop the flow and the robot movement immediately. This stop option will also put the flow in error state, i.e. before restarting the flow you must first specify a flow recover action, e.g. continue pick/place.

  2. In PickMaster 5.10 it is a little more tricky to use some types of mechanical grippers than it is to use a gripper having only suction cups. It is almost always possible to find a solution in the end, but some special adaptions is needed in rapid and/or the project configuration. Maybe some good practice can be posted on the forum? You can expect improvements in this area in future PickMaster releases. I definitely agree on your remark that it would be good to have a possibility to configure a separate grip location for pick and place. If you (or anyone) have more requests/ideas for improvements in this area, feel free to post them.

  3. A general remark, the movement of axis 6 for a 4-axis palletiser robot will depend on the usage of PmCalcArmConf which modifies the cf6 in the target confdata. The routine will favour tool orientations where axis 6 is as close as possible to the input value of cf6 which normally is zero unless a safe position is being executed. Maybe you have a reorientation from +170 to -170 instead of going the other way since that solution will be too “far away” from the preferred value.

  4. I did not really follow here. Maybe you can clarify ?

Best regards, Anders

Hi Anders,

1/ I want to clarify this point. I agree with you for stopping the flow when using the Flexpendant but when the stop signal comes from the PLC it is not possible to stop immediately. In our case the robot is not moving but waiting for products to pick and I think in this case we should be able to stop the flow but it does not works. Why?

2/ I will maybe come later on with other remarks.

3/ I will try to limit the reorientation values.

4/ For the first place position of each layer the robot is moving from Intermid3 point to approach point on pallet. But I think, in our case, that the intermid3 point is lower than the approach point for layer 5, 6 en 7. This will mean that the robot is doing a little up movement before placing the box. And when the robot is leaving the pallet to get the next item to pick he takes the placed box with him. This happen only for the first flight of each layer. For all the other flights I do not have this behavior. I hope you will understand what I mean. I have solve the problem now by changing the end offset. The robot is still doing this up movement but when leaving the pallet he did not reach the boxes. Maybe you have an other idea to solve this.

5/ New point, I have some troubles to pick the slipsheets. The robot is doing a search at the first time, this works ok. The next time when the robot is moving to the next slipsheet to pick he activates again the search function but on the wrong position (He did not start from the top of the stack). What could be the reason that the robot is doing again a stack search. I have activate in the config of the stack search each 10 layers. Wil this mean that the robot will search after 10 picks of slipsheet or will it mean that our next point coincide with a value that the robot should do a search again?
An other problem is that the robot is sometimes not waiting on the toolevents when picking the slipsheets. I have place in the format of the slipsheet in the “beforepick” area GInput should be for example 1 but the robot goes sometimes true this. When is this exactly controled? Is it in the approach point?

BR,
Fabrice

Hi Fabrice,

A couple of notes:

3/ Infeeder 1 and Infeeder 2 are located in two different main quadrants. That will probably make the joint 6 calculation to find a ±180 solution which forces the robot to take another turn. There are probably two ways to fix it.
a: Inspect joint 6 at the different picks and places and limit the angle in the calulation.
b: Rotate the grip location 180 degrees for the formats you use at Infeeder2.

5/ The first time the robot makes the search, it starts at the highest possible stack height and searches from there. If the level it finds the stack is lower than a number of sheets, it reduces the number of layers in the stack. If the next layer happen to be top layer minus 10 layers (or 20 or 30 or 40…) it will make a new search from that level. It is probably just a coincidence.

/Mats

Hello,

  1. From PickMaster 5.10 and RobotWare 5.12, the stop immediate is possible also to perform using the I/O interface. There is a separate desription in the User manual on the sequence, which is slightly different from the sequence when using “finish cycle” or another stop option. The sequence is also possible to do with PM5.04, Rw5.11 but there is a problems if the flow must be restarted without using a flex pendant. The stop sequence sets the flow in error state. Flow revovery must be done before restarting the flow and this function became available in the I/O interface with PM5.10, Rw5.12. With older releases the flow recovery must be done with the flex pendant app.

  2. I would not expect this behaviour. May I ask which RobotWare and PickMaster release you are using ? There has been an evolution of the intermid move solution.

/Anders

Hi,

1/ OK I will try this.

3/ a. I have try to limit the orientation form -180 to 180 without good result (still the same problem), I had no time to test more. I think that the reorientation limit is not enough because the robot is going between pick and place true 3 intemid point each intermid point allows a reorientation of +/-180A?. And in my case I see each intermid point rotating less
than 180A?.
b. Change the pick position is not an option because of the mechanical gripper. On the movable plate we have some fingers.

I have for the moment solve the problem by forcing the orientation at the pick with this 2 instructions :
Act.RobTgt.rot:=[0,-1,0,0];
Act.RobTgt.robconf:=[0,0,1,0];
I am using the same instruction for the 3 intermid points.

4/ The last RW and last PM. See backup of robot and PM in attach
webwiz/622/66Z-63075_Backup_20090520.zip
webwiz/622/Pickmaster_5_Backup_20052009.zip
I hope you will find somthing in the backups.

5/ I have test this morning again and one time it works fine the other time the robot is on his pickposition before the suction cups are completly out. (This result in suction cups crash)
I do not undestand why the robot is not waiting on his toolevent?

I have some new issues :

6/ Is there a simple way (in PM5) to let the robot move to home or maintenance position when the PLC sent a request?

7/ Why is the IO value value of the Format layout always changing when changing the tool location?

8/ It would be intresting to have the possibilty to export and import tool events.

BR,
Fabrice

Hi,

I have one point more.

Yesterday I have test the error handler for the search and I was a little bit surprise when the robot crashed in the feeder.

What happened exactly:

First of all I add a moveL instruction in the Error handler of the ERR_WHLSEARCH to be sure that the robot does not crashed in the stack feeder again.

CASE ERR_WHLSEARCH:
SearchError:=TRUE;
SearchPoint:=ToPoint;
MoveL Reltool(ToPoint,0,0,-1000),Speed,fine,ToolWObj:=WObj;
TRYNEXT;

After this the robot is trying to do the next instruction and get the error PM_ERR_PALLET_REDUCED while executing PmSearchAdjust.

In this error handler you raise the ERR_WHLSEARCH but if we look further in the program you do nothing with this error. I assume that this is needed to stop the execution of the robot.

We start the robot again without filling the stack, I get again the ERR_WHLSEARCH but the robot does not stop and continue the pick/place cycle. The second time that the instruction PmSearchAdjust is executed there is no error. This will mean that the robot operate the outfeed. If I had not add the MoveL instruction the robots crashed in the feeder.

Is this normal?

To solve the problem I have change the TryNext instruction by RAISE, this works fine. I can redo the search as long that the stack is not filled.

BR,
Fabrice

Hello Fabrice,

This behaviour occurs if you set the search stop height higher than the center point of the first layer in the stack. Then we cannot be sure that the stack is empty when SearchL returns ERR_WHILE_SEARCH. If you set the search stop height lower and SearchL returns ERR_WHILE_SEARCH, the PmSearchAdjust will instead detect an empty stack (after TRYNEXT, i.e. PM_ERR_PALLET_EMPTY and this error will be raised in the error handler (just as you did by switching TRYNEXT to RAISE).

BR Anders

Hi Anders,

This is correct the stop height in my project is 50mm. But I think I will keep it like this with the change of TRYNEXT to RAISE.

I have an other question is there any possibilty to execute the next approach point after placing a box and before the signal ready to pick? The reason of that is that I need to win some cycle time.

BR,
Fabrice

Hello Fabrice,

You cannot start the movement to the next operation before the position request trigger signal is set and target generation trigger signal is received. The reason is that the decision on which flow to operate and which infeeder to use not yet has been done. Using early request on the flow configuration will make the signal/decision come earlier, i.e before placing and no cycle time should be lost. However, If the feeding of the product is very slow, you could loose cycle time anyway. But if you know in advance where the robot will move, e.g picking is always made from the same work area, you could make your own special intermediate movement in advance, before operating the infeeder and then skip the regular intermediate movement, which migtht save some time.

BR Anders