Binding Function

RFDAUTO

Binding ID

AUTOPICKER

Binding Description

Sockets Interface to Autopicker PLC

Purpose

This Binding is designed to communicate with an Autopicker (Material handling Robot) that performs two main operations: 1) picks up door slabs from a pallet feed lane and puts them away in a storage area grid and 2) Picks door slabs based on manufacturing orders for finishing. TagNet provides verification of exactly what door type is currently being handled by the Autopicker in either operation and communicates this to the Robotic controller via simple XML exchange. The Binding uses GPIO script and ADAM I/O controller to listen for trigger events as well as turn on stack light conditions as configured.  This function makes use of the power of TagNet UDA's and the ability to group those UDA's for variable content in the XML. 

Logic

Reader Operation at a given Autopicker robot is controlled by trigger events as configured in the Binding:

üThere are two modes of operation based on which Trigger input is provided. The chart below shows what 'Core' attributes are sent in the XML and what 'variable' attributes are included based on the UDA Grouping

1.When the Autopicker provides a put-away trigger (e.g. Input1), it instructs TagNet to perform a read cycle to scan the door tag and send a Put-away payload as configured. This tells the Autopicker what Item # they have so it knows which stack location (x.y) to put it away to and also what antenna saw the tag (on all 4 corners of the door). This dictates what the orientation of the door is when picked up so the autopicker can rotate/swivel as necessary before loading onto a storage pallet. See example below of Antenna naming convention

2.When the Autopicker provides a pick trigger (e.g. Input2), it instructs TagNet to perform a read cycle to scan the door tag and send a Pick payload as configured. This again confirms to Autopicker what Item # they have and where the tag is on the door. The Barbaric System then sends back to TagNet the PDI for that picked door as detailed below.

üThis Binding makes use of a PDI concept which stands for Production Data Input. This is basically a unique identifier that relates to order configuration data waiting to be associated with a door blank. When the door is picked, the PDI is sent from the backend system (in the XML response) that instructs TagNet to retrieve that PDI data and link it to the actual TagID of the door picked. This now becomes a made-to-order product that will instruct Robotics further downstream in the manufacturing process of what operation to perform by passing UDA's at key workstations.

üIMOVE rules are applied are the very end of logic only if enabled.

üSupports full GPIO script as a result of standard MATCH / NOMATCH / ERROR / NOTAG variables. Shown below is an example script that enables listening on two tripper inputs as well as outputting to signal lights indicating which trigger was received.

Restrictions

None identified

Comments

This binding can be tested with a AUTOPICKER_EMULATOR utility that will return a PDI value specified in a TXT file. Note: this utility uses Port 2500 and the IP address of your testing machine. So an example would be 192.168.1.140:2500 in the IP address of the Binding. Currently has issue when adding another binding such as the Event viewer

Files Updated

RFDLOCIN, RFDLOCIH (Insert), RFDTAGVS, RFDTGMAP, RFDLOCEX

Program Name

URI set to RFDAUTO

Binding Setup

Binding Properties

Email Notification

The email address to send binding specific alerts. Note: This overrides the default SMTP Recipient value under System Settings.

Antenna Triggers

Specifies the state of a Trigger that will initiate a UDA grouping payload (e.g. Antenna 1 trigger value sends UDA Grouping 1, Antenna 2 trigger value sends UDA Grouping 2).  Note: this directive should not be confused with the physical 'Antenna 1/2' as all antennas enabled in the physical reader profile are activated. Also note that UDA groupings are NOT required for this binding to function unless the Barbaric system wants additional info for customer specific reasons.

Dwell Time

This is the time period that TagNet will ignore further read events until the dwell period has expired. For example, when a tagged object goes through a read zone and TagNet changes its location state from A to B, the dwell period gives it time to move away from the read zone before it is evaluated again for another inventory move (i.e returning back through same B to A).  The dwell time should be long enough to allow the object to move away from the portal read zone but not too long that if it is brought back in the reverse direction it will be not be ignored. There are (4) dwell time options in the dropdown. 

ü[Global] indicates that if the Tag was seen previously at any TagNet Physical Reader its LRE (Last Read Event) will be taken into consideration.

ü[Location] indicates that only if the Tag was seen at a Physical Reader within the same Logical Reader group, will its LRE will be taken into consideration.

ü[Reader] indicates that only if the Tag was seen at the same Physical Reader will its LRE will be taken into consideration.  ** Future

ü[Antenna] indicates that only if that Tag was seen at the same Antenna on a given Physical Reader will its LRE will be taken into consideration. ** Future

Note: The LRE time is updated every time the tag is read anywhere unless it is specifically filtered out in the Event Subscription Binding.  Though the tag event will be logged, it will not be evaluated for any business logic nor will it update the LRE. This filtering is typically done so that downstream read zones will not ignore it because its LRE was updated (e.g. if the tagged object has a specific inventory state or attribute that precludes it from being considered for dwell based logic).

Terminate With

Indicates to receiving endpoint that XML document is complete. Allows for blank, NULL, CR (Carriage Return), EOT (End-of-Transmission char), LF (Line Feed) or TAB (tab to next column) making it flexible depending on the requirements of the interface. Note that NULL is used by the Barbaric AutoPicker

Inventory Movement Rules

In the example below, the Inventory Movement Rules are set to *YES. Refer to the the Binding Change for detailed explanations of each directive.