Container Problem [PickMaster 3]

PickMaster
1

I have a place container with 10 positions. When the 10th position is filled, I set an output signal and the filled container is moved out of the robot cell and a new empty container is moved into position. I use the doQueueIdle signal from the work area setup. I check this signal everytime I complete a place. The doQueueIdle signal actually goes high when the 10th item is picked. When I move up from the place position, I use a Trigg to set a digital output. The digital output triggers a TRAP routine, which checks the doQueueIdle signal. This works 95-99% of the time. However, periodically the container will index out after placing the 9th item. The IRB340 will continue to pick the 10th item and place it into the missing container. It appears that the doQueueIdle periodically comes on prematurely. I have worked around this problem by using a counter. However, if the container is changed, the RAPID counter will need to be changed.

2

What you have seen is the behaviour of the rapid running one cycle ahead.

Fact 1: The doQueueIdle goes high when the GetItmTgt returns the last itmtgt of the place queue.
Fact 2: The GetItmTgt will return the next itmtgt right after the last one has been acknowledged, due to the Conc switches and that the prefetch time of the instructions is longer than half a cycle time.
Fact 3: The trap may be a little delayed, so when the signal is checked, the signal may already been set by the next cycle.

I suggest you try to use the trigg instruction TriggCheckIO and set up an event in the middle of the upstroke in the place routine, which checks the value of the signal. If it’s set, the trap is executed.

/Mats

3

Thanks for the reply. I believe that what I am doing is very similar to what you have suggested. Maybe there is a difference that you can point out to me.

  1. On every upstroke in the PLACE routine, I set a digital output (do) when I am 5mm from the endpoint using the same TriggL that the ItmSrcData{Index}.Ack is used. The do is set from a TriggIO that was defined at the beginning of program execution.

  2. I have an interuppt tied to the digital output that runs a TRAP routine. In the trap routine, I check the doQueueIdle signal. If it is set, I pulse an output to request a new carton (container).

Using the TriggCheckIO may be slightly better than what I have set up, but it seems to be very close to being the same. Maybe the difference is enough where the ‘look ahead’ of the RAPID will not affect the system. I believe that you are saying that there is enough ‘look ahead’ in the execution of the RAPID that when the robot is executing the upstroke in the PLACE, the program may have already executed into the PICK routine, performed the GetItmTgt statement, and therefore set the doQueueIdle.

Thanks for your patience as I try to understand the problem that I am having with this application.

4

Yes, the idea is the same, but when running the check in a trap routine, you will have a context switch, which may be delayed, and the check of the IO signal may be done when the robot already passed the last place point and the new place itmtgt is already retrieved i.e. the doQueueIdle is alredy set.
If TriggCheckIO is used, the IO check is made much earlier.

The big difference between the two different solutions is that the TriggCheckIO check is made on a much higher execution priority than a IO check in a rapid trap. This will make difference when running a high speed IRB340.

/Mats