Programming Overview

This section briefly describes the overall Parts Feeding programming code. Similar information will be presented in more detail in forthcoming sections of the manual.
For most applications, Parts Feeding is handled by the system automatically. The basic SPEL code for Parts Feeding is created for you. The code consists of SPEL+ functions called "callbacks".
Callback functions are user functions called by the system at runtime and are used to let your program know the following:

PF_Robot function	When parts are available to be picked from the feeder
PF_Status function	When status has changed
PF_Vision function	When doing vision operation with PF_Vision callback
PF_Feeder function	When doing unique feeder operations
PF_Control function	When something needs to be controlled, such as hopper, front light, etc.
PF_MobileCam function	When using a mobile camera and the robot needs to move the camera above the feeder to search for parts
PF_CycleStop function	When the Part Feeding operation is stopped

Some modification to the callbacks will be required to handle the specific requirements of your application.
Most applications will only require use of the PF_Robot and PF_Status callbacks.
Here is a brief overview of each of these callback functions:

PF_Robot callback Function
PF_Robot will be automatically executed when the feeding / vision operation has been completed and parts are available to be picked. In general, this is the location in code where you will add instructions for the pick and place operation. A simple Parts Feeding application only requires adding a few lines of code to handle the robot’s pick and place motion and gripper (mechanism grasp parts) actuation. When the PF_Robot callback ends, the PF_Status callback will start.

PF_Status callback Function
PF_Status will be automatically executed after each callback function completes. PF_Status tells the system how to proceed based upon the callback’s return value or PF_Status will notify the operator that an error condition has occurred. The error could be a system level error (like a robot over-torque error) or a Parts Feeding error (like the quantity of parts supplied by the hopper are too little or too much). PF_Status gives you the ability to decide how to handle error conditions. A simple Parts Feeding application does not require modification to the PF_Status code.

For more complex applications, the user may need to handle the vision processing themselves. In this case you will need to use the PF_Vision callback. Here is a brief overview of the PF_Vision callback.

PF_Vision callback Function
When the customer performs the vision processing of the parts feeder instead of the vision processing prepared by the system, write the processing required for the PF_Vision callback function. You will need to execute VRun to acquire an image from the camera and process the sequence that finds the parts, get the vision RobotXYU results, and add then add the robot coordinate data into the Part coordinates queue. A simple Parts Feeding application that processes vision by the system will not require you to modify the PF_Vision callback.
Refer to the following for further details.
PF_Vision

In rare situations, you may need to use your own lighting rather than the built-in feeder backlight. The PF_Control callback is required to control your own lighting. There might also be situations where you want to use your own hopper. Whether you are using Epson’s hopper or your own, you will need to control the hopper from the PF_Control callback. Here is a brief overview of the PF_Control callback.

PF_Control callback Function
PF_Control will be automatically executed if the system needs to turn on the hopper or if the system needs to turn on/off user supplied lighting. When using the Epson supplied hopper, you will need to uncomment the hopper statements in the PF_Control callback.

PF_MobileCam callback Function
PF_MobileCam will be automatically executed if the camera is mobile mounted onto the robot rather than fixed mounted downward above the feeder. PF_MobileCam requests the robot to move the camera over the feeder so that the system can process images. PF_MobileCam also notifies the robot that it is ok to move away from the feeder when parts have been found and added to the Parts Feeding queue. A simple Parts Feeding application that uses a Fixed Downward camera does not require you to modify the PF_MobileCam callback.

PF_CycleStop callback Function
PF_CycleStop will be automatically started if the PF_Stop statement is executed. This callback allows you to finalize any operations upon termination (like turning on/off outputs or moving the robot to a safe location). A simple Parts Feeding application does not require modification to the PF_CycleStop code.

PF_Feeder callback Function
When your device or part cannot be processed well by automatic feeder control, you can write the feeder operation in SPEL code using the PF_Flip command, PF_Shift command, etc. in the PF_Feeder callback function. In general, there is no need to write a PF_Feeder callback function.

All Part Feeding callback functions require you to return a value. To return a value from a function, you assign a value to the function’s name (for example, PF_Robot = PFCALLBACKSUCCESS where PFCALLBACKSUCCESS is a predefined constant which has a value of 0). Normally the return value will indicate that the operation has completed successfully (constant PF_CALLBACK SUCCESS). PF_Status tells the system how to proceed after any of the callback functions have completed or after an error has occurred. The system needs to know what you want it to do - continue, exit, restart etc. For example, you may want to set the return value to constant PF_EXIT to terminate the Parts Feeding operation after an error. For a simple Parts Feeding application, you can use the callback return values that are automatically generated in the code for you.
Please refer to the following chapter for further details.
Part Feeding Callback Functions
The next page is an overview of the pick and place program.