Binding Function

RFDPLC1

Binding ID

PLC_ROBOTIC_LOAD

Binding Description

Sends Part Tag Data to PLC

Purpose

This Binding passes an event payload to a PLC Controller (Socket Listener program) that in turn uses ladder logic or similar to manage robotics. RFDPLC1 communicates directly with the PLC gateway controller via an IP address. This Binding was initially developed for paint load use cases but can also be used for other robotic operations such as Stripe, Buff, etc.

Logic

This Binding function performs the following logic:

üCollects whatever tags are read during a given read event cycle from a given portal, and sends them in real time.

üSupports full GPIO script as a result of standard MATCH / NOMATCH / ERROR / NOTAG variables. Typically a sensor input is used to trigger the read cycle for the specified time period (e.g. 2 seconds) such as paint lines with post indexing.

üThe chart below shows what 'Core' attributes are sent in the XML and examples of what 'variable' attributes can also be included based on the UDA Grouping  This grouping name is then specified in [UDA Grouping 1] detailed below.

üMax Tags in read event cannot be > 6 (the max parts that can be mounted on post fixture), if more in read event cycle (because of signal bounce) then drops tags >6 with the weakest RSSI and does not update TAGVS (for those tags dropped).  The assumption is that the weak tag(s) dropped were seen upstream prematurely and will be seen again when the post gets closer to portal. This modified tag list (from PHLOG) will be now be used for the RFDHDSP logic so both systems are in sync.  Note: PLC side is already dropping more than 6 currently if received. Splits out 'Color Flag' tags from those of parts if the read cycle were to actually see parts in the same payload as the color flag (rogue tag read from upstream signal bounce). So if the Inventory type of tag is ‘COLOR FLAG’ then this will be included in separate XML payload.  However, in order not to confuse the post indexing logic (two) payloads for a single trigger event will not occur. Operationally, whenever there is a paint flag there will be (3) empty posts behind it, therefore the color flag read event will be held back and associated to the next empty post.  So in this case instead of sending an 'no tag' XML payload for an empty post the part tags read will be associated with the previous (correct) Color flag event.

üBoth PLC1 and HDSP use TAGVS as tag last seen entity (reader/antenna name level) to determine dwell. Note when multiple bindings used together there is a flag that is passed to each binding that dictates whether it is the last Binding to be processed for a given schedule and thus the last binding updates TAGVS at that time. With this in place there is no contention between PEVG and PLC1 or HDSP when used together as bindings associated with a reader schedule.

üOnce a robotic operation has been performed for a given tag (or tags) sent, the PLC has the option to send back to TagNet an XML [Robotic_Operation] payload of parameters there were associated with the PLC operation (such as Robot ID, Temp, Humidity, Color applied, etc.). This is detailed in the  Web API section found here.

Restrictions

None at this time.

Comments

This binding can be tested with a PLC_LOAD_EMULATOR that will return various reply states. Note: this utility uses Port 10002 and the IP address of your testing machine. So an example would be 192.168.1.140:10002 in the IP address of the Binding.

If triggered the dwell time can be removed

Files Updated

RFDTAGVS

Program Name

URI set to RFDPLC1. The Port # is variable based on what is agreed to by customer to nominate which Robot is consuming the event data.

Binding Setup

Binding Properties