We have 3 robots picking from a single conveyor. We are picking up to 6 times in a row and then doing a single place on another conveyor. Our conveyor speeds are high 500mms plus.
We are using the QuickAck on each of the picks and we are encountering a problem with only robots 2 and 3 which base frames are above the 2000mm set point in the function IsQuickAckOk.
The problem is that we get a “Wobj Not Connected” error message and we sometimes are not allowed to QuickAck, i.e. IsQuickAckOk is False. This really screws up our process at these high speeds. Is there anything that can be done to always allow a QuickAck??
It seems that the conveyor position roll over points that are above 2000mm is causing a problem. For example, we set all the base frames to be less than 2000mm and everything runs great.
There is no way to always do a QuickAck.
The process sometimes needs idle time to drop the workobject and the QuickAck isn’t allowed to execute.
First you have to make sure you are reading all conveyor baseframe distances (‘ReadCnvX’) when you start your project, preferably by calling that routine from ‘PickPlace’ before entering the WHILE loop.
The reason for your “Wobj Not Connected” error is that you are executing the QuickAck when it’s actually not allowed.
If you are still experiencing problems you need to increase the ‘SafeDist’ in the ‘IsQuickAckOk’ routine.
Mats,
I was expecting that we could not always do a quickack. But I had to ask.
Can you further explain why the system needs some idle time to drop the work object? Is this predictable? Can we program around it?
We do have the ReadCnv in the PickPlace routine before entering the WHILE loop.
We have increased the SafeDist variable in the IsQuickAckOk routine and that has reduced the Wobj Not Connected error, but it has not eliminated it entirely.
We are writing conveyor position and whether it was a quick or slow ack to a file to help us understand this. Conveyor position was read right after the get item target. This is our observation;
Rob 1 (first robot) has a baseframe of 1101.3mm. (1103 < 2000 so use 2000)
Conveyor Position = 623.619 - Quick
Conveyor Position = 805.569 - Quick
Conveyor Position = 987.078 - Quick
Conveyor Position = 1170.08 - Quick
Conveyor Position = 1335.18 - Quick
Conveyor Position = 1515.58
Rob 2 has a baseframe of 2225.4mm. (2225 > 2000 so use 2225)
Conveyor Position = 1662.6 - Quick
Conveyor Position = 1844.48 - Quick
Conveyor Position = 2009.82 - Slow
Conveyor Position = 1640.27 - Quick
Conveyor Position = 1669.23 - Quick
Conveyor Position = 1735.32
Rob 3 has a baseframe of 3337.41. (3337 > 2000 so use 3337)
Conveyor Position = 3120.56 - Quick
Conveyor Position = 5071.88 - Slow
Conveyor Position = 2322.98 - Quick
Conveyor Position = 2350.64 - Quick
Conveyor Position = 2416.75 - Quick
Conveyor Position = 2598.71
As an observation, everything runs really good if the baseframe is below 2000mm. Is this a coincidence or is there something to it? Can you explain how the acknowledgement works? Why is it so dependant on baseframe position.
Just a comment,
it is most likely a coincidence that it works when you do a quick ack for each item target
when the base frame distance is less than 2 meters. E.g. if there never are more than one scene available simultaneosly on the conveyor (due to short tracking distance when the base frame distance is reduced) a quick ack is always possible.
BR Anders
I agree with Anders, it’s just pure luck that it works fine for the first robot.
Each workobject is by default tracked the same distance as the baseframe distance. But, to avoid too frequent drops, we limit the tracking distance to minimum 2 meters.
When the tracking distance is reached, a drop of workobject will occur. During this drop sequence, no coordination to the conveyor is allowed, which is prevented by the synchronized acknowledgment (Ack triggdata in last TriggL).
Therefore the variable ‘SafeDist’ is there to use the synchronized Ack when approaching the drop distance.. This variable needs to be increased when tracking high speed conveyors.
I am still confused on the c1position. Some place it “rolls over” and starts counting at zero. I am assuming this roll over value is calculated from the baseframe, i.e. baseframe plus some value like 500mm.
It IS pure coincidence that rob 1 is working fine. We are actually sending distributed pulses to each one of the three robots. For example, 6 pulses to rob 3 then 6 pulses to rob 2 and then six pulses to rob 1. It just happens that rob 1 picks six and then the gap of 12 (time when pulses are sent to 2 and 3) allows the roll over to happen and we start counting from zero again. So we never exceed the 2000mm and are always able to do a quickack.
The question I have is on Rob 3, we have quickack’s for 3-4 of the six and then we have a slow. When this slow happens, it causes pick5 to be missed (high conv speeds). So we missed it with the GetItmTgt but it is still in the queue. I think it then causes a huge value to be placed on the next item that passes the sync switch, i.e. greater than 5m. This does not make sense to me. Of course, then we have a position that is at >5m which will be a slow ack when it gets to rob three and this keeps perpetuating. Why would this value be set at >5m when our baseframe is 3.3m?
c1Position goes to 2 meter or the baseframe distance. If there is no outstanding itemtarget, the workobject gets dropped and c1Position restarts at 0. If there is an outstanding itemtarget, it waits until the outstanding itemtarget is acknowledged before dropping the workobject and reset the c1Position.
It sound to me that you aren’t acknowledging an itemtarget, otherwise it should have been reset after the baseframe distance is running out, or you are looking at wrong position signal.
By outstanding I mean a popped itemtarget by GetItmTgt but no yet acknowledged, by either AckItmTgt or the Ack trigg event.
The c1Position is the currently tracked position of the conveyor. The item targets popped from the queue has an X-value offset related to this position.