Rockwell Automation RFID
Basic Operation
An RFID system is used to store and access information contained within an RFID tag. An RFID tag is placed on
material to be tracked during the manufacturing process. As the item travels through the system, information can
be written to or read from the RFID tag. This information is pass to/from the Programmable Logic Controller, which
in turn can be used to track where an item is in this process or what may need to be done next in the process
based on the information contained within the RFID tag.
System Components
A basic RFID system consists of minimum of the following components:
•
Programmable Logic Controller (PLC)
•
Ethernet Adapter Card (For PLC)
•
RFID Interface Block
•
RFID Transceiver
•
RFID Tag(s)
•
Associated interconnecting cables
•
24Vdc Power Supply
Programmable Logic Controller (PLC)
The RFID Interface requires a PLC that has the ability to communicate over an Ethernet network using Control &
Information Protocol (CIP) via Class 1 or Class 3 messaging. Class 1 messaging is sometimes referred to as
Scheduled Communications or implicit messaging and Class 3 messaging is referred to as Unscheduled
Communications or explicit messaging; The PLC must support CIP communications over Ethernet for this to work.
Rockwell PLC’s that support Class 1 messaging over Ethernet are:
•
1769 CompactLogix Controller
•
1756 ControlLogix Controller
These PLC’s use RSLogix5000 programming software and have the ability to create and initiate scheduled
connections to devices over Ethernet by simply adding them to the controllers I/O tree. In order to add them to
the I/O tree, the software requires an Add On Profile, or whats called an AOP. This AOP contains all the
information needed for the PLC to create and maintain a class 1 connection to the RFID interface. RSLogix5000
versions less than version 21 requires that the user install the AOP manually. The Addon Profiles for the RFID
interfaces can be found at http://www.rockwellautomation.com/rockwellautomation/support/downloads.page .
These AOP’s will work with RSLogix5000 version 18 and above, but will not work with RSLogix5000 versions <18. If a
customer is using a version of RSLogix5000 less than version 18, then they will need to create whats called a
Generic Module connections. The information required to create a Generic Module connection can be found in
the RFID user’s manual http://literature.rockwellautomation.com/idc/groups/literature/documents/um/56rfum001_-en-p.pdf . The process for installing the AOP can also be found in the RFID user’s manual.
Rockwell PLC’s that support Class 3 messaging over Ethernet are:
•
1769 CompactLogix Controller
•
1756 ControlLogix Controller
•
MicroLogix
•
SLC-5/05
These PLC’s use either RSLogix5000 or RSLogix500 programming software and have the ability to create class 3
message instructions. Message instructions must be triggered in order to read and write data to and from the
RFID interface and are run as part of the program logic inside the PLC. Communications via class 3 messaging
requires more knowledge of how the data is structured inside the RFID interface and thereby requires more
programming skills and knowledge than using an AOP. On a scale of 1 to 10, where 1 is easy and 10 is extremely
difficult, using class 3 message instructions would be considered an 8, where using an AOP would be considered
a 3 in difficulty.
Ethernet Adapter Card
A PLC will need an Ethernet adapter card if it does not have a built-in Ethernet port. All ControlLogix processors
will require an Ethernet Adapter Card, some CompactLogix processors have a built-in Ethernet port, and the SLC5/05 has a built in Ethernet port. Depending on the PLC that the customer is using, they may or may not need to
add an Ethernet adapter card.
There are some standalone Ethernet converters (i.e. Serial to Ethernet) that will convert from a serial packet to a
TCP Ethernet packet. These devices will not work with the RFID interface because they send out and receive
standard TCP packets without embedding the CIP inside them.
RFID Interface
There are three different RFID interfaces that Rockwell offers:
•
56RF-IN-IPS12
•
56RF-IN-IPD22
•
56RF-IN-IPD22A
The RFID interface converts commands sent from the PLC to commands to be sent to the RFID tags. The PLC will
send a command down to the RFID interface, who in turn sends the command to the RFID transceivers who send
the commands to the RFID tag. The RFID tag will process the commands and send back a response to the RFID
transceiver. The RFID transceiver sends the response back to the RFID interface, who in turn sends the response
back to the PLC.
As of this writing, the current firmware version is 1.05. Technote 461897 keeps track of firmware releases and
changes for both the interface and transceivers. Flashing of the firmware is done using the ControlFlash utility.
Starting with version 1.05 firmware, when flashing an interface block, the Control Flash utility will also flash any
transceiver that is connected to it. If the interface sees a transceiver attached to it that does not contain the
minimum required firmware level, it will flash its channel LED on the interface block. This issue can be corrected
by merely reflashing the interface with the transceiver attached. Firmware versions and location can be found in
technote 495346.
56RF-IN-IPS12 is a Single Channel RFID interface with 1 discrete 24Vdc Input point and 1 discrete 24Vdc output
point. This interface block has only one RFID channel, meaning you can only connect one RFID transceiver to this
device.
56RF-IN-IPD22 is a Dual Channel RFID interface with 1 discrete 24Vdc Input point and 1 discrete 24Vdc output
point. This interface block has two RFID channels, meaning you can connect one or two RFID transceiver to this
device.
56RF-IN-IPD22A is a Dual Channel RFID interface with 2 discrete 24Vdc Input point and no output point. This
interface block has two RFID channels, meaning you can connect one or two RFID transceiver to this device.
The interface has two Ethernet ports, and either or both ports can be used. Two ports are provided in order to
allow daisy chaining of devices on Ethernet. This unit supports DLR (Device Level Ring), which is an Ethernet loop
configuration (all devices connected on Ethernet to create a ring network) as shown below.
The Ethernet ports are 5-pin M12 connectors that support 10/100MB, Half/Full duplex, auto negotiate, and can
handle up to 10,000 packets per second. The maximum cable length is 100 meters from port to port. Technote
468422 list all the cables and connectors to use for the RFID system.
The RFID Channel connector has a 5-pin M12 female connector, and is used to connect an RFID transceiver to
the RFID interface. The maximum cable length cannot exceed 100 meters (due to voltage drop).
It is extremely important that the cable used is the 889D-F5FCDM-Jx (where x is the cable length). This cable is
shielded and a shielded cable is required to prevent electrical noise from back feeding into the RFID interface,
which has been shown to cause communication issues over both the transceiver and Ethernet networks.
The Discrete Input Channel connector has a 5-pin M12 female connector, and is used to connect a field device
to the RFID interface. The maximum cable length cannot exceed 100 meters (due to voltage drop).
Two pins provide power to the field device (pins 1 & 3), one pins sinks power from the field device (pin 4), and pin
5 is the shield connection. This input can be used for a trigger into the PLC for Continuous Read Mode or as a
standard input. Maximum current rating is 5ma’s.
The Discrete Output Channel connector has a 5-pin M12 female connector, and is used to connect a field device
to the RFID interface. The maximum cable length cannot exceed 100 meters (due to voltage drop). Maximum
rated output current is 500ma. This output could be used to switch a gate or turn on a stack light.
For additional information pertaining to the specifications and installation of the unit, please refer to the
Installation Instruction Sheet which can be found here
http://literature.rockwellautomation.com/idc/groups/literature/documents/in/56rf-in008_-en-p.pdf
Technote 524594 can be used to calculate the maximum current draw of the RFID interface.
The Auxillary Power connector has one 4-pin M12 female connector and one 4-pin M12 male connector. This
connector is used to provide both 24Vdc power to the interface block as well as power to the Discrete Input and
Output connectors.
It is important to note that all pins must be used to provide power to the interface block or an Aux power Fault will
be generated inside the RFID interface block as well as a Module Fault. If the user does not wish to use the
discrete input/output points on the RFID interface, then they do not have to provide power to pins ¼ and
understand that the unit will always have a module fault bit set as well as the aux power bit set.
The female side is used to daisy chain the power to another device. The power connection is limited to 4 A.
When the daisy chain approach is used, the maximum number of interface blocks that can be connected is
determined by the total power consumed by each block. For further information, please reference the RFID
user’s manual.
RFID Transceivers
There are four different RFID Transceivers that Rockwell offers:
•
56RF-TR-M18 – 18mm Barrel
•
56RF-TR-M30 – 30mm Barrel
•
56RF-TR-4040 – 40mm x 40mm square
•
56RF-TR-8090 – 80mm x 90mm rectangle
The RFID transceivers are basically antenna used to create a magnetic field to talk to RFID tags. As the RFID tag
passes into this magnetic field, energy from the magnetic field is imparted into the RFID tag, which is used to
power its internal chips. Commands are sent from the RFID interface into the RFID transceiver, and then wirelessly
to the RFID tag. As distance between the RFID tag and transceiver increase, the strength of the magnetic field
being generated by the RFID transceiver begins to decrease. When the distance becomes too great, there is not
enough energy available to power up the RFID tags.
A transceiver creates a main field and two side lobes; the side lobes should never be used for applications. The
main field’s size and shape is dependent upon the transceiver style that created it. Applications should target
the main field only, which means that the tag should be located far enough away from the transceiver so that it
does not come in contact with the side lobes. In the picture shown above, the side lobes extend approximately
20mm’s from the face of the transceiver, which means the tag should be no closer than 20mm’s from the face of
the transceiver to ensure the tag does not enter a dead zone or an area where the field is weak. Dead zones
typically cause communication issues most notably a tag not present error. If the direction of travel is from left to
right and the tag height is <20mm, then as the tag travels the user will see a tag present, no tag, tag present, no
tag, tag present, no tag. This will cause communication issues when the user keys initiating a command based off
of the tag present bit because as the tag enters the first side lobe a tag present is generated. As the tag
continues to travel it will hit the first dead zone and lose the tag present signal. By this time the command is being
executed at the interface, which will see that there is not a tag present and report back an error 4 (No tag
present). For stop and go applications, the user could use a timer instruction to verify that the tag is present for at
least 1 sec (time needs to be based on users application) before initiating a command. This way as the tag
crosses through the dead zone and creates the tag present, no tag, tag present signal the timer will complete
once the tag stops within the field and generates a tag present signal for at least 1 second.
Stop and Go applications can use the entire range of the field, just keep in mind that side lobes exist. On-The_Fly
applications must never use side lobes and they should place the tag within the maximum field width of the
transceiver. In the picture above, the best location for the tag for an on the fly application would be
approximately at the 40mm location as the field is the widest at this point, giving them the most time available to
read/write a tag.
Angling or pitching a tag in reference to the transceiver is not advised as this reduces the amount of magnetic
flux that is being induced into the tag, thereby reducing the maximum tag to transceiver distance. Through
testing, angling a tag by <=10 Degrees has little impact on the tag to transceiver maximum distance. Anything
greater than 10 degrees can start reducing tag to transceiver maximum distance by 40%. Angling a tag by 90
degrees reduces the tag to transceiver distance to as much as 0mm. If angling a tag is required, users will need
to determine at what distances a specific angular degree can be done. Of course each tag type and
transceiver will have a different impact based on the degree of angling that one might achieve.
Most applications are looking to place the tag as far as possible from the transceiver. High Frequency systems
are usually limited in range to no greater than 1 meter. To obtain this 1 meter distance they must use a very large
transceiver and tag. Our RFID offering will only go up to 210mm when using an 8090 transceiver and a smart
card. In order to increase the distance between the RFID tag and transceiver you need to do one or more of the
following:
1.
Increase the size of the transceiver
2.
Increase the size of the RFID tag
3.
Increase the voltage to the RFID transceiver in order to increase the magnetic field strength.
Increasing the size of the transceiver is not possible unless they move from a smaller transceiver offering to a larger
one.
Increasing the size of the RFID tag is sometimes more of an option. Moving from a 20mm disc tag to a 50mm disc
tag can increase read/write distances from 65mm to 120mm.
Increasing voltage to the RFID transceiver is only possible by increasing the supply voltage to the RFID interface
(not recommended). Voltage fluctuations can have an adverse impact on RFID communications as the
changes in voltage can cause changes in the size and shape of the magnetic field produced by the
transceivers.
Communications between the RFID interface and transceiver is done via RS232 serial data. The data structure
(packet formation) is proprietary and not available to customers. This means that it is not possible to use a
transceiver without an interface.
When mounting an RFID transceiver it is important to mount them away from metal as well as away from other
RFID transceivers. Metal tends to warp the magnetic field, and having transceivers too close can cause
communication issue, because of this there should not be any metal closer than 30/50mm to the sides of a
transceiver depending on the transceiver used.
The rule of thumb to mounting multiple transceivers is to take the width of the magnetic field from center and
multiply it by 4 and that would be the distance needed between two similar transceivers. A 56RF-TR-8090 creates
a magnetic field 150mm wide from center. If we multiply 150mm x 4 = 600mm, we get 600mm from the center of
the first 8090 transceiver to the center of the second 8090 transceiver to ensure that the magnetic fields of both
transceivers do not overlap or have the ability to gang a tag from one transceiver to the next.
When mounting two dissimilar transceivers, always use the larger of the two calculations to determine minimum
distance requirements.
Installation instruction sheets for the transceivers can be found here:
56RF-TR-M18 http://literature.rockwellautomation.com/idc/groups/literature/documents/in/56rf-in012_-en-p.pdf
56RF-TR-M30 http://literature.rockwellautomation.com/idc/groups/literature/documents/in/56rf-in013_-en-p.pdf
56RF-TR-4040 http://literature.rockwellautomation.com/idc/groups/literature/documents/in/56rf-in009_-en-p.pdf
56RF-TR-8090 http://literature.rockwellautomation.com/idc/groups/literature/documents/in/56rf-in010_-en-p.pdf
RFID Tags
There are many different RFID tags that Rockwell offers, all of which are ICODE compatible. ICODE is the industry
standard for high-frequency (HF) solutions. This proven technology supports the ISO 15693 / ISO 18000-3 compliant
infrastructure. Information regarding the ICODE standard can be found here
http://www.nxp.com/documents/data_sheet/SL058030.pdf
RFID tags are mounted to devices in order to track and record information during manufacturing. Each tag type
offers different user memory sizes as well as physical size characteristics. Mounting of a tag can be done with an
epoxy, glue, screw or rivet depending on the type. In most cases tags are mounted on plastic, glass, wood, or
some other non-Ferris material. Unless a tag specifically states that it is a mount on metal tag, you cannot mount
tags directly onto a metal surface as this will drastically reduce the read/write distances or they will not work at all.
Technote 474309 discusses mounting tags on metal and the requirements of doing so.
When mounting tags, it is critical to space them apart so that there will not be more than one tag in the field at a
time. This means if you are using a 56RF-TR-8090 transceiver, you would need to space your RFID tags at least
300mm apart. In very rare applications, multiple RFID tags are mounted in close proximity. The RFID system can
detect up to 4 tags in a field at a time and there are only a few commands that support multiple tags in a field.
Another consideration is distance between the tag and transceiver. For stationary applications this technically
doesn’t matter what the distance is as long as the tag is in range of the transceiver the entire time commands are
being executed. However on moving applications the distance between tag and transceiver is critical. Tech
note 473890 talks about optimal tag heights as well as minimum and maximum distances.
Information on RFID tag offerings can be found here
http://literature.rockwellautomation.com/idc/groups/literature/documents/br/rfid-br001_-en-p.pdf
At the time of writing this document, all mount on metal tags, except for the 56RF-TG-50MOM have been
discontinued and there is no replacement. Please refer to technote 630043.
It is possible to use a 3rd party RFID tag as long as that tag is ICODE compatible. This in its self does not guaranty
that it will work because the ICODE standard is loosely written and only one command out of many are required,
the other commands are optional. The required command is inventory, which reads the UID information for a
tag. If a tag is in the field and the led indicator on the transceiver does not stay amber, then the tag does not
support the ICODE inventory command and will not work with our system.
Data within an RFID tag is stored in blocks, where each block is made up of a certain number of bytes. An SLI
style tag has 128 bytes of memory, with 4 bytes assigned to each block for a total of 28 blocks (0-27). Using math,
one can clearly see that 4 x 28 = 112 bytes not 128 bytes, so what happened to the other 16 bytes? The answer is
that internally the tag uses blocks -4 through -1 to store the UID information. A UID is a unique Identification given
to each tag during manufacturing and can never be change. The UID is 64-bits, or 16 bytes (8-bits in a byte) that
can be used by an application to identify a specific tag. The UID also hold additional information about the tag
including manufacturer and memory size. For additional information on how to decode a UID please refer to the
RFID user’s manual.
Due to limitation associated with the ICODE spec, an ICODE compatible tag can never be larger than 8k bytes
because the addressing scheme used for calculating blocks and byte offsets is a 16-bit word. Tags larger than 8k
would be considered proprietary, meaning they don’t use the ICODE command set as outlined in the spec.
Because of this, these proprietary commands are unknown to our RFID system and cannot be used.
RFID Commands
Commands are sent to the interface blocks in order to execute commands in the RFID tag; only one command
per channel can be sent at a time. Before a command is sent, the user must preload the appropriate data fields
to ensure that the setup information has been received by the interface prior to sending down the command
value. Note that before any commands can be sent to the interface, the Run bit IPD22:O.Run must = 1 otherwise
any command that execution will always error.
Data fields that need to be prepopulated are:
Reset – Should be 0. A value of 1 causes the channel to go through a reboot process.
BlockSize – Value based on the bytes per block of the tag. SLI tags come in memory sizes up to 128 bytes (112
bytes usable) and have a bytes per block size of 4. FRAM tags come in memory sizes up to 8k bytes and have a
bytes per block size of 8, 16, or 32. The current offering of Rockwell FRAM tags have 2k bytes memory and a bytes
per block size of 8. A value of 0 in this field specifies to use the default of 4 bytes per block.
Address – Based on the command used, could be referring to the byte starting location or the block starting
location.
Length – Based on the command used, could be referring to the number of bytes or number of blocks to execute
on.
Timeout – For a vast majority of application, this value can be left at 0 (default 750ms). The only time this may
need to be adjusted is when performing large reads/writes where the execution time may exceed the 750ms
time frame.
UIDLow – Represents the lower 32-bits of a 64-bit UID. For a vast majority of applications, this value can be left 0.
The only time it would need to be changed would be when attempting to lock a block, the DSFID or AFI value.
UIDHi – Represents the upper 32-bits of a 64-bit UID. For a vast majority of applications, this value can be left 0.
The only time it would need to be changed would be when attempting to lock a block, the DSFID or AFI value.
Data – When using write commands, the data field represents the information to be written to the tag. When
using read commands, the first 4 bytes need to contain a 0.
The rung below shows one possible way to preload the data prior to initiating a command.
Logic Construction will need to follow the process as outlined below.
1.
Preload the data as outlined above.
2.
Move a value of 0 into the output command word IPD22:O.Channel[0].Command.
3.
Verify that the input image command word IPD22:I.Channel[0].Command is now equal to 0, the value
you moved into the output image command word.
4.
Next move the value of the command to be executed into IPD22:O.Channel[0].Command. If we were
going to perform a Read Byte command, the value of that command is 4.
5.
Verify that the input image command word IPD22:I.Channel[0].Command is now equal to (in this
example) 4, the value you moved into the output image command word.
6.
Verify that the input image IPD22:I.Channel[0].ChError is equal to 0. This is the Channel Error value, and a
value other than 0 means there was an error in executing the command. Refer to the user’s manual for
the meaning of the error value.
a.
If this was a read command, and the IPD22:I.Channel[0].ChError word is 0, then your data will be
contained within the input image channel data section IPD22:I.Channel[0].Data. The amount
of data in bytes will be designated by the value contained within the Length field
IPD22:I.Channel[0].Length. Copy this data from IPD22:I.Channel[0].Data[0] with a length in
bytes received in IPD22:I.Channel[0].Length into your user tag.
b.
If this was a write command, and the IPD22:I.Channel[0].ChError word is 0, then your data has
been written to the RFID Tag.
For additional information on all the RFID commands, please refer to the RFID user’s manual.
A large majority of application will need to use only two commands. These two commands are Read Byte and
Write Byte. Read byte reads a specific number of bytes from a tag starting from an offset. Write byte writes a
specific number of bytes to a tag starting from a specific offset. One limitation with the AOP is that the output
image data field contains enough room to handle a write of up to 112 bytes, and the input image table contains
enough room to handle a 160 byte read. Reading and writing more data than 160 bytes / 112 bytes respectfully
requires the use of multiple Read/Write byte instructions. The AOI Read_Bytes_INT and Write_Bytes_INT handles
the reading and writing of a tag up to the size of an 8k tag with just a single AOI instruction. Inside the instruction,
the code is executing the basic read/write byte command multiple times, however using a single AOI to perform
this is much easier than writing multiple lines of code.
Other commands like Read Single Block and Write Single Block are popular with applications that only want to
read/write a single block of data. In either case there are multiple commands that can be used to accomplish a
wide variety of tasks.
Add on Instructions
To make writing ladder logic simpler and easier, Add on instructions were created to simplify the process.
Technote 518207 contains add on instructions for the RFID interfaces that can be downloaded and install into
RSLogix5000 version 20 and above. If a customer is using RSLogix5000 version less than 20, they will need to rewrite
the AOI’s in that version. These AOI will only work when the RFID interface is added to the I/O tree as an INT data
type (hence the xxx_INT name).
Instead of writing 10 lines of code that would be needed to execute a write byte command, you can drop one
add on instruction on the rung instead:
Add on instructions must stay true until the instruction has completed in order for the instruction to work correctly,
and only one add on instruction per channel can execute at a time.
All of the AOI’s require a unique control word to track the status of execution of the AOI. In the example rung
above, the control word is WLT_INT. The WLT_INT tag contains all the tags used to track the execution of the AOI
including .EN, .IP, .DN, and .ER bits. These bits can be used in the user’s code as triggers to execute additional
instructions or to note a problem with the execution of the AOI.
All of the AOI’s require an Input_Image and Output_Image word. This tag is used to identify what RFID interface
and what channel they are going to execute the command on. As shown above, the Input_image tag is
IPD22:I.Channel[0] and the output_image tag is IPD22:O.Channel[0], which is referring to the RFID interface
named IPD22 using channel 0. If we wanted to direct this instruction to RFID channel 1, we would change the
tags to IPD22:I.Channel[1] and IPD22:O.Channel[1].
RSLinx and EDS Files
RSLinx is the communication engine that allows our software to talk to our products. RSLinx uses an EDS file
(Electronic Data Sheet) to identify what the specific device is and how to talk to it. Embedded within the EDS file
is information pertaining to a devices capabilities and how to access them. When RSLinx does not have an EDS
file associated with a device it finds on the network, it places a yellow
in its list as a placeholder showing the
user that RSLinx did find something out there on the network, but it doesn’t know what it is or how to access any
additional information. The RFID product line has a built in EDS file, which means you can use RSLinx to upload the
EDS from inside the device and install the EDS file onto your computer. Tech note 467745 explains how to upload
the EDS file from within the device.
One misconception is that the EDS file is required for RSLogix500 or 5000, this is not the case. RSLogix500 does not
use EDS files at all, and RSLogix5000 does not need an EDS file in order to add the device to the I/O tree (this is a
function of the AOP). However with version 21 of RSLogix5000 and greater, you can use an EDS file to add the
device to the I/O if you do not have the AOP. This capability is limited to the fact that the EDS file must contain
enough information in order to have RSLogix5000 create a usable on-the-fly addon profile, but otherwise an EDS
file is never used inside RSLogix5000.
Setup and Configuration Steps
The following steps assume you will be using a CompactLogix or ControlLogix processor to communicate with an
RFID interface. Each step outlines a process that the user must go through in order to establish communications
and transfer data. These steps assume that the PLC being used is already configured and communicating on the
Ethernet network.
1.
Set the IP Address of the RFID Interface.
2.
If using RSLogix5000 versions <21, download and install the Addon Profile.
3.
Open your RSLogix5000 project and add the RFID interface to your I/O Tree.
4.
Download your project to the PLC and verify that a connection has been made to the RFID interface.
5.
Verify that the TagPresent bit for the RFID interfaces channel changes from 0 to 1 whenever a tag is
brought into range of the RFID transceiver.
6.
Import any desired Addon Instructions and write your ladder logic program.
Setting the IP Address
To set the IP address the user will need to perform the following steps:
1.
Verify that your computers IP Address is going to be on the same subnet as will the RFID Interface once its
IP Address is assigned via the BootP/DHCP utility.
2.
Set the rotary switches to 9 9 9 on the RFID Interface.
3.
Start the BootP/DHCP utility.
4.
Add the MAC ID of the RFID interface into the relationship list with a valid IP address by clicking the New
button.
5.
Power up the RFID interface connected to the Ethernet network.
6.
Ensure that the BootP utility assigned the RFID interface the associated IP address by checking the
Request History and check that the device shows up in RSLinx.
At this point the RFID interface has a valid IP address and is communication on the Ethernet network, however
with the rotary switches still set to 9 9 9, on the next power cycle of the device, the IP address will be erased and it
will request a new one from a BootP server.
To make the RFID interface request an IP address from a DHCP server perform the following steps:
1.
Set the rotary switches to 9 9 9.
2.
Start the BootP/DHCP utility
3.
Add the MAC ID of the RFID interface into the relationship list with a valid IP address
4.
Power up the RFID interface connected to the Ethernet network.
5.
Ensure that the BootP utility assigned the RFID interface the associated IP address by verify that the
6.
Set the rotary switches to 0 0 0
device shows up in RSLinx.
7.
Cycle power on the RFID interface
8.
Ensure that the BootP utility assigned the RFID interface the associated IP address by verify that the
9.
In the BootP utility select the device in the Relation List
device shows up in RSLinx.
10. Click Enable DHCP
11. A Success message should show up in the Status field.
At this point the RFID interface will request an IP address from a BootP/DHCP server every power cycle
If you want to make the IP address static perform the following steps:
1.
Set the rotary switches to 9 9 9.
2.
Start the BootP/DHCP utility
3.
Add the MAC ID of the RFID interface into the relationship list with a valid IP address
4.
Power up the RFID interface connected to the Ethernet network.
5.
Ensure that the BootP utility assigned the RFID interface the associated IP address by verify that the
device shows up in RSLinx.
6.
Set the rotary switches to 0 0 0
7.
Cycle power on the RFID interface
8.
Ensure that the BootP utility assigned the RFID interface the associated IP address by verify that the
device shows up in RSLinx.
9.
In the BootP utility select the device in the Relation List
10. Click Disable BootP/DHCP
Rotary switch positions:
8 8 8 clear out the old IP address information
9 9 9 Restores all settings back to default as if it was new out of the box
0 0 0 Allows writing to memory inside the RFID interface so that BootP/DHCP, baud rate, duplex, etc. can be set.
0 0 1 – 2 5 4 Used to set a hard address of 192.168.1.xxx where xxx is the rotary switch position.
Any other position not mentioned is not valid and could potentially cause issues.
When using the BootP/DHCP utility, it is critical that the utility is setup correctly. To verify the setup of the utility,
select Tools->Network Settings to view the screen below.
Verify that the subnet mask will allow your computer to talk to the RFID interface. Using a subnet mask of
255.255.255.0 will only allow your computer to talk to devices at 192.168.1.xxx assuming your computer is at
192.168.1.xxx.
If you do not have a gateway, you must use the default gateway address of 192.168.1.1, again assuming your
computers IP Address is 192.168.1.xxx. If your computers IP Address is 10.240.32.45, then your gateway address
would be 10.240.32.1. If your gateway address is not correct, the RFID interface will not keep its IP Address on a
power cycle.
If your network does not use a Primary and/or Secondary DNS (Domain Name Server), then set these address to
0.0.0.0.
Adding the RFID Interface to the I/O Tree
In order to have a ContolLogix or CompactLogix processor communicate with the RFID interface over Ethernet,
the interface needs to be added to the projects I/O tree.
In your RSLogix5000 project, right mouse click your Ethernet adapter module/port
1.
Select New Module
2.
In the search filed type 56rf and select the RFID interface and click Create
If you did not find your RFID interfaces part number in the list, then you will need to download and install the AOP.
In this example we are missing the 56RF-IPS12 and the 56RF-IPD22A from the list.
3.
Give the interface a name and an IP address. Please note that filling in an IP address here does not
assign the RFID interface an IP address, it only tells RSLogix what the RFID’s IP address will be and where
to find it.
By default the Data Table format is INT. If the user requires a SINT format, they would need to click the
Change button at this point in the process.
4.
Click OK
The RFID module is now in the I/O tree with the name given to it in the previous step.
By default the RPI (Requested Packet Interval) is set to 20ms. This means that every 20ms the data inside the RFID
interface is transferred back to the PLC’s Input Image table, and every 20ms data in the PLC’s Output Image
table is transmitted to the RFID interface. For stop and go applications this update rate is fine, but for on the fly
applications the RPI will need to be lowered to 2ms. When a tag is traveling at 1 meter/sec its traveling at
millimeters per millisecond, and at 20ms it has already traveled 20mm. We can give ourselves a little more time
by increasing our RPI from 20ms to 2ms, which means we can detect a tag present 10x as fast and send
commands down to the interfaces as well as receive responses 10x as fast. At a 2ms RPI we can detect a tag
that has traveled 2mm’s inside the field instead of 20mm’s, giving us our tag present bit faster and the ability to
read more data before the tag leaves the field.
Data Tables
The Addon profiles in RSLogix5000 assigns names and organizes the data contained with the RFID interface.
RSLogix500 software does not use AOP’s but instead uses different data table types like N7. When programming
with RSLogix500 the user will need to create all data table structures as well as keep track of what information is
contained within each data location.
Data table information and layout for both RSLogix5000 and RSLogix500 is defined within the RFID user’s manual.
Appendix B will also need to be referenced for any CIP messaging that will be required when using an SLC or
MicroLogix processor.
Programming
Programming and example code can be found in the RFID user’s manual as well as in the following technotes:
466178 Sample code for a Micrologix 1400
466341 Sample code for a ControlLogix processor
Programming the RFID interface is made easier when using the AOI’s in conjunction with the AOP’s, but the
sample code can give the user a good starting point in construction of their code for their application.
Technote 518207 contains 16 Addon instructions that users can import into RSLogix5000 and use to simplify the
programming process. Each addon instruction is meant for a specific task, meaning the user may only need 1 or
2 of the addon instructions for their program. All of the AOI ladder code is viewable and editable, meaning the
user can modify the AOI’s as they see fit. However if their modifications cause issues with the operation of the
instruction, then it will be up to the user to troubleshoot their code changes.
The following four Addon instruction will be broken down for further clarification in order of popular use. Other
addon instructions will not be covered but their operation and tag types are similar if not the same as those
covered below.
1.
ReadBytes_INT
This AOI uses command 4 (Read Bytes) to read a tag from a starting address. This AOI has the capability to read
up to 64,000 bytes.
ReadBytes_INT: RLT_INT is the command word used to track the status of the block of code
Input_Image: IPD22:I.Channel[0] points to the input data channel on the RFID interface that will be used for the
AOI
Output_Image: IPD22:O;Channel[0] points to the output data channel on the RFID interface that will be used for
the AOI
Block_Size: BlockSize informs the interface of the number of bytes per block of the RFID tag. Valid values are 0, 4,
8, 16, 32
Destination_Tag: DstData is used to store the information that is read from the tag
Start_Address: StartAddress is the starting byte address in the tag to start reading from
Number_Of_Bytes: Bytes is the number of bytes to read from the tag starting from the Start_Address
Bytes_Left: Used to track the number of bytes the instruction has left to read
Error_Code: Used to track any error received during execution of the AOI
Execution_Time: Tracks the total time (in milliseconds) that was required for the AOI to finish
RLT_INT_Trigger is a user tag that would be used to initiate the execution of the AOI. The AOI rung would need to
be TRUE until the AOI is either finished (DN bit set) or errors (ER bit set). How the user triggers the AOI is up to them,
but the rung needs to stay true until it completes. The AOI does not do any checking to see if a tag is present
before sending the command, this is required to be done by the user.
Another question that commonly comes up is how to write string data to an RFID tag. Tech note 487005 explains
how this is accomplished.
2.
WriteBytes_INT
This AOI uses command 14 (Write Bytes) to write to a tag from a starting address. This AOI has the capability to
write up to 64,000 bytes.
WriteBytes_INT: WLT_INT is the command word used to track the status of the block of code
Input_Image: IPD22:I.Channel[0] points to the input data channel on the RFID interface that will be used for the
AOI
Output_Image: IPD22:O;Channel[0] points to the output data channel on the RFID interface that will be used for
the AOI
Block_Size: BlockSize informs the interface of the number of bytes per block of the RFID tag. Valid values are 0, 4,
8, 16, 32
Source_Tag: SrcData used to write the information to the tag
Start_Address: StartAddress is the starting byte address in the tag to start writing to
Number_Of_Bytes: Bytes is the number of bytes to write to the tag starting from the Start_Address
Bytes_Left: Used to track the number of bytes the instruction has left to write
Error_Code: Used to track any error received during execution of the AOI
Execution_Time: Tracks the total time (in milliseconds) that was required for the AOI to finish
WLT_INT_Trigger is a user tag that would be used to initiate the execution of the AOI. The AOI rung would need to
be TRUE until the AOI is either finished (DN bit set) or errors (ER bit set). How the user triggers the AOI is up to them,
but the rung needs to stay true until it completes. The AOI does not do any checking to see if a tag is present
before sending the command.
3.
ReadSingleBlock_INT
This AOI uses command 1 (Read Single Block) to read a tag from a starting address.
ReadSingleBlock_INT: RSB_INT2 is the command word used to track the status of the block of code
Input_Image: IPD22:I.Channel[0] points to the input data channel on the RFID interface that will be used for the
AOI
Output_Image: IPD22:O;Channel[0] points to the output data channel on the RFID interface that will be used for
the AOI
Bytes_Per_Block: BytesPerBlock informs the interface of the number of bytes per block of the RFID tag. Valid
values are 0, 4, 8, 16, 32
Destination_Tag: Dst_RSB is used to store the information that is read from the tag
Block_Number: BlockNumber is the starting block address in the tag to start reading from
UID_Low: Lower 32bits of the UID of the tag.
UID_Hi: Upper 32bits of the UID of the tag.
Option_Flag: Refer to the user’s manual for specific values
Bytes_Returned: Used to track the number of bytes the instruction has read
Error_Code: Used to track any error received during execution of the AOI
Execution_Time: Tracks the total time (in milliseconds) that was required for the AOI to finish
RSB_INT_Trigger is a user tag that would be used to initiate the execution of the AOI. The AOI rung would need to
be TRUE until the AOI is either finished (DN bit set) or errors (ER bit set). How the user triggers the AOI is up to them,
but the rung needs to stay true until it completes. The AOI does not do any checking to see if a tag is present
before sending the command, this is required to be done by the user.
4.
WriteSingleBlock_INT
This AOI uses command 11 (Write Single Block) to write data to a tag from a starting address.
WriteSingleBlock_INT: WSB_INT is the command word used to track the status of the block of code
Input_Image: IPD22:I.Channel[0] points to the input data channel on the RFID interface that will be used for the
AOI
Output_Image: IPD22:O;Channel[0] points to the output data channel on the RFID interface that will be used for
the AOI
Bytes_Per_Block: BytesPerBlock informs the interface of the number of bytes per block of the RFID tag. Valid
values are 0, 4, 8, 16, 32
Source_Tag: WSB_Src is the data used to write the information to the tag
Block_Number: BlockNumber is the starting block address in the tag to start writing from
UID_Low: Lower 32bits of the UID of the tag.
UID_Hi: Upper 32bits of the UID of the tag.
Error_Code: Used to track any error received during execution of the AOI
Execution_Time: Tracks the total time (in milliseconds) that was required for the AOI to finish
WSB_INT_Trigger is a user tag that would be used to initiate the execution of the AOI. The AOI rung would need to
be TRUE until the AOI is either finished (DN bit set) or errors (ER bit set). How the user triggers the AOI is up to them,
but the rung needs to stay true until it completes. The AOI does not do any checking to see if a tag is present
before sending the command, this is required to be done by the user.
CIP Messaging
Programming and examples are contained within the user’s manual appendix B. CIP Messaging is normally seen
when a customer is using a SLC or micrologix processor. Rarely may you have a customer attempting to use a 3rd
party PLC to communicate with the RFID interface. Their PLC must be able to talk CIP over Ethernet and be able
to access the class, instance, and attribute values provided in the user’s manual as if their PLC was a SLC or
micrologix processor. If they have no way of accessing the CIP object classes, then this will not work. A work
around may be to use a SLC or micrologix processor to control the RFID interface, and have their 3rd party PLC
send and receive information with the SLC or micrologix processor.
Troubleshooting
When troubleshooting an RFID system, it is important to know the following:
•
Unit in question
•
Firmware revision
•
Transceiver style used
•
Tag type used
•
Distance of tag to transceiver
•
Issue at hand
There are potentially demo cases out in the field that used prototype RFID units. These units are clearly marked as
prototype OR do not have any markings on them. If you run into any issues with prototype equipment, they will
need to acquire actual released equipment pieces. There is no way to flash or upgrade prototype units.
Make sure they are running the latest revision of firmware in the interface and transceivers. Far too often have
customers had issues with certain commands, to later find out they are running an early firmware revision where
these issues were actually documented in a tech note.
Tag to transceiver distance is largely based on the transceiver being used. If a customer is attempting to get
120mm sensing distance out of an M18 transceiver, there is no way this would work.
Make sure they are using our RFID tags. If the customer is using a 3rd party tag and having issues, have then
acquire a comparable AB tag and perform the same tests.
When dealing with Ethernet communications related issues, make sure that the device shows up in RSLinx. If
RSLinx cannot see the RFID interface, then there is a pretty good chance nothing else will either. If they can see it
in RSLinx but the PLC is having issues communicating with it, then verify that the IP address in RSLinx matches the IP
address set in RSLogix. You will also need to find out what the error code and verbiage description is. An Error
code 16#0204 is a connection timeout, meaning the PLC cant communicate or see the device. An error code
16#0203 is another connection timeout but this time it means that the PLC can see the device but the
connection is timing out during the handshaking process. Usually a 16#0203 is related to a connection issue inside
the PLC or the PLC’s Ethernet adapter card. Verify firmware in the PLC and Ethernet adapter cards are the
correct version for the controller firmware.
There are many troubleshooting technotes available for reference including the following:
•
468380
•
465493
•
468424
•
618487
•
470961
•
601554
•
494843
Troubleshooting ladder code is not a simple matter. In this case you need to verify that the RFID equipment
actually works.
Make sure that no customer ladder code is executing with the exception of one rung that will be used to set the
xxx:O.Run bit true all the time.
1.
Go into the data tables for the RFID interface
2.
Set all the output image data tables as shown above. Make sure that Data[0] & Data[1] have a value of
3.
Place the tag in range of the RFID transceiver.
4.
Verify in the input image table that the TagPresent bit is true.
0.
5.
Enter a value of 4 in the output Command word.
6.
A value of 4 should show up in the input image Command word.
7.
ChErr in the input image command word should be 0.
8.
The Counter word in the input image should increment by 1.
9.
The Length field in the input image should show a value of 4 (4 bytes read)
10. The data that was read should show up in the input Data field.
If these steps produced the expected results then their RFID equipment is functioning properly and the user will
need to evaluate their code. If not see what the error code is and evaluate further.