PF_Robot Return Values

All callback functions require you to return a value. Normally, the return value will indicate that the operation has completed successfully. (constant PF_CALLBACK_SUCCESS). The return value can be used to change how the system operates. The PF_Robot return values redirects the main process flow and provides different behavior depending upon the "use case scenario". Having different return values gives the developer the ability to control the Part Feeding process flow for different situations.

Let’s begin by describing each of the return values for the PF_Robot callback function -

PF_CALLBACK_SUCCESS:
When the PF_Robot callback function finishes and "PF_Robot = PF_CALLBACK_SUCCESS", the system will check to see if the next Active Part (desired part) is available in its queue. If the Active Part is available, then the system will call the PF_Robot function again. The PartID parameter that is passed into PF_Robot will be the part # for the Active Part. In the case where the Active Part is available, there is no need to acquire a new image or vibrate the feeder since the desired part is already in the queue. If the Active Part is not available, then the system will acquire new images for every part that was executed in the PF_Start statement. The vision results will be loaded into every part queue and the system will make a judgement of whether to vibrate the feeder.

PF_CALLBACK_RESTART:
When the PF_Robot callback function finishes and "PF_Robot = PF_CALLBACK_RESTART", the system will acquire new images for every part that was executed in the PF_Start statement regardless of whether there are parts available in the Active Part’s queue. The vision results will be loaded into all the part queues and the system will make a judgement of whether to vibrate the feeder. The main purpose of the PF_CALLBACK_RESTART return value is to force new images to be acquired, queues reloaded, re-judgement and re-feeding from the beginning of the main Part Feeding process loop. This return value is convenient when you want to acquire new images for every pick and place cycle. For example, if surrounding parts are accidentally disrupted during the pick and place, it may be helpful to acquire new images and refresh the queues.

PF_CALLBACK_RESTART_ACTIVEPART:
When the PF_Robot callback function finishes and "PF_Robot = PF_CALLBACK_RESTART_ACTIVEPART", the system will acquire a new image for only the Active Part (not all the parts listed in the PF_Start statement). This return value is particularly useful when multiple robots are sharing the same feeder. PF_CALLBACK_RESTART_ACTIVEPART can be used to prevent duplication of parts in multiple queues. The return value forces a new image to be acquired for only the Active Part and only the Active Part’s queue will be loaded. The queues for all the other parts listed in the PF_Start statement are cleared. This is best illustrated by an example.

Suppose that the feeder has one physical part type on its platform and two robots are picking up parts from the feeder. For this application, two parts are added in the Part Feeding dialog. Each part will have a different Robot #. Additionally, the vision sequences for each part will have a different vision calibration (since the camera is calibrated to a specific robot). Even though there is only one physical part type on the platform, two logical parts must be created (one for each robot). The PF_Start statement will include both part numbers. Vision is acquired for both logical parts and both queues are loaded. Because both vision sequences are locating the same physical parts on the platform, there will be duplication of coordinates in the queues. If robot#1 picks a part and removes it from its queue, the part will remain in the other robot’s queue. As a result, robot#2 will attempt to pick up a part that was already removed by robot#1. PF_CALLBACK_RESTART_ACTIVEPART is used to ensure that a part is only loaded into one queue. As a result, no special sorting and no special queue distribution is required. Please refer to the following section for details on how to program this use case scenario.
Two Robots One Part