Specifications & Requirements for Multiple Parts & Multiple Robots

• A maximum of 4 Parts Feeders can be used with 1 robot controller.

• Part Feeders cannot be shared between robot controllers.
  For example, two T/VT series robot cannot share the same feeder. If you want multiple robots to share a feeder then you must use an Controller which supports multiple robots on a single robot controller.

• A system can have any combination of feeder models.
  For example, a system could have one IF-80, one IF-240, one IF-380 and one IF-530 or any other combination.

• A maximum of 4 parts can run on the same feeder at the same time.
  When multiple parts are running on the same feeder at the same time, the parts should have similar physical characteristics. In other words, the parts should weigh about the same amount, have similar dimensions, be made of similar materials, have approximately the same surface area etc…. Every part will use its own unique vibration parameters. Consequently, a part’s vibration parameters should not cause other parts to fly out of the feeder.

• A maximum of 2 robots can use the same feeder at the same time.
  If you attempt to PF_Start a grouping of parts (i.e., PF_Start 1, 2, 5) and the parts are assigned to more than 2 robots, an error will occur.

• When PF_Start is executed, a single part or a grouping of parts will run on the feeder.
  If you attempt to execute PF_Start multiple times for parts that are assigned to the same feeder, a message (issued from the PF_Status callback) will appear indicating that the "feeder is already in use" and the second PF_Start will not be executed.

• When executing PF_Start with a grouping of parts (i.e. PF_Start 1, 2, 5), all the parts must be assigned to the same feeder Number.

• PF_Start a single part or a grouping of parts on a feeder.
  Each feeder that is running is assigned a unique controller task number. (See the table below.)
  The user’s application code should not use a task that has been reserved for the feeder. If a Feeder # is not being used, then its task is available for the user’s code. If you use the PF_InitLog statement for logging Part Feeding data, specific timer #’s is reserved for the system and should not be used in the user’s code. If you use the feeder control commands (PF_Center, PF_ConterByShift, PF_Flip, PF_Shift), specific SyncLock #’s are reserved for the system and should not be used in the user’s code. The Task Number, Timer Number and SyncLock Number are specific to the Feeder Number. (See the table below.)

  Feeder Number	Task	Timer	SyncLock
  1	32	63	63
  2	31	62	62
  3	30	61	61
  4	29	60	60

• The first part that is listed in the PF_Start statement will be the first "Active Part" (i.e., the first desired part). Selection of the next desired part is done with the PF_ActivePart statement. PF_ActivePart will be demonstrated by an example in a later section of this chapter.

• The feeding action (vibrations, pick area and supply method) is performed for the current Active Part. Every part that is listed in the PF_Start statement will use its own settings when it has been selected as the Active Part. For example, each part in the PF_Start grouping could have a different pick area if that’s what is needed for the application.

• The PartID that is passed into each of the callback functions will be the Part # of the current Active Part (i.e., the current desired part).

• Images are acquired for every part that is listed in the PF_Start statement and each part’s queue will be loaded with the vision results. Every part uses its own vision and lighting settings. For example, one part could use "system processes vision" and another part in the PF_Start list could use "user processes vision" - all parts use their own settings. Similarly, every part can use its own specific lighting criteria - front lights, no backlight, different brightness etc…

• The Part Feeding Log File (started with the PF_InitLog statement) will contain the data for all the parts that are running on a feeder.

• When multiple robots are accessing the same feeder, the user’s application code must use the PF_AccessFeeder & PF_ReleaseFeeder statements to ensure that the robots cannot collide. This will be covered in more detail throughout the chapter.

• Every part must be calibrated individually. Once again, it is assumed that the parts that are running on a feeder at the same time will have similar characteristics (size, weight, material etc…).