RFID 181EIP Ident Device Configuration and Programming - Molex

RFID 181EIP Ident Device - Configuration and Programming – 03/2009 1 of 97 Copyright © SST 2009. All rights reserved.

RFID 181EIP Ident Device

Configuration and Programming

Version 3.20 Edition 03/2009


Contents 1. Scope....................................................................................................................................... 3 2. Configuration of the RFID 181EIP for the use in an Ethernet/IP network environment............. 4

2.1 Requirements:.......................................................................................................................... 4 2.2 Installing Hard- and Software................................................................................................... 4 2.3 Assigning IP-Address data....................................................................................................... 4 2.4 IP-Address data - Troubleshooting........................................................................................... 9 2.5 Adding EDS-File data............................................................................................................. 11 2.6 Verifying Ethernet/IP Configuration with RSLinx .................................................................... 12 2.7 Adding IO/Connection within RSLogix 5000........................................................................... 13

3. Communicating with the RFID 181EIP Ident device............................................................... 16 3.1 Communication Principle ....................................................................................................... 16 3.2 Ethernet/IP encapsulation of PIB telegrams........................................................................... 19 3.3 Transfer syntax cyclic data..................................................................................................... 20

3.3.1. Cyclic Control Word....................................................................................................... 20 3.3.2. Cyclic Status Word ........................................................................................................ 21

3.4 Parameter Telegram .............................................................................................................. 23 4. Ethernet/IP Object/ID structure of the RFID 181EIP Ident device .......................................... 24 5. PIB Commands...................................................................................................................... 26

5.1 PIB Command description ..................................................................................................... 27 5.2 Acyclic Command and Acknowledge Telegram ..................................................................... 38 5.3 Detailed Coding of Command and Acknowledgement telegrams........................................... 40 5.4 Hints for programming............................................................................................................ 56

6. Error and Warning Concept ................................................................................................... 57 6.1 Structure of the error/status information ................................................................................. 57 6.2 Error messages...................................................................................................................... 58

6.2.1. Errors from the communication module / reader............................................................ 58 6.2.2. Errors of the RFID standard profile concerned to user program .................................... 68 6.2.3. Errors from Ethernet/IP.................................................................................................. 69

6.3 Warnings................................................................................................................................ 69 6.4 Special error handling ............................................................................................................ 70

6.4.1. Detecting a switched off ident unit ................................................................................. 70 6.4.2. Detecting an unconnected reader.................................................................................. 70

7. Test application...................................................................................................................... 71 7.1 Structure ................................................................................................................................ 71 7.2 Short description of the sub routines...................................................................................... 73 7.3 Mapping of the Communication Principle to Ladder Logic...................................................... 75 7.4 Representation of Cyclic Data................................................................................................ 76 7.5 Representation of PIB Command and Acknowledge Data ..................................................... 77 7.6 Adding new RFID 181EIP devices to the test application....................................................... 79

8. Firmware-Update ................................................................................................................... 82 9. Appendix................................................................................................................................ 86

9.1 Using the RFID 181EIP with an Allen-Bradley PLC5 Controller ............................................. 86 9.1.1. Preface.......................................................................................................................... 86 9.1.2. Requirements ................................................................................................................ 87 9.1.3. Setting the RFID 181EIP into PLC5 mode..................................................................... 88

9.2 Comparison: RFID 181EIP connected to ControlLogix or PLC5 ............................................ 88 9.2.1. PLC relevant differences: ControlLogix ↔ PLC5........................................................... 88 9.2.2. Software relevant differences: RSLogix5000 ↔ RSLogix5............................................ 90 9.2.3. Exchange of cyclic data................................................................................................. 93

9.3 Test application for RSLogix5 / PLC5 .................................................................................... 94 9.3.1. Structure........................................................................................................................ 94 9.3.2. Short description of the sub routines ............................................................................. 96


1. Scope In its first part this document gives a description of configuring the Ethernet/IP and PIB based Radio Frequency Ident Device RFID 181EIP. The second part shows the user to program and to control the RFID 181EIP by using PIB commands (Proxy Ident Function Block) and Ethernet/IP as the encapsulating transport protocol. The Proxy Ident Function Block is a software component which is used for Radio Frequency Identification Systems and Barcode Readers. PIB supports configuration of Ident Units, reading and writing data as well as status and command handling. This document is based on the following paper: Specification of Profile for Identification Systems, Proxy Ident Function Block (PIB), Version 1.1, February 2006 Publisher: PNO e.V., Haid-und-Neu-Str. 7, D-76131 Karlsruhe, Germany Order Number: 3.124 The interested user will get more detailed information in this document.


2. Configuration of the RFID 181EIP for the use in an Ethernet/IP network environment

2.1 Requirements: Hardware:

• One or more RFID 181EIP Ident Device(s) • SIMATIC RFID reader(s) connected to RFID 181EIP Ident Device(s) • An Allen-Bradley ControlLogix 1756 or compatible PLC with an Ethernet/IP-

compatible network interface suitable for the use together with the RSLogix 5000 Software (in the following ‘PLC’)

• A Windows™- or compatible PC with a free 10/100 MBit Ethernet network interface (in the following ‘PC’) and TCP/IP installed and valid IP-Address data assigned to the interface.

Software:

• Windows XP™ with Service Packs installed • FTP and Telnet installed for possible Firmware-Update • RSLogix5000™ (v15.01.00 or higher) • RSLinx™ Classic or RSLinx Classic lite (v 2.500.20 (CPR7) or higher) • A DHCP-Server, in example the BOOTP/DHCP-Server 2.3, coming with the

RSLinx™ Software • The EDS Hardware Installation Tool, coming with RSLinx/RSLogix™

2.2 Installing Hard- and Software

• Please install the RFID 181EIP Ident Device and connect the cables according to the instructions.

• Install the Allen-Bradley or compatible PLC Hardware according to the instructions of their corresponding manual(s).

• Install the required Software on the Windows™- or compatible PC according to the instructions of its corresponding manual(s).

• Instead of the BOOTP/DHCP-Server 2.3, coming with the RSLinx™ Software, an existing DHCP-Server can be used.

• Connect the Ethernet/IP-compatible network interfaces of the RFID 181EIP Ident Device, the PC and the PLC to the Ethernet/IP network. Ensure that all mentioned components are powered up.

• Configure RSLinx™ to use (among others) the Ethernet/IP Driver according to the instructions of the RSLinx™ manual.

2.3 Assigning IP-Address data At first IP-Address data (IP-Number, Net Mask etc.) has to be assigned to the RFID 181EIP Ident Device in order to make it useable on the Ethernet/IP network. The RFID 181EIP Ident Device is able to obtain an IP-Address data over the Dynamic


Host Configuration Protocol (DHCP) or it can use static IP-Address data (which is recommended). Attention: In its shipping state the RFID 181EIP Ident Device does not have IP-Address data assigned. So when an "out of the box" Base module and an "out of the box" Connection block are connected and powered up for the first time, you cannot access it by a Web-Browser or by Telnet and you cannot establish a connection! In this state nearly all LEDs of the Base Module are switched on which means that the boot process has not finished because of the missing IP-Adress data. Therefore the RFID 181EIP Ident Device tries to find IP-Adress data over DHCP when it is turned on for the first time. To fulfill the DHCP requests of the RFID 181EIP Ident Device a DHCP-Server on the subnet is required (or at least the ability of the router(s) to forward DCHP-Packets to a DHCP-Server in a neighborhood subnet). The customer can use any existing appropriate DHCP-Server on the subnet (network). If there is no DCHP-Server on the network the BOOTP/DHCP-Server 2.3, coming with the RSLinx Software, can be used. The following configuration example shows the steps for assigning IP-Address data using the BOOTP/DHCP-Server 2.3, coming with the RSLinx™ Software.

A) Please check for the unique 12-Digit Ethernet MAC-Address on the RFID 181EIP chassis. Look for ‘MAC-ADD: XX-XX-XX-XX-XX-XX where X stand for a hexadecimal digit from 0 – F. If needed, note it down.

B) Start the BOOTP/DHCP-Server

2.3 from the Start Menu. The location in the Start Menu depends on your installation; usually it is located in on of the ‘Rockwell Software Subfolders. After some seconds the DHCP requests from the device(s) on the Ethernet network respectively their unique Ethernet MAC-Address(es) can be seen in the Request List. Compare the 12 Digit Ethernet MAC-Address(es) in the Request List with the one printed on the RFID 181EIP Ident Device. If the Ethernet MAC-Address cannot be found or the Request List stays empty please check if all cables are connected properly and the RFID 181EIP is powered up or see 2.4.


C) From the ‘Tools’-Menu click on

‘Network Settings’. Enter the settings for ‘Subnet Mask’ (required) and for ‘Gateway’ (optional, if the PLC resides in another subnet) in decimal dotted notation in the dialog box. The values for ‘Primary DNS’, ‘Secondary DNS’ and ‘Domain Name’ are not supported by the current firmware release of the RFID 181EIP. Click ‘OK’.

D) After identifying the Ethernet

MAC-Address create a new DCHP entry for the RFID 181EIP Ident Device. Click on the ‘New’-Button on top of the Relation List. The ‘New Entry’-Dialog opens. Please enter the Ethernet MAC-Address (required), the IP-Address (required) in dotted decimal notation, a hostname (optional) and a description (optional) and click ‘OK’.

E) The new entry is now shown in

the Relation List. After a while the next request of the RFID 181EIP is answered by the BOOTP/DHCP-Server 2.3 and an IP-Number is assigned to the Device. This is shown in the Request History. Now the RFID 181EIP device can be reached over TCP/IP with the shown IP-Number. Now the device is ready to be accessed by Web-Browser, Telnet etc. Attention: - It can last up to 1 minute until the entry in the Relation list results in an IP-Address assignment to the RFID 181EIP Ident Device! - To access the device ensure that the accessing PC/Laptop/PLC has an IP-Address of the same subnet assigned!


F) Start a Web-Browser (i.e. Microsoft Internet Explorer or Mozilla Firefox).

In the address field enter “http://<IP-Number>”, where <IP-Number> is the assigned IP-Number. Authenticate with the login “fwupdate” and the password “R_F_I_D_”. After successful authentication the Ethernet/IP Ident Object (0x01) and the TCP/IP Interface Object (0xF5) are shown in the browser window. At the TCP/IP Interface Object the TCP/IP Interface attributes can be changed. The ‘DHCP enabled’ checkbox is enabled. To assign a static IP-Address uncheck ‘DHCP enabled’ and enter/change the value for ‘IP-Address’, ‘Net Mask’, ‘Gateway Address’ and ‘Hostname’ manually according to your

needs. The current values received over DHCP are the shown as default values. Click on ‘Store settings to NVRAM and reboot device’ when ready. The data is stored both in the non volatile RAM (NVRAM) of the Connector Block and the Indent Device itself*. Then the device reboots and uses the static IP-Address data. After reconnecting (it may be necessary to change the IP-Address in the address field of the browser) the browser window shows the changed IP-Address data and the changed content of the NVRAMs. (see next page) *) Note: If the Ident Device has to be changed for support reasons, the IP-Address data in NVRAM of the Connector block will still be there and will be used instead of DHCP if a newly shipped device is connected to the remaining Connector Block


Attention: It is recommend using static IP-Address data stored in the RFID 181EIP Ident Device. Although it is possible to leave ‘DHCP enabled’. This will cause the RFID 181EIP Ident Device to search the DHCP-Server on every reboot for valid IP-Address data which slows down the reboot process. The settings for ‘IP-Address’, ‘Net Mask’, ‘Gateway Address’ and ‘Hostname’ will be ignored in this case. If you still want to use DHCP assigned IP-Address data on every reboot, it is also necessary to ensure a unique static mapping of Ethernet MAC-Address and IP-Address. Don’t use dynamic IP-Address assignment from an IP-Address pool for the RFID 181EIP Ident Device(s)!

G) The following table shows the behavior of the module regarding different

combinations of IP-Address data in the module and in the Connector block

IP-Address data in NVRAM of the module

IP-Address data in NVRAM of the Connector block

Resulting/used IP-Address data

DHCP DHCP => DHCP DHCP Static IP-Address data => Static IP-Address data Static IP-Address data DHCP => Static IP-Address data Static IP-Address data Static IP-Address data => Static IP-Address data of

the module (until Firmware version 3.0.4)

Static IP-Address data Static IP-Address data => Static IP-Address data of the Connector block (Firmware revision greater 3.0.4)


Hint: After changing module or Connector block for support reasons it is recommended to enter the Web-interface to synchronize IP-Address data again. There is no automatically synchronization!

2.4 IP-Address data - Troubleshooting If it is not possible to assign IP-Adress data to the RFID 181EIP Ident Device, please execute the following procedure:

- Connect the RFID 181EIP Ident Device directly to your PC, notebook etc. Do not connect any other module/device/CPU to that network interface and, at this point, do not (!) power up the RFID 181EIP Ident Device.

- Disconnect other network cables connected to your PC/notebook and ensure that the 181EIP module is the only network device connected to your PC/notebook.

- Start the BOOTP/DHCP-Server 2.3, coming with the RSLinx™ Software and configure the network settings if not already configured (net mask, router.)

- The Request History Window of the Bootp/DHCP server should be empty (and stay empty until power up).

- Power up the RFID 181EIP Ident Device:

The Ident Divice should show nearly all LEDs switched to ON. One of the two LINK LEDs of the Connection block should be switched on (green). The Request History Window of the Bootp/DHCP server should now show the requests of the module. You should see only one MAC-address repeatedly. The RX/TX LED besides the active LINK LED of the Connection block should flash clearly visible even once in 2 minutes (yellow) indicating the DHCP-Requests packets from the module to the server on your PC/notebook.

- Double click in the Request History Window of the Bootp/DHCP server on the

MAC-address. A dialog opens: - Enter a valid IP-Address - Click OK

- Next time the module asks the Bootp/DHCP server the module should get the

IP-Address (although shown in the the Request History Window of the Bootp/DHCP server). - Only the DC24V LED, the ON LED are now constantly on and the BF LED is blinking. The other LEDs are off. - Adjust the IP Address/subnet mask of your PC/notebook network adapter a one of the same IP subnet you gave the module.


If the Request History stays empty or no connection is possible to the module, it can be caused by one of the following reasons:

State Reason Solution None of the LINK LEDs of the Connection block show a link to the PC/notebook

No physical connection between PC/Laptop and RFID 181EIP Ident Device

Check the cabling

Nearly all LEDs are ON; One of the LINK LEDS is green; no flashing at the corresponding RX/TX LED for 2 minutes

RFID 181EIP Ident Device is defective

Change the device

Nearly all LEDs are ON; One of the LINK LEDs is green and the RX/TX LED is flashing at least once in 2 minutes

DHCP-Packets does not reach the DHCP-Server

Check the firewall/filtering settings of your PC/Laptop

RFID 181EIP Ident Device is connected via a hub, bridge or switch to the PC/Laptop. The very rare case occurred that the hub, bridge or switch does not support forwarding DHCP packets.

Change the hub, bridge or switch immediately.

The PC/notebook network interface or the RFID 181EIP Ident Device network interface is defective

Change PC/Laptop or the device

The above procedure worked out, but Ping, Telnet and Web-interface does not work

The IP-Address of the PC/notebook network interface does not fit to the subnet respectively to the IP-Address assigned to the device.

Adjust the IP-Adress of the PC/Laptop network interface

The above procedure worked out, but Ping, Telnet and Web-interface does not work; The IP-Address of the PC/notebook network interface fits to the subnet respectively to the IP-Address assigned to the device.

The ARP table (ARP cache) was not refreshed in time;

Clear the ARP table with command arp * -d <Enter> in a COMMAND windows (DOS box)

Only the DC24V LED and the ON LED are constantly on and the BF LED is blinking. The other LEDs are off

The RFID 181EIP Ident Device has already an IP-Address assigned

Access the device via Web-Browser as described in 2.3


2.5 Adding EDS-File data After all RFID 181EIP Ident Devices are configured with IP-Address data, connected to the Ethernet/IP network and powered up it is necessary to add an EDS-File (Electronic Data Sheet) to the EDS database in order to let RSLinx to identify the Ident Devices on the Network. Therefore start the EDS Hardware Installation Tool from the Start Menu and follow the instructions to add the EDS-File named ‘RFID 181EIP.eds’ on the CD that comes shipped with the in Ident Device in the Directory \EDS . Step by step:

A) Start the EDS Hardware Installation Tool from the Start Menu. Click on the ‘Add’-Button

B) Choose ‘Register a single file’ and ‘Browse’ the directory tree to search for the EDS-file of the RFID 181EIP Ident Device (usually on the CD shipped with the device). When you have found it, mark it and click on the ‘Open’-Button.

C) To verify the chosen EDS-file click on the ‘Next’-Button.


D) Verify or change the shown Icon

for the RFID 181EIP Ident Device. Click on the ‘Next’-Button

E) Click on the ‘Next’-Button twice to start the integration process

The EDS-File data then will be integrated in the EDS database. This EDS Hardware tool can also be used to remove EDS-File data if needed.

2.6 Verifying Ethernet/IP Configuration with RSLinx Start RSLinx. It is assumed that at least the Ethernet/IP driver is loaded. From the Main Window click on the ‘ ’-Button to open an RSWho-Child-Window. After browsing the network for a while the RSWho-Window shows all connected RFID 181EIP Ident Devices. The following example shows a network with two RFID 181EIP Ident devices, one the IP-Address 192.168.0.100 and one with the 192.168.0.101. The Ethernet/IP Scanner is named ‘Moby Host’ and is a 1756-ENBT/A Adapter which is plugged in a 1756-L61 LOGIX5561 PLC. If the RFID 181EIP Ident devices are shown with ‘Question mark’-icons instead of the assigned icons please restart the ‘RSLinx Classic’ service in the control panel of your Windows System (Start → Settings → Control Panel → Administrative Tools → Services → RSLinx Classic → right mouse button → restart).


2.7 Adding IO/Connection within RSLogix 5000 To establish an I/O connection to RFID 181EIP Ident device within RSLogix 5000 for the use in an application first (assuming correct cabling and IP-Address data assigned) click in the I/O configuration section with right mouse button on 1756 ENBT/A Ethernet/IP interface → Ethernet. Choose ‘New Module …’ in the context menu which opens the ‘Select Module’-Dialog in the figure below. Then choose ETHERNET-MODULE (Generic Ethernet Module) from the ‘Communications’ section.

This opens the ‘Module Properties’-Dialog (See next page).


On the General Tab enter a name for the new module differing i.e. “RFID 181EIP_00”, a description (optional). Choose “Data – INT” at the Comm Format Combo-Box. Then type in the IP-Address. Then set the Comm Format to ‘Data – INT’. Set the connection parameters as shown in the figure on the right side. Input Assembly Instance: 101 Size: 2 Output Assembly Instance: 100 Size: 2 Configuration Assembly Instance : 3 Size: 0 The Assembly Instance numbers and sizes are the same for every further RFID 181EIP Ident Device! Change to the Connection Tab and set the RPI to 20.0 ms. Click OK. Now a RFID_181PIB Ident Device is shown under the I/O configuration → 1756 ENBT/A Ethernet/IP interface → Ethernet section. Important: Adding the I/O Connection with its Assembly Instances in this way also creates the corresponding I/O-tags in the Controller Tag section (shown on the next page): The Input Assembly Instance (101 Size: 2) produces the ‘RFID 181EIP00:I-tag’ divided in two parts of 16-Bit each. These two 16-Bit words represent the Cyclic Status Word for each channel ([0] and [1]). The Output Assembly Instance (101 Size: 2) produces the ‘RFID 181EIP00:O-tag’ also divided in two parts of 16-Bit each. These two 16-Bit words represent the Cyclic Control Word for each channel ([0] and [1]). The Cyclic Control Word and Cyclic Status Word are permanently exchanged between the RFID 181EIP and PLC. They are described in detail at 3.3 . See also 7.4 .


2.8 Checking Firmware and Hardware Versions The firmware version can be determined by logging into the module with Telnet and typing the VER command. See Chapter 8 on how to communicate to the module in this way.

To also find out what the hardware version, examine the version matrix of the Base module. It is under the label of the connector X2. It is a small 2x2 matrix with the numbers 1 - 4 in it. One of the numbers is not visible. You’ll see an 'X'. This represents the hardware/firmware version.


3. Communicating with the RFID 181EIP Ident device

3.1 Communication Principle All PIB communication between PLC and RFID 181EIP Ident device is always initiated by the PLC (Originator) and bases on two types of telegrams:

1. Cyclic telegrams: With cyclic telegrams the PLC sends a “Control Word” and receives immediately a “Status Word” from the RFID 181EIP Ident Device. The content of the cyclic telegrams with its status flags and the command and acknowledge counters is used by PLC and Ident Device to control the flow of commands and data (acyclic telegrams).

2. Acyclic telegrams: Acyclic telegrams are used to transmit commands and the corresponding data.

PIB specifies four basic communication sequences for communication between a PLC and an Ident Device:

1. Synchronous operation for small amount of data, supported by the current RFID 181EIP firmware release

2. Synchronous operation for large amount of data (linked write commands), supported by the current RFID 181EIP firmware release

3. Synchronous operation for large amount of data (linked read commands), supported by the current RFID 181EIP firmware release

4. Synchronous operation (Command repetition), not supported by the current RFID 181EIP firmware release

The drawings on the next pages show the communication sequence of cyclic and acyclic telegrams for the cases 1. – 3.


Synchronous operation for small amount of data (PIB Command + Data ≤ 240 BYTE).

Command 1 is send as an ‘Acyclic Write’ in the request of acyclic telegram. The immediate response does not contain relevant data. After receiving the ‘Acyclic Write’ and writing it to a buffer the command counter is increased/changed by the RFID 181EIP. Then the RFID 181EIP processes the command. When ready the RFID 181EIP increases the acknowledge counter indicating to the PLC that a result is waiting. The PLC is sending an ‘Acyclic Read’ telegram containing no relevant data in the request, but having the length of the expected result. The immediate response contains the result (and the data). Remarks: *) In the above drawing “Acyclic Write (PIB command telegram)” means that a command is send to the Ident Device. In normal operation this can be a read or write command. **) the PLC does not need to check for the change of the command counter. ***) Corresponding to this an “Acyclic Read (PIB acknowledge telegram)” stands for a result of a previous (command) telegram.

Acyclic Write (PIB command telegram)*

Acyclic Read (PIB acknowledge telegram)***

Cyclic Data (acknowledge counter changed)

Cyclic Data (command counter changed)**

Cyclic Data (unchanged)


Cyclic Data (unchanged) . . .


PLC RFID 181EIP Ident Unit

Command 1

Command 2 Acyclic Write (PIB command telegram)

Cyclic Data (command counter changed)


.

.

.

t


Synchronous operation for large amount of data (linked write commands):

To write a large amount of data to the RFID 181EIP respectively to a tag (command + data > 240 BYTE), a sequence of ‘Acyclic Write’ telegrams is send to the RFID 181EIP and buffered. The first ‘Acyclic Write’ contains information how many telegrams will follow. It is not necessary to wait for a acknowledge for each telegram, just a change of the command counter indicates the PLC that the RFID 181EIP is ready to receive the next piece of data. After all ‘Acyclic Write’ telegrams have been processed the RFID 181EIP changes the acknowledge counter and the PLC requests the result with an ‘Acyclic Read’ telegram.

Acyclic Write (1st PIB command telegram)

Acyclic Read (PIB acknowledge telegram)





.

.

.


Acyclic Write (2nd PIB command telegram)


Acyclic Write (3rd PIB command telegram)



.

.

.

t

etc.


Synchronous operation for large amount of data (linked read commands, data to be read > 194 BYTES):

The ‘Acyclic Write’ contains a read command requesting more than 194 Bytes data. After reading the first data piece the RFID 181EIP changes the acknowledge counter to signal the waiting data to the PLC. The PLC gets the data pieces each time the acknowledge counter changes by an ‘Acyclic Read’ until all requested data is received.

3.2 Ethernet/IP encapsulation of PIB telegrams As chosen as the transport protocol for the RFID 181EIP Ident Device, Ethernet/IP supports the cyclic and the acyclic transmitting mechanisms of PIB. This is done by encapsulation of the PIB-telegrams respectively data in corresponding Ethernet/IP message types:

- Ethernet/IP implicit I/O messages: For the cyclic telegrams implicit I/O messages are used. They can also be defined as “cyclic” and “bidirectional”. One message per cycle is used to transmit the “Control Word(s)” from the PLC to the Ident Device and the immediate response from Ident Device contains the “Status Word(s)”. The RFID 181EIP receives one 16-Bit Control Word and sends one 16-Bit Status Word per Channel, therefore it receives and sends 32-Bits. For details on the meaning of the bits of Status and Control Word see 3.3.

Acyclic Write (PIB command telegram)

Acyclic Read (1st PIB acknowledge telegram)







Acyclic Read (2nd PIB acknowledge telegram)


Acyclic Read (3rd PIB acknowledge telegram)


.

.

.


t

etc.


- Ethernet/IP unconnected explicit (UE) messages: For the acyclic telegrams UE messages are used. They are used to transmit the essential data. At least two acyclic telegrams are needed for a PIB user command and its acknowledge. The first UE message contains the command and if it’s a ‘Write’ command the data to be written in the request (the immediate response does not contain relevant data). The second UE message contains the acknowledge (indicating status of the previous received command) in the response and if applicable read data. For detailed structure of the individual PIB Commands see Section 5.1.

Corresponding to PIB all Ethernet/IP messages are initiated by the PLC.

3.3 Transfer syntax cyclic data

3.3.1. Cyclic Control Word The coding of the cyclic control bytes is presented in the following diagram.

m 0 0 0 0 0 0 o m o 0 0 u u u u

Reserved Reserved ManufacturerspecificIn

it

Soft

_Res

et

Rep

eat_

Com

man

dCyclic output data

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

o...optionalm...mandatoryu...manufacturer specific

Rea

ding

_Gat

e

Control Word Coding

The meaning of the individual bits, depending on the use for RFID or BR systems, is as follows:

Meaning for RFID systems

Init

(mandatory)

This bit forces the Reader to restart its operation except the communication interface. Local operations done within this procedure are manufacturer specific. Initialization is forced if the bit is set to 1.

Soft_Reset

(mandatory)

If this bit is set to 1 the command currently processed within the Reader will become cancelled.

Repeat_Command

(optional)

This bit forces the Reader to repeat the command currently executed as long as the Repeat bit is set to 1. In case the bit is reset during the execution of a command the current command will be completed.

Not available for RFID180EIP

always set to 0

Reading_Gate Manufacturer specific use


(optional) Not available for RFID180EIP

always set to 0

Reserved Reserved bits have to be set 0.

3.3.2. Cyclic Status Word Following the coding of the cyclic Status bytes is presented.

m m m m m 0 o o m o o m u u u u

Manufacturerspecific

Init_

Act

ive

Soft

_Res

et_A

ctiv

e

Rep

eat_

Com

man

d_A

ctiv

e

Cyclic input data

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Res

erve

d

Tar

get_

Pres

ence

_Cha

nged

o...optionalm...mandatoryu...manufacturer specific

Com

man

d_C

ount

(CC

_L) l

ow

Ack

_Cou

nt(A

C_H

) hig

h

Ack

_Cou

nt(A

C_L

) low

Com

man

d_C

ount

(CC

_H) h

igh

Tar

get_

Pres

ent

Bus

y_Fl

ag

Err

or_F

lag

Status Word Coding

The meaning of the individual bits, depending on the use for RFID systems, is as follows:

Meaning for RFID systems

Init_Active

(mandatory)

This bit indicates, if set to 1, that the Reader is executing a startup procedure. After reseting the bit to 0 a Write-Config command is expected to be received from the PIB. Commands other then Write-Config are rejected with an error. It is intended to be used for resynchronization of acknowledge counter and command counter.

Ack_Count_high (AC_H)

(mandatory)

Acknowledge counter higher bit

Ack_Count_low (AC_L)

(mandatory)

Acknowledge counter lower bit

Command_Count_high (CC_H)

(mandatory)

Command counter higher bit

Command_Count_low (CC_L)

(mandatory)

Command counter lower bit

Target_Presence_Changed This bit indicates, if set to 1, that the number of transponder within the antenna lobe of the Reader has been changed


(optional) (incremented or decremented). This bit is reset after an Inventory command has been executed.

Target_Present

(optional)

This bit indicates, if set to 1, that a transponder is in the range of the Reader. It is reset if no tag is within the antenna lobe or the antenna is switched off.

Soft_Reset_Active

(mandatory)

If this bit is set to 1 it indicates that the command currently processed within the Reader has been cancelled. It is reset to 0 after Soft_Reset is reset.

Repeat_Command_Active

(optional)

This bit indicates (set to 1) that the Reader repeates the command last requested from the PIB.

Not available for RFID180EIP

always set to 0

Busy_Flag

(optional)

This bit is set to 1 as long as the Reader processes a command (independent of using Repeat_Command).

The bit is reset when the command processing is finished. However the data may not have been tranfered to the communication interface.

Not available for the RFID systems RF300, MOBY U, MOBY D

Error_Flag

(mandatory)

This bit indicates an fatal error at the Ident Unit hardware. Appropriate action must be taken by the user (e.g. read status information or request initialization routine through “INIT”).

Failure of the Reader because of missing power supply or error in the connection are also inticated with this bit.

Reserved Reserved bits have to be set 0.


3.4 Parameter Telegram To initialize the very basic operation a Parameter Telegram must be sent to the RFID 181EIP ident unit. This has to be done before any PIB communication can happen. This Parameter Telegram is 10 Bytes long. Four Bytes are currently used. The rest is reserved for future use. The meaning of the four used Bytes of the Parameter Telegram is: Byte Meaning Possible Values 0x00 Operation mode 0x03 PIB (always) 0x01 MOBY mode 0x01 Normal Addressing (NA, DA = Direct Access),

MOBY I/E 0x81 File Handler (FH), MOBYI I 0x05 Direct Addressing MOBY U, MOBY D, RF300 0x85 File Handler MOBY U 0x95 File Handler RF300

0x02 Baud rate 0x01 19,2 Baud 0x02 38,4 Baud 0x03 57,6 Baud 0x04 115,2 Baud

0x03 Diagnose mode 0x01 (always) 0x04 – 0x09

Reserved for future use

The test application (6.4) coming with the ident unit uses 0x03 (PIB), 0x85 (File Handler MOBY U), 0x04 (115,2 Baud) and 0x01 (Diagnose Mode) for parameterization. The Parameter Telegram has to be sent with special ObjectIDs (Service #0x41, ObjectID #0x80, InstanceID #0x01, AttributeID #0x01) to the RFID 181EIP ident unit. See also next chapter (4). Hints:

• Despite the fact that there are only 4 Bytes used 10 Bytes have to be sent as the Parameter Telegram.

• It is not possible to send different parameters with another parameter telegram. Once the parameters are accepted by the ident unit they can’t be changed until the device is re-energized.

• To finish parameterization another telegram with the same ObjectIDs and Length 0 has to be sent (ParameterEndTelegram).

In the test application (7.) the sending of the Parameter Telegram is done in the subroutine “Parameterization”.


4. Ethernet/IP Object/ID structure of the RFID 181EIP Ident device

Ethernet/IP provides an object structure and corresponding IDs to identify and address components, services and data of a device. The RFID 181EIP uses Class IDs, Instance IDs, Service IDs and Attribute IDs. The RFID 181EIP Ident Device itself is addressed over the vendor-specific Class ID #0x80 and the Instance ID #1. The two reader channels are addressed over the vendor specific Instance Attribute IDs #0x6f and #0x70 for normal operation, over #0x65 and #0x66 for initialization and over #1 for parameterization. To handle communication two vendor specific Ethernet/IP Services (“PIB Handler”, #0x41 PIB Acyclic Write/Command and #0x40 PIB Acyclic Read/Acknowledge) are provided. PIB Object (class code = 0x80) Class attributes Attribute ID

Access Rule

Name Data Type

Description of Attribute

Remark

1 Get Class revision WORD Revision of the PIB class 2 Get Max. instances WORD Maximum instances Always 1 for the

RFID 181EIP 3 Get Num. instances WORD Number of instances Always 1 for the

RFID 181EIP 4 Get Max. channels WORD Maximum channels per

instance Always 2 for the RFID 181EIP

Instance Attributes Attribute ID

Access Rule

Name Data Type Description of Attribute / Remark

Subroutine in test application

1 Service #0x41

Parameter Command / Parameter End Command

Array of Byte, Length 10 / Length 0

First command(s) send after startup

Parameterization

101, (0x65)

Services #0x40, #0x41

WriteConfig Command / Acknowledge Channel 0

Array of Byte, Length depending on the RFID Product Family

Contains the command / acknowledge for initialization of channel 0

Initialization (channel 0)

102 (0x66)


WriteConfig Command / Acknowledge Channel 1

Array of Byte, Length depending on the RFID Product Family

Contains the command / acknowledge for initialization of channel 1

Initialization (channel 1)

111 (0x6f)


Operation Command / Acknowledge Channel 0

Array of Byte, Length depending on the command / acknowledge

Contains the command / acknowledge the PIB commands of channel 0

every command subroutine of channel 0

112 (0x70)


Operation Command / Acknowledge Channel 1

Array of Byte, Length depending on the command / acknowledge

Contains the command / acknowledge the PIB commands of channel 1

every command subroutine of channel 0


Services to handle the class and the instance To handle a complete PIB command at least two Ethernet/IP messages with the class ID 0x80 (instance ID 1) and with the services 0x41 and 0x40 in this order are necessary. PIB Acyclic Write/Command (0x41, vendor specific): With the Acyclic Write/Command services a PIB command is send to the RFID 181EIP. Depending on the Attribute ID it is differentiated if the command is

• the Parameter Command (Instance Attribute #0x01) to sent the basic parameters to the RFID 181EIP

• a WriteConfig Command (Channel 0: Instance Attribute 101, #0x65, Channel 1: Instance Attribute 102, #0x66) → look at Write-Config, Write-Config (FH, DA)(detailed coding).

• a command for RFID operation (Channel 0: Instance Attribute 111, #0x6f, Channel 1: Instance Attribute 112, #0x70)

The Byte sequence for a PIB command is stored in the request data of the Ethernet/IP message with the 0x41 service. The response data of an Ethernet/IP message using the 0x41 service is empty.

PIB Acyclic Read/Acknowledge (0x40, vendor specific): The Acyclic Read/Acknowledge service fetches a PIB acknowledge from the RFID 181EIP. Depending on the Attribute ID it is differentiated if the command is

• (the Parameter Command (Instance Attribute 1) doesn’t have an acknowledge)

• a WriteConfig Acknowledge (Channel 0: Instance Attribute 101, #0x65, Channel 1: Instance Attribute 102, #0x66) → look at Write-Config, Write-Config (FH, DA)(detailed coding).

• an acknowledge for a previous RFID operation command (Channel 0: Instance Attribute 111, #0x6f, Channel 1: Instance Attribute 112, #0x70)

The request data of the message using the 0x40 service is empty. The response data of the message using the 0x40 service contains the acknowledge (or error information) of the previous message using the 0x41 service.


5. PIB Commands The following pages contain a description of the PIB commands which is a common standard for RFID devices. The table shows the PIB commands available in ‘Normal Addressing’-(DA = Direct Access) and ‘File handler’-(FH)-MOBY_mode:

To be able to use them for the RFID 181EIP some vendor-specific additional information regarding the PIB commands

• Write-Config and • Format

is needed. Follow the Links to the detailed description to find out more about these commands.

Command code available in MOBY_mode Command Hex ASCII

Parameters used Normal

addressing (NA, DA)

File handler (FH)

CLEAR 63 ‘c’ UID, FileName - - CREATE 68 ‘h’ UID. FileName, Length, Attributes, FileType - X DELETE 64 ‘d’ UID, FileName - X DEV-STATUS 74 ‘t’ Attributes, OffsetBuffer X X FORMAT 66 ‘f’ OffsetBuffer, UID, Length X X GET 62 ‘b’ OffsetBuffer, Length - X GET-ATTRIBUTE 6B ‘k’ UID, FileName - - GET-DIRECTORY 6D ‘m’ OffsetBuffer, UID, FileType - X INVENTORY 69 ‘I’ Attributes, OffsetBuffer X X MEM-STATUS 73 ‘s’ UID, Attributes, OffsetBuffer X X NEXT 6E ‘n’ UID, NextMode - X PHYSICAL-READ 70 ‘p’ OffsetBuffer, UID, Length, StartAddress X X PHYSICAL-WRITE 71 ‘q’ OffsetBuffer, UID, Length, StartAddress X - PUT 65 ‘e’ OffsetBuffer, Length - X READ 72 ‘r’ OffsetBuffer, UID, FileName, Offset, Length - X READ-BARCODE 6F ‘v’ OffsetBuffer, TimeOut, ObjectNumber - - READ-CONFIG 61 ‘a’ OffsetBuffer X X SET-ATTRIBUTE 6F ‘o’ UID, FileName, Attributes, FileType - X UPDATE 75 ‘u’ OffsetBuffer, UID, FileName. Length - X WRITE 77 ‘w’ OffsetBuffer, UID, FileName. Offset, Length - X WRITE-CONFIG 78 ‘x’ OffsetBuffer, Length, Config X X


5.1 PIB Command description

Name Description

Read

(FH)

This is the command to read data from a file (in case of RFID system) out of the Ident Unit. Data are stored in the RXBUF after the command succeeded. The parameter TRLEN of the PIB indicates the number of bytes received.

VAR CMD : BYTE := 0x72; (* r *) END_VAR

Parameters Description

OffsetBuffer This parameter specifies the relative offset within the RXBUF. It specifies the first address within the memory area where the first byte of data received has to be stored. All following bytes have to be stored at incremented addresses.

UID This parameter identifies a single transponder.

UID = 0: Any (no specific) The tag currently present is read.

FileName This parameter specifies the file to be accessed.

Offset This parameter specifies the relative offset within the specified file where the data shall be read.

Length This parameter specifies the number of bytes to be read from the file. Length = -1: read the whole file

Get This is the command to read manufacturer specific data located at the Ident Unit. The TXBUF is used as manufacturer specific area for parameter data (optional send data). Received data are stored within the RXBUF starting at the beginning of the RXBUF. The parameter TRLEN of the PIB indicates the number of bytes received. The following commands for RFID 181EIP are embedded in the Get telegram: Get_QREAD: Read several files or the whole tag with one command The Get_QREAD command can be used to read several files ( selective, max. of 12 files ) from the tag with one command. As an option, the entire tag with all files can be read. Get_MOVE: Save system data from the filehandler ( directory, FAT, checksum ) system data of the corresponding reader is transferred to the application . - After a power failure, this information can be retransmitted to the RFID 181EIP by using a Put_LOAD command. The checksum of the incoming tag will correspond again with the internal checksum in the filehandler. The process can continue immediately at full transport speed. - Invoking the Get_MOVE command is recommended after a corresponding modification to a directory (checksum change: indicated with bit 6 in the CI byte of the telegram header). Saving system data with Get_MOVE is only recommended if Get_MOVE/Put_LOAD is in general use.


VAR CMD : BYTE := 0x62; (* b *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the TXBUF. It specifies the first address within the memory area where the first byte of the parameter data to be sent is stored. Other parameter data follow consecutively.

Length This parameter specifies the number of bytes to be sent to the Ident Unit starting at the address indicated by the parameter OffsetBuffer. The range is: 0 … 226.

Physical-Read (FH, DA)

This is the command to read data from a transponder using a physical start address and the length of data to be read. The parameter TRLEN of the PIB indicates the number of bytes received.

VAR CMD : BYTE := 0x70; (* p *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the RXBUF. It specifies the first address within the memory area where the first byte of data received has to be stored. All following bytes have to be stored at incremented addresses.


UID = 0: Any (no specific)

The tag currently present is read.

Length This parameter specifies the number of bytes to be read from transponder starting at the address indicated by the parameter StartAddress.

StartAddress This parameter specifies a physical address within the transponder memory.


Write (FH)

This is the command to write data to a file located at the transponder. In case the number of bytes to be written is less than the file length, bytes not overwritten remain unchanged. VAR CMD : BYTE := 0x77; (* w *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the TXBUF. It specifies the first address within the memory area where the first byte of data to be sent is stored.




Offset This parameter specifies the relative offset within the specified file where the data shall be written. Offset = 0xFFFFFFFF:

Append data to the file specified.

Length This parameter specifies the number of bytes to be written to the file.

Put This is the command to write manufacturer specific data to the Ident Unit. The following commands for RFID 181EIP are embedded in the Put telegram: Put_QWRITE: Set up a complete data carrier This command enables individual files to be stored very quickly onto the tag, together with their corresponding contents and attributes. The individual files to be created ( consisting of file name, attribute, file length and data ) are processed sequentially by the filehandler. This means that the filehandler internally first creates a file, then writes data to it and assigns it an attribute. The next file to be created is then processed in the same way. This function can only be performed after the specified MDS has been successfully formatted. Put_LOAD: Transmit system data to filehandler running at the RFID 181EIP. This command can be invoked by the user to transmit data saved with Get_MOVE Command to the filehandler. Following a power failure, a Put_LOAD command should be issued immediately after the Write-Config command. ( only if Put_LOAD/Get_MOVE is in general use.) VAR CMD : BYTE := 0x65; (* e *) END_VAR



OffsetBuffer This parameter specifies the relative offset within the TXBUF. It specifies the first address within the memory area where the first byte of the parameter data to be sent is stored. Other data follow consecutively.

Length This parameter specifies the number of bytes to be sent to the Ident Unit starting at the address indicated by the parameter OffsetBuffer.

Physical-Write (DA)

This is the command to write data to a transponder using a physical start address and the length of data to be written.

VAR CMD : BYTE := 0x71; (* q *) END_VAR






Length This parameter specifies the number of bytes to be send to the transponder starting at the address indicated by the parameter StartAddress.

StartAddress This parameter specifies a physical address within the transponder memory.

Format

(FH, DA)

This command initializes the Initialization of the transponder. After formatting the transponder is ready to be used within the application.

A Security_Code (STRING[8]) has to be placed at the beginning of the parameter block (TXBUF). This code is a manufacturer defined code for protecting the formatting with wrong parameters, randomly formatting or to define the name of the transponder. The TXBUF is used as manufacturer specific area for parameter data needed for the formatting procedure. The RFID 181EIP doesn’t support Security Code. The value must be set to 0. VAR CMD : BYTE := 0x66; (* f *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the TXBUF. It specifies the first address within the memory area where the first byte of the Security_Code to be send is stored. Other data follow consecutively.



The tag currently present is formatted.


Length This parameter specifies the number of bytes to be send to the Ident Unit starting at the address indicated by the parameter OffsetBuffer. It counts the 8 byte Security_Code and the variable number of format parameters. The range is: 8 … 226.

Delete (FH)

This is the command to delete a file from the transponder. Depending on the file system supported the file disappears from the directory or its File-Length and Used-Length are set to zero. Take attention to the file attribute if the file is protected. VAR CMD : BYTE := 0x64; (* d *) END_VAR






Create (FH)

This is the command to create a new file on a formatted transponder.

VAR CMD : BYTE := 0x68; (* h *) END_VAR




FileName This parameter specifies the file to be created. Allowed values: 20h – 7Eh.

Length This parameter specifies the length of the file to be created. Length = 0:

A file with dynamic length will be created. In this case bit 2 of the Attribute must be set to 0.

Attributes BitString (8) valid values: Read/Write unlimited = Bit 0,1 not set Read only = Bit 0 set Write once = Bit 1 set Fixed length = Bit 2 set (the length of the file can not be changed by any command)

FileType This parameter is used to classify/group files according to user specific criteria. Files with the same characteristics are associated to the same group. Consequently they are of the same file type indicated by the same value of the parameter FileType. In case it is not used all bytes of the FileType parameter have to be set to “0x20”. RFID 181EIP does not use the FileType. It must be set to 0x2020.

Update (FH)

This is the command to write data to a file located at the transponder. The file length will become updated exactly to the number of data written. This service is always


applied to a complete file. VAR CMD : BYTE := 0x75; (* u *) END_VAR






Length This parameter specifies the number of bytes to be written to the file.

Next (FH)

This is the command to finish operations regarding one transponder. The next command will be executed when the next transponder is recognized/indicated. VAR CMD : BYTE := 0x6E; (* n *) END_VAR




NextMode valid values: NextMode = 0 (The next command can be applied to each

(another or the same) tag) – not available for the RFID 181EIP

NextMode = 1 (only a different tag will become handled)

Get-Directory (FH)

This is the command to read the directory from a transponder. File names and associated attributes will be delivered. The parameter FileType is used to specify files of a specific type to be delivered. Response data of this command is provided in a structured form within the RXBUF.

Following an example is given to illustrate the construction of the data transferred. It is not intended to be used as Structured Text code within the PLC program. The example represents the transmission of 10 directory elements. VAR CONSTANT FileCount : INT := 10; END_VAR TYPE DIRELEMENTS_STRUCT STRUCT

FileName : ARRAY[1..8] OF BYTE; UsedLength : DINT; Attributes : BYTE; FileLength : DINT; FileType : WORD;

END_STRUCT; END_TYPE


TYPE DIRLIST_STRUCT STRUCT

UID1 : ARRAY[1..8] OF BYTE; TagName : ARRAY[1..8] OF BYTE; FreeUserMem : DINT; CheckSum : WORD; FileCount : INT; FileList : ARRAY[1..FileCount] of

DIRELEMENTS_STRUCT; END_STRUCT; END_TYPE The parameter TRLEN of the PIB indicates the number of bytes received.

VAR CMD : BYTE := 0x6D; (* m*) END_VAR


OffsetBuffer This parameter specifies the relative offset within the RXBUF. It specifies the first address within the memory area where the first byte of data received is to be stored.



FileType This parameter is used to classify/group files according to user specific criteria. Files with the same characteristics are associated to the same group. Consequently they are of the same file type indicated by the same value of the parameter FileType. In case it is not used all bytes have to be set to “0x20”. “?” (0x3F) is used as Wildcard and “?,?” (0x3F,0x3F) means ALL files. RFID 181EIP does not use the FileType. It must be set to 0x2020.

Definition of sub-parameters delivered within the response:


UID1 This parameter identifies a single transponder. UID1=0 indicates that the transponder does not contain a UID.

In case UID=0 was written to the transponder within the command, UID1 responds the UID of the present transponder.

TagName This parameter specifies the name of the tag.

FreeUserMem This parameter specifies the memory space not used at the tag.

Checksum This parameter specifies the Checksum of the directory located at the tag. If not used all byte are set to “0x00”

FileCount This parameter specifies the number of directory entries available at the tag and provided by this command.

FileList This parameter provides the list of directory entries.

FileName This parameter specifies the file accessed.


UsedLength This parameter indicates the memory space used of the complete FileLength.

Attributes BitString (8) valid values: Read/Write unlimited = Bit 0,1 not set Read only = Bit 0 set Write once = Bit 1 set

Fixed length = Bit 2 set (the length of the file can not be changed by any command)

FileLength This parameter specifies the max. length of the file. In case of a dynamic file system “FileLength” and “UsedLength” are identical. RFID 181EIP has a dynamic file system implemented. If File-Length = 00h, the file has been deleted.

FileType This parameter is used to classify/group files according to user specific criteria. Files with the same characteristics are associated to the same group. Consequently they are of the same file type indicated by the same value of the parameter FileType. In case it is not used all bytes of the FileType parameter have to be set to “0x20”. RFID 181EIP does not use the FileType. It must be set to 0x2020.

Set-Attribute (FH)

This is the command to set/change attributes associated to a file. The attributes are stored at the directory.

VAR CMD : BYTE := 0x6F; (* o *) END_VAR






Attributes BitString (8), valid values: Read/Write unlimited = Bit 0,1 not set Read only = Bit 0 set Write once = Bit 1 set

Fixed length = Bit 2 set (the length of the file can not be changed by any command)

FileType This parameter is used to classify/group files according to user specific criteria. Files with the same characteristics are associated to the same group. Consequently they are of the same file type indicated by the same value of the parameter FileType. In case it is not used all bytes have to be set to “0x20”. RFID 181EIP does not use the FileType. It must be set to 0x2020.


Write-Config

(FH, DA) This service is used to modify operation of the Ident Unit except interruption of the communication. It is possible to send new parameters to the Ident Unit (ConfigData). Also a reset can be initiated requesting the Ident Unit to restart operation. The TXBUF is used as manufacturer specific area for config data. Config data are manufacturer specific.

Normally Write-Config is executed automatically by the PIB during INIT. Optionally Write-Config may be started with EXECUTE. Mandatory operation to be supported: Config = 1 Optional to be supported: Config = 2 Or Config = 3 VAR CMD : BYTE := 0x78; (* x *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the TXBUF. It specifies the first address within the memory area where the first byte of data to be sent is to be stored.

Length This parameter specifies the number of config data byte to be written to the Ident Unit.

Config Config = 0 … not allowed Config = 1 … Reset, no ConfigData Config = 2 … not allowed for RFID 181EIP Config = 3 … Reset, ConfigData to be send Config > 3 … reserved


MaxPacketSize This parameter is transmitted from the PIB* to the PIB and provides information about the max. length of the Ident PDU (Ident header + data) the slave device is able to receive or send. The PIB checks the PDU length supported by the PIB* dynamically within the initialization phase (INIT). PIB adapts the internal algorithm for packaging data and align the PDU size.

00 = Default (corresponds to 240 Byte) 64…240 = max. permitted PDU size of within the PIB* 01…63 = reserved 241…255 = reserved RFID 181EIP supports PDU size of 240 Bytes

Read-Config (FH, DA)

This service is used to read config data out of the Ident Unit. The RXBUF is used as manufacturer specific area for config data. Config data are manufacturer specific. The parameter TRLEN of the PIB indicates the number of bytes received. VAR CMD : BYTE := 0x61; (* a *) END_VAR


OffsetBuffer This parameter specifies the relative offset within the RXBUF. It specifies the first address within the memory area where the first byte of data read is to be stored.


Mem-Status (FH, DA)

This service is used to read the status of a tag (battery condition, memory size, type of tag, available capacity, …). The RXBUF is used as manufacturer specific area for status data. Status data are manufacturer specific. The parameter TRLEN of the PIB indicates the number of bytes received. VAR CMD : BYTE := 0x73; (* s *) END_VAR





Attributes This parameter is used to specify the class of information to be read. Valid values are: 0x00…reserved 0x01…not used 0x02…reserved 0x03…reserved 0x04…physical status information ( only RF300) 0x05…file system related status information (only FH) 0x06 – 0x7F reserved 0x80 – 0xFF not used 0x82 only RF300


Dev-Status (FH, DA)

This service is used to read the status of an Ident Unit. The RXBUF is used as manufacturer specific area for status data. Status data are manufacturer specific. The parameter TRLEN of the PIB indicates the number of bytes received. This command is not available for Moby I/E neither for FH nor DA. VAR CMD : BYTE := 0x74 ; (* t *) END_VAR


Attributes This parameter is used to specify the class of information to be read. Valid values are:

0x00… reserved

0x01 – 0x08… not used for the RFID 181EIP

0x09 – 0x7F reserved

0x81… state of the Reader (not used by MOBY I/E)

0x84… UID list (identified tags) (only MOBY U) 0x86 only RF300


Inventory

(FH, DA)

This command is used to request a list of all UID’s currently accessible within the antenna lobe. Vendor specific it is possible to deliver additional information. The RXBUF is structured as follows.

Following an example is given to illustrate the construction of the data transferred. It is


not intended to be used as Structured Text code within the PLC program. The example represents the transmission of 5 objects (ObjectNumber = 5) and ObjectLength = 16. VAR CONSTANT ObjectNumber : INT := 5; ObjectLength : INT := 16; END_VAR TYPE UID_STRUCT STRUCT

UID : ARRAY[1..8] OF BYTE; Data : ARRAY[1..(ObjectLength-8)] OF BYTE;

END_STRUCT; END_TYPE TYPE UidList: ARRAY[1..ObjectNumber] OF UID_STRUCT; END_TYPE VAR CMD : BYTE := 0x69; (* i *) END_VAR


Attributes This parameter is used to specify the information to be read. Valid values are:

0x00…all UID’s are read (without additional information)

0x01 – 0x7F reserved

0x80 – 0xFF not used




ObjectNumber This parameter specifies the number of UID‘s delivered within the acknowledge.

ObjectLength This parameter specifies the number of bytes associated to a single UID (length of UID + additional data). In case of Attributes =0x00 the following applies: ObjectLength = 8.

UidList This optional parameter contains a list of manufacturer specific information associated to the UID’s currently accessible within the antenna lobe.

ObjectNumber This parameter is used to concatenate an object with its barcode information. The barcode reader can put this number into its read result telegram.

In case RPTCMD is active the ObjectNumber is incremented with every single reading procedure.

Value range of this parameter is: 0…1023

After crossing the value of 1023 counting will start with “0”.


5.2 Acyclic Command and Acknowledge Telegram

Telegram heading (always present, coding is dual)

0 1 2/3 4/5 6/7 8/9 10 ... 239 Byte Position

0 0 SN CommandCC CI TDB DBN DBL User data

The user data depend on the command

Length of user data following

Current data block number

Total number of data blocks to be transmitted

Command Index‘A‘ : command from PIB to ident unit

xx : status byte: acknowledgement from ident unit

7 6 5 4 3 2 1 0

1 = Command terminated with error; the user dataContains error information.

1 = vendor specific meaning

1 = RFID: The RAM battery is poor or exhausted.Barcode Reader: vendor specific



1 = vendor specific meaning1 = vendor specific meaning

Command Codex(see command definition,e.g.: „r“ = Read)

sequence number

Reserved (set to „0“)

Reserved (set to „0“)


Byte order:SN Byte0 high Byte

Byte1 low ByteTDB Byte4 high Byte

Byte5 low ByteDBN Byte6 high Byte

Byte7 low Byte

Acyclic Command and Acknowledge Telegram

The meaning of the individual header bytes is as follows:

Meaning of the individual bytes within acyclic command and acknowledge telegram

Name Meaning

SN SN (Sequence Number) is used as a command counter. The counter is incremented each time a new command is issued by the PIB and sent back from the Ident Unit. In case of using Repeat_Command it is incremented with every new acknowledgement telegram (except the first). In case a command contains a sequence of acknowledgements all individual acknowledgements carry the same SN value.


After “INIT” succeeded the sequence number is set to “0”. The “SN” takes the value of “1” for the first command following the initialization procedure.

After the command “SRESET” the sequence number is continuously incremented and NOT reset to “0”.

CMD CMD (Command Codex) is used as an individual identifier for a command to be transmitted from the PIB to the Ident Unit and the corresponding acknowledgement.

CI CI (Command Index) is set to “A=0x41” in case of a command telegram sent to the Ident Unit. In case of the acknowledgement telegram the CI byte is used to transfer status information. The following coding of the CI in the acknowledgement is used: Bit 0: “0” indicates a positive ending of the command. “1” indicates a negative ending.

The following data in the acknowledgement contain error information. Bit 1: Warning: Only used in ECC-mode: data from the MDS has been corrected and are

OK. Bit 2: Warning: The RAM battery of the MDS is poor or exhausted. Bit 3: Warning: Aux. battery is poor or exhausted ( only valid for MDS 507, otherwise

always 1) Bit 4: Warning: MDS was outside the transmission window during command processing. Bit 5: Warning: file read has length 0 or the length to be read is greater than the file. Bit 6: Warning: A MDS with a new directory structure has entered: the bit is set when the

file handler has automatically executed a read operation of the complete MDS directory. In some applications, the new directory can be backed up in the PLC with the Get_MOVE command. The result of the last command will be delayed by the directory operation

Bit 7: reserved ( always 0 ) See also chapter 6 for the recommended embedding of warning information in the error structure.

TDB TDB (Total Number of Data Blocks) indicates the total number of individual data blocks to be transmitted in association to a single command. It is used for flow control of data split into several data packages.

DBN DBN (Data Block Number) is used to identify an individual data package within a sequence of data packages associated to a single command.

DBL DBL is used to indicate the number of bytes following within the user data area of the telegram. The RFID 181EIP is able to handle a DBL length between 0 and 229 bytes. The PIB checks the PDU length supported by the PIB* dynamically within the initialization phase (INIT). The PIB* sends the supported PDU length within the acknowledgement to the “Write-Config” command through the parameter “MaxPacketSize” (header + data). The PIB adapts the internal algorithm for packaging data and align the PDU size.


5.3 Detailed Coding of Command and Acknowledgement telegrams

The following table presents the detailed coding of the individual telegrams. Sequences of data packages are not considered.

Command Telegram coding

Read (FH)

0 0 SN `r` 1 1 35 FileName LengthOffsetÀ`

Command: Read

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0 0 SN `r` 1 1xx DBL

CCStatus DBLDBNTDB0 5 1042/31 8/96/7

Acknowledgement: (≤ 229 Byte)

11..239

UID

12..19

Data

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Get Command: Get

0 0 SN `b` 1 1xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

0 0 SN `b` 1 1 DBL 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Into the general structure of the Get command the following sub-commands are embedded:

Get_QREAD (Read multiple files or the whole tag)

Get_MOVE (Save tag system data from the filehandler to the PLC)

Get_QREAD Read several files or the whole tag with one command

0 1 2/3 4 5 6/7 8/9 10 11..31 32/33 34..45 46 47 CC CI TDB DBN DBL 0 0 SN ‚b’ ‚A’ 1 1 DBL 0 Length 0 ‚F’ ‚E’

48..55 56/57 58..66 67..69 70.. max.239 UID Option reserved Length_of_data from byte

70 to the end Data

8byte 1byte 3byte 2byte File-name

reserv.= 0

F-Length reserved Other file entries


First file entry Length ( Byte 32/33): Length of data in the data field of the PIB command structure ( byte 46 and following) including also further telegram blocks if in use. UID: Tag number. If there is no UID required, this parameter must be set to zero. Option: The option in byte 56/57 has the following meaning:

0x0000 No option. The data contain the file to be read. 0x0002 All files with a length > 0 are read from the tag. “Length_of_data” must be preset

with 0. 0x0004 If the actual file length is greater than the F-Length reserved in the data, there is no

error message. 0x0008 The user data contain the files which are not to be read (i.e.; all files of the data

memory are read expect the files specified in the command). The F-Length parameter in the file entry can be disregarded with this option.

0x0010

The file data read are arranged by word and directly appended to each other (i.e., when a file has an odd-number length, a “skip byte” is added with the value 20hex.) The “skip” parameter then has the value 0001 in the acknowledgement. With this option, the F-Length parameter must always be set to 00FFFFFFhex in the file entries.

0x0022 All files of the tag are read. In contrast to option 02h, the blank files are also read (Length_of_file_data = 0). This option can be used to read a complete tag and then write it to another tag with Put_QWRITE.

The options are bit-coded. Several options can be set at the same time (e.g. 0Ch, 12h, 18h and so on). File entry: Filename: Name of File to read F-Length: Number of byte to be always reserved in the acknowledge telegram for this file entry 0xFFFFFF = Read the whole file; file data are appended without skip bytes in the Acknowledge telegram. 0x00yyyy = The acknowledge telegram always reserves yyyy bytes for this file. If the File contains less than yyyy bytes it is represented in the number of skip bytes Note: - Maximum 12 file entries possible. - The Get_QREAD command cannot be splitted in several telegram blocks, however its acknowledge will be split if the result length exceeds one block Acknowledgement

0 1 2/3 4 5 6/7 8/9 10 11... CC Status TDB DBN DBL 0 0 SN ‚b’ 0 TDB 1 DBL Data

8byte 1byte 3byte 2byte File-name

reserv. = 0

Length_of_ file_data

Number of skip bytes

File data

Skip bytes Other file entries

First file entry Note:

A predefined F-Length in the command together with the “Number of skip bytes” and “skip bytes” garantees that the start address of the read files is always at the same address in the PLC memory. This simpifies the PLC program to find the right data.

Get_MOVE Save system data from the filehandler ( directory, FAT, checksum ) Not used by MOBY U

0 1 2/3 4 5 6/7 8/9 10 11..31 32/33 34..45 46 47 CC CI TDB DBN DBL


0 0 SN ‚b’ ‚A’ 1 1 25h 0 02h 0 ‚F’ M’

Acknowledgement

0 1 2/3 4 5 6/7 8/9 10 11/12 13... CC Status TDB DBN DBL Data 0 0 SN ‚b’ 0 TDB 1 DBL Length

of dataDIR + FAT

Store this data segment for long-term usage with the command Put_LOAD Length of data (Byte 11/12): Length of DIR + FAT + 2 bytes. ( Byte 11/12 included )

Physical-Read (FH, DA)

Command: Physical-Read

0 0 SN `p` 1 1xx DBL

CCStatus DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

0 0 SN `p` 1 1 35 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

StartAddress

34..37

0 00

39 42/4340/41

0

38

0

44..45

Write (FH) Command: Write

0 0 SN `w` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `w` 1 1 DBL FileName LengthOffsetÀ`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Put Command: Put

0 0 SN è` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN è` 1 1 DBL 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Into the general structure of the Put command the following sub-commands are embedded:

Put_QWRITE (Write multiple files or the whole tag)

Put_LOAD (Load tag system data from the PLC to the filehandler)


Put_QWRITE Set up a complete tag.

0 1 2/3 4 5 6/7 8/9 10 11..31 32/33 34..45 46 47

CC CI TDB DBN DBL 0 0 SN ‚e’ ‚A’ TDB 1 DBL 0 Length 0 ‚F’ ‚Q’

48..55 56/57 58..66 67..69 70.. UID Option reserved Length of file

entries File entries

8byte 1byte 3byte 1byte 1byte Number of bytes in

„Length data“

File-name

Attribute F-Length reserved Number of Skipbytes

Data

File entry further file entries Length ( Byte 32/33): Length of data in the data field of the PIB command structure ( byte 46 and following) including also further telegram blocks if in use. UID: Tag number. If not required, it must be set to zero. Option:

0x0000 Default: The Put_QWRITE command overwrites or deletes the file structure.

0x0001 The Put_QWRITE command appends the new file entries to the existing MDS file structure. A check is made to determine whether the file to be created already exists.

Length of file entries: Whole number of data bytes beginning at byte 70 to the end of file entries. ( Also those bytes are included which do not fit in the first telegram block.) File entries: Filename: Name of the file; 8 bytes ASCII; - allowed values: 20h – 7Eh. Attribute: Fileattribute ( 0x00 = no attribute; 0x01 = read only; 0x02 = write once; 0x04 = fixed length) F-Length: Length of Data in the data field. Number of Skipbytes: Number of additional bytes following at the end of file entry until the first byte of the next file entry. Can be used to get alignments in data structure. Data: file data to be written. Acknowledgement

0 1 2/3 4 5 6/7 8/9 10 CC Status TDB DBN DBL 0 0 SN ‚e’ 0 1 1 0

Put_LOAD Transmit system data to filehandler (communication module) Not used by MOBY U

0 1 2/3 4 5 6/7 8/9 10 11..31 32/33 34..45 46 47 48/49 50 .....

CC CI TDB DBN DBL Data 0 0 SN ‚e’ ‚A’ TDB 1 DBL 0 Length 0 ‚F’ L’ Length

of Data

DIR + FAT

Data received with Get_MOVE command


Length ( Byte 32/33): Length of data bytes following, beginning with byte 46; including also further telegram blocks if in use. Length of Data (Byte 48/49): Length of DIR + FAT + 2 bytes. ( Byte 48/49 included ) Acknowledgement

0 1 2/3 4 5 6/7 8/9 10 CC Status TDB DBN DBL 0 0 SN ‚e’ 0 1 1 0

Physical-Write (DA)

Command: Physical-Write

0 0 SN `q` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `q` 1 1 DBL 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

StartAddress

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Format (FH, DA) Command: Format

0 0 SN `f` 1 1xx 0

CC Status DBLDBNTDB0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `f` 1 1 DBL 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Structure of the Data section (from Byte 46):

Direct Addressing Length in PIB Header: 0x0F

1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 0 0 0 0 0 06h

03h 0 Init Value

13 14 15 0 MSB LSB

Byte 1 – 8: Reserved for security code. Always 0, since MOBY does not support a security code. Byte 9: Length of the following partial parameter (hexadecimal, here 06h). Byte 10: Always 03h. Byte 11: Always 0. Byte 12: default value for initializing tag memory (hex) Byte 13: Always 0. Byte 14: End address + 1 of tag High Byte (hex) Byte 15: End address + 1 of tag Low Byte (hex)


Example: 0, 0, 0, 0, 0, 0, 0, 0, 06h, 03h, 0, 0, 0, 80h, 0 ( for 32k tags )

File Handler Length in PIB Header: 0x15

1 2 3 4 5 6 7 8 9 10 - 17 0 0 0 0 0 0 0 0 0Ch Volume

18 19 20 21 MDS-Typ Option 0 0

Byte 1 – 8: Reserved for security code. Always 0, since MOBY does not support a secuity

code. Byte 9: Length of the following partial parameter (hexadecimal, here 0Ch). Byte 10 - 17: Tag name (8 ASCII characters Value range: 20hex to 7Ehex ) Byte 18: Tag type. ( ECC only used by MOBY I )

04h, 84h 2 kByte, 2 kByte with ECC 05h, 85h 8 kByte, 8 kByte with ECC 06h, 86h 32 kByte, 32 kByte with ECC

Byte 19: Option

0000xxx0B 0000xxx1B

Read always Directory + FAT Checksum switched on

0000xx0xB 0000xx1xB

Erase whole tag Directory + FAT are preserved, data area is erased

0000x0xxB 0000x1xxB

Erase whole tag Directory + FAT are erased, data area is preserved

00000xxxB 00001xxxB

normal The counters for write cycles respectively ECC-corrections are preserved. Even if the system area is defective the counters stay also preserved (i.e. ECC-errors)

Byte 20: always set to 0. . Byte 21: always set to 0. example: 0, 0, 0, 0, 0, 0, 0, 0, 0Ch, 20h, 20h, 20h, 20h, 20h, 20h, 20h, 20h, 06h , 01h,

00h, 0 ( for 32k tags, without ECC)


Create (FH) Command: Create

0 0 SN `h` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `h` 1 1 DBL FileName Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

Attributes

38

FileType

44..45

Data

46...239

Delete (FH) Command: Delete

0 0 SN `d` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `d` 1 1 35 FileName 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Update (FH) Command: Update

0 0 SN ù` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN ù` 1 1 DBL FileName Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

Next (FH) Command: Next

0 0 SN `n` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN `n` 1 1 35 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

NextMode 00

39 42/4340/41

0

38

0

44..45


Get-Directory (FH)

Command: Get-Directory

00 00 SN `m` 0001 0001xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

00 00 SN `m` 0001 0001 23h 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

FileType

44..45

11-18 19-26

27-30 31-32 33-34 35-42 43-46 47 48-51 52-53 ..

UID Tag- name

free user memory

Check- sum

File- count

File- name

Used length

Attr. File- length

File- type

Directory entry further directory entries

See chapter 5.1 for more details.

Set-Attribute (FH) Command: Set-Attribute

0 0 SN ò` 1 1xx 0

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

0 0 SN ò` 1 1 35 FileName 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

Attributes

38

FileType

44..45

Write-Config (FH, DA)

Command: Write-Config

0 0 SN `x` 1 1xx 1

CC Status DBLDBNTDB

0 5 10 1142/31 8/96/7

Acknowledgement:

0 0 SN `x` 1 1 DBL 0 Length0À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

Config

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239

MaxPacketSize

Structure of the Data section (from Byte 46):

Direct Addressing Length in PIB Header: 0x0B MOBY I/E

1 2 - 5 6 7 8 9 10 11 04h res. 05h 0 0 T-sample Param Opt1


Byte 1: Length of the following partial parameter (hexadecimal, here 04h). Byte 2 - 5: Always 0 Byte 6: Length of the following partial parameter (hexadecimal, here 05h). Byte 7: Always 0 Byte 8: Always 0 Byte 9: Sampling rate

Byte 10: Parameter

Byte 11: Optional

example.: 05h, 0, 0, 0, 0, 05h, 0, 0, 0, 21h, 0 (MOBY I with attendance check)

Length in PIB Header 10h MOBY D/U/RF300

1 2 - 5 6 7 8 9 10 04h res. 0A 0 0 Standby Param

11 12 13 - 14 15 16 Opt1 dili Number of

MDS fcon ftim

Byte 1: Length of the following partial parameter (hexadecimal, here 04h) Byte 2 – 5: always 0 reserved Byte 6 : Length of the following partial parameter (hexadecimal, here 0Ah) Byte 7: Always 0 Byte 8: Always 0 Byte 9: Standby

00 hex = no Standby 01 hex ... C8 hex = 7 ms ... 1400 ms Standby time

Byte 10: Parameter


Byte 11: Optional Byte 12: Distance_limiting

05; 0A; 0F; 14; 19; 1E; 23 hex = 0.5; 1.0; 1.5; 2.0; 2.5; 3.0; 3.5 m (MOBY U) 85; 8A; 8F; 94; 99; 9E; A3 hex = ditto with reduced sending capacity (MOBY U) 02 ... 10 ... 28 hex = 0.5 W ... 4 W ... 10 W (MOBY D)

Byte 13 - 14: Number of detectable data media( max. 12 at MOBY-U ) Byte 15: Field_ON_control proximity switch mode

00 hex = No proximity switches 01 hex = field_ON_time_ switches the field off 02 hex = 1st prox. switch turns on the field 2nd prox. switch turns off the field

Byte 16: Field_ON_time 00 hex = No proximity switches 01 hex ... FF hex = 1 to 255 sec switch–on time for the SLG field

example.: 04h, 0, 0, 0, 0, 0Ah, 0, 0, 0, 25h, 0, 0Fh, 0, 01h, 0, 0 (MOBY U with attendance check)

File Handler Length in PIB Header: 0x0D MOBY I

1 2 - 5 6 7 8 9 10 - 11 04h res. 07h

0 MDS_IO_CONTROL

(EAKO) ECC SLG-Nr

12 13 Prior

0 (Blockl)

Byte 1: Länge Length of the following partial parameter (hexadecimal, here 04h) Byte 2 – 5: Always 0 reserved Byte 6 : Length of the following partial parameter (hexadecimal, here 07h). Byte 7: Always 0 Byte 8: MDS_IO_CONTROL determines the method of an Entry/Exit check of an MDS/Tag in an SLG/Reader Field will be used.

In case of multitag, MDS_IO_CONTROL has to be set to 1. Byte 9: 31hex -> ECC on

MOBY U/D, RF300, RF600 – without multitag


30hex -> ECC off Byte 10 - 11: Number of the SLG-Station (reader). This number is written to the tag before each processing operation. This enables the filehandler to recocnize if a “new MDS” has actually entered the field. The user has to ensure that every SLG/Reader has a different value for each use of the SLG parameter. 0001hex – FFFEhex: Normal operating mode. FFFFhex: Test function: The SLG/reader number will not be evaluated by the filehandler. The entry/exit monitoring can thus only be tested with one reader/SLG and one tag/MDS. The same tag can return to the transmission window of a reader repeatedly and will be processed. Byte 12: Always 0 Byte 13: Always 0 example: 04h, 0, 0, 0, 0, 07h, 0, 34h, 30h, FFh, FFh, 0x0, 0h ( MOBY I without ECC, EAKO 4, without sampling interval )

Length in PIB Header: 0x13 MOBY U

1 2 - 5 6 7 8 9 10 - 11 12 04h res. 0Dh

0 MDS_IO_CONTROL

(EAKO) ECC SLG-

Number Prior

13 14 15 16 - 17 18 19 0 (max. Length)

Standby ( Scanning Time )

dili Number of Tags fcon ftim

Byte 1: Length of the following partial parameter (hexadecimal, here 04h) Byte 2 – 5: Always 0 reserved Byte 6 : Length of the following partial parameter (hexadecimal, here 0Dh). Byte 7: Always 0 Byte 8: MDS_IO_CONTROL determines the method of an Entry/Exit check of an MDS/Tag in an SLG/Reader field will be used.

In case of multitag, MDS_IO_CONTROL has to be set to 1. Byte 9: 31hex -> ECC on 30hex -> ECC off Byte 10 - 11: Number Number of the SLG-Station (reader). This number is written to the tag before each processing operation. This enables the filehandler to recocnize if a “new MDS” has actually entered the field. The user has to ensure that every SLG/Reader has a different value for each use of the SLG parameter. 0001hex – FFFEhex: Normal operating mode. FFFFhex: Test function: The SLG/reader number will not be evaluated by the


filehandler. The entry/exit monitoring can thus only be tested with one reader/SLG and one tag/MDS. The same tag can return to the transmission window of a reader repeatedly and will be processed Byte 12: Always 0 Byte 13: Always 0 Byte 14: Standby time of tags: Scanning time. If the tag receives an additional command before the Scanning Time has expired the command will be executed immediately, otherwise there will be a time delay according to the sleep_time value of the tag. Scanning_time should only be set when both of the following conditions exists: - One command after another is executed on the same MDS and - Command execution must be concluded within a minimum time

00 hex = no Standby 01 hex ... C8 hex = 7 ms ... 1400 ms Standby time

Attention: Scanning_time affects the lifetime of the battery: The longer the scanning_time, the shorter the life of the battery. For calculations see the MOBY U manual for configuration, mounting and service. Byte 15: Distance_limiting

05; 0A; 0F; 14; 19; 1E; 23 hex = 0.5; 1.0; 1.5; 2.0; 2.5; 3.0; 3.5 m (MOBY U) 85; 8A; 8F; 94; 99; 9E; A3 hex = ditto with reduced sending capacity (MOBY U)

Byte 16 – 17: Number of detectable data media ( max. 12 at MOBY-U ) Byte 18: Field_ON_control proximity switch mode. switch antenna field on/off automatically. The command “ antenna ON/OFF” is suppressed in proximity switch mode.

00 hex = No proximity switches 01 hex = One ore two proximity switches. The proximity switches have a logical OR link. During the time a proximity switch is activated, the field is turned on. 02 hex = One ore two proximity switches. The 1st proximity switch turns on the field while the 2nd proximity switch turns off the field. When two proximity switches exists and a field_ON_time is parametereized, the field is automatically turned off if the 2nd proximity switch doesn’t react within this prox. switch time. If no field_ON_time is parameterized, the field remains on until the 2nd prox. switch is activated.

Byte 19: Field_ON_time

00 hex Time monitoring is off. The 2nd prox. switch is needed to turn off the field. 01 hex ... FF hex = 1 to 255 sec switch–on time for the SLG field

example: 04h, 0, 0, 0, 0, 0Dh, 0, 34h, 30h, FFh, FFh, 0h, 0, 0, 0Ah , 0, 0Ch, 0, 0

Read-Config (FH, DA)

Command: Read_Config

0 0 SN à` 1 1xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

0 0 SN à` 1 1 35 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

The Data area contains the configuration data, written via Write-Config to the module.


Mem-Status (FH, DA )

Command: Mem-Status

0 0 SN `s` 1 1xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

0 0 SN `s` 1 1 35 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

Attributes

38

0

44..45

Structure of the data in the acknowledgement by use of attribute 04h. Only RF300

Structure of the data in the acknowledgement by use of attribute 05h. Only MOBY I/U, RF300 Filehandler



Dev-Status (FH, DA)

Not available for Moby I/E

Command: Dev-Status

0 0 SN `t` 1 1xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

11..239

Data

0 0 SN `t` 1 1 35 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

0

11

0

34..37

0 00

39 42/4340/41

Attributes

38

0

44..45


Structure of the data in the acknowledgement by use of attribute 81h.

available for RF300, MOBY U / D and MOBY U Filehandler

Structure of the data in the acknowledgement by use of attribute 84h. Only MOBY U ( FH and DA )



Inventory (FH, DA)

Command: Inventory

00 00 SN `l` 0001 0001xx DBL

CC Status DBLDBNTDB

0 5 1042/31 8/96/7

Acknowledgement:

15..239

DataObjectNumber ObjectLength

11/12 13/14

00 00 SN `l` 0001 0001 23h 0 00À`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

0

12..19

0

11

0

34..37

0 00

39 42/4340/41

Attributes

38

0

44..45

Negative Acknowledgement for all commands

0 0 SN CC 1 1 4

CCStatus DBLDBNTDB

0 5 1042/31 8/96/7

Negative Acknowledgement:

Function_Num

11

7 6 5 4 3 2 1 0

1 = Command terminated with error; the user dataContains error information.


1 = RFID: The RAM battery is poor or exhausted (alwaysset for EEPROM MDS).Barcode Reader: vendor specific



1 = vendor specific meaning1 = vendor specific meaning


Error_Decode

12

Error_Code_1

13

Error_Code_2

14

Coding according to THIS profile

In case data do not fit into a single telegramm data must be split into several blocks and transmitted sequentially. The coordination of this transmission is managed by using TDB and DBN. After all packages are transmitted the command is completed. Below an example is provided for the Write and Read commands. These principle procedures shall be applied to other commands analogical.


5.4 Hints for programming

1. There are 3 places to specify a ‘Length’ for a PIB command.

o Byte 10 – DBL: To specify the following number of bytes in this specific telegram (max. 229 (#E5)).

o Byte 32-32 – Length: Length to specify the number of all data bytes of a command. This length may exceed the max. telegram length of 240 bytes in the case of chained write or read commands. The maximum is 192 (#C2) bytes for a ‘single command’ or the size of the tag in bytes for ‘chained commands’.

o The length of the ‘Source element’ of a MSG-Instruction: The ‘Source Length’ must be greater or equal to the number of bytes contained in the telegram.

Misaligned lengths parameters are the major Malfunction source.

2. Offset parameter: The offset parameter uses only the lower 2 bytes (Byte 30 and 31) are used for the available tag sizes. The upper 2 bytes are not used (Byte 28 and 29).

3. Parameterization after the communication connection is lost. After the communication connection has been lost, the RFID 181EIP does an internal reset (the ERR_1 and the ERR_ 2 LEDs are flashing synchronously). The RFID 181EIP then expects a new Parameter Telegram (routine PIBXX_PARAMETERIZATION) and a following Write-Config telegram (routine PIBX_Initialization) for each channel.

0 0 SN `w` 1 1 DBL FileName LengthOffsetÀ`

CC CI DBLDBNTDB

0 20..275 1042/31 8/96/7 32/3328..31

UID

12..19

0

11

0

34..37

0 00

39 42/4340/41

0

38

0

44..45

Data

46...239


6. Error and Warning Concept The status byte ( CI ) in the acknowledgement (Byte 5) indicates if the requested command was performed successfully or not. If Bit 0 in the status byte is set to “1”, the telegram is a negative acknowledgement and the data contains error information.

The error indication is typically used for two purposes: • To change the reaction to the process i.e. to implement a substitute reaction

e.g. to repeat the request at another time or another place or to abort the process task.

• To issue an alarm message to a HMI system by the application program or by the PLC system automatically.

NOTE: In case 1 only a very few different reactions dependent on the indicated error are typical. Detailed error information is rarely used.

As the PLC application uses other FB’s (Communication FB’s) and functions, there will happen error messages according the communication description of the PLC manufacturer.

6.1 Structure of the error/status information The structure of the error/status information is shown in the following table. This structure presents additional error sources beyond the RFID 181EIP like PLC, Network or vendor specific issues.

The four bytes of information can be packed into a DWORD or array structure.

Byte

Name Date type

0 Function_Num byte

1 Error_Decode byte

2 Error_Code_1 byte

3 Error_Code_2 byte

• Byte 0 (function numbers refers to Byte 11 in the acknowledgement )

The function_Num byte is used as defined in IEC 61158-6 and IEC 61158-4 respectively. Bit 7 set to 1 means there is a response with error. Bit 6 to 5 are always set for PIB specific errors in this case. Bit 4 notices if there are warnings. See Error_Code_2 below. Bits 0.3 to 0.0 indicate which components of the RFID system report the error (status). See next chapter for error numbers.

• Byte 1 (error decode refers to Byte 12 in the acknowledgement )


The RFID 181EIP uses only the value 0xFE for this byte. This means it is a profile specific error. Values from 0x82 to 0x8F can be used by the PLC programmer to specify errors allocated by the PLC.

• Byte 2 (error code 1 refers to Byte 13 in the acknowledgement )

See next chapter for error numbers.

• Byte 3 (error code 2 warnings refers to Byte 14 in the acknowledgement ) This byte has two different meanings, depending on bit 4 in the Function_Num byte: - Bit 4 = 0 -> vendor specific information. RFID 181EIP replies always 0. - Bit 4 = 1 -> warnings information. RFID 181EIP replies always 0. Note: RFID 181EIP replies warnings in the CI byte of the acknowledgement telegram. See chapter 5.2

Example:

6.2 Error messages

6.2.1. Errors from the communication module / reader The causes of these errors can include: • Communication between the RFID 181EIP and the reader/write/read device or

between the reader/write/read device and the tag contains errors. • The RFID 181EIP is unable to process the command. Byte 14 of the negative acknowledgement is not relevant for the error messages.


With certain error messages of the RFID 181EIP, the ERR-LED also flashes (see both tables below).

Evaluation of the ERR-LED in normal addressing

Flashing of ERR LED

Errors that have occurred

1x No error RFID 181EIP has executed a startup and is waiting for a WRITE-CONFIG.

2x Presence error/processing error 3x Error in the connection to the reader / write/read device, write/read device does

not answer. 4x Error in tag memory ( tag not initialized ) 5x Unknown command 6x Field disturbance on reader 7x Too many transmit errors 8x CRC sending error 9x Only during tag initialization: CRC error during acknowledgment receipt from tag

10x Only during tag initialization: Tag is unable to perform the initialization command. 11x When formatting, the tag must be in the transmission window of the reader,

otherwise a timeout error will occur. 12x The tag memory cannot be write-accessed. 13x Address error on tag 14x ECC error (only possible when ECC_mode = TRUE) 16x NEXT-command not possible or not permitted 18x Internal communication error of the RFID 181EIP 19x RFID 181EIP / reader Moby U does not have enough buffers to store the

command intermediately. 20x Internal monitoring error of the RFID 181EIP 21x Incorrect parameter command 22x PIB_command cannot be executed with the RFID 181EIP parameters 23x Communication error 25x Buffer overflow.

A WRITE-CONFIG with Config = 3 is necessary. 28x The antenna of the reader is turned off. A tag command to the RFID 181EIP was

started in this state. 30x Error when processing the command. Wrong telegramm

Evaluation of the ERR-LED with file handler

Flashing of ERR LED


1x The file handler will now only accept a WRITE-CONFIG command with Config = 3. 2x During certain important operations (e.g. writing to the system area of the tag, format tag),

the tag must not exit the transmission window of the reader, since otherwise this error would cancel the command.


Flashing of ERR LED


3x Error in the connection to the reader / write/read device 4x The tag signals a memory error. 5x The commands FORMAT or PHYSICAL-READ have been issued with incorrect

parameters. The physically accessed address is not available on the tag (tag memory is smaller than specified in the command).

6x Field disturbance on reader 7x Too many transmit errors 8x CRC sending error 9x Field disturbance on reader 10x Tag is unable to perform the FORMAT command. The tag is defective. 11x When formatting, the tag must be in the transmission window of the reader, otherwise a

timeout error will occur. 12x The tag memory cannot be write-accessed. Probably not initialized tag. 13x The commands FORMAT or PHYSICAL-READ have been issued with incorrect


14x ECC error (only possible when ECC_mode = TRUE) 15x The file handler is not working correctly. 18x Internal communication error of the RFID 181EIP

• Hardware is defective • Carry out a restart

20x Internal overflow of the RFID 181EIP; stack overflow; diagnostics not functioning Send WRITE-CONFIG or complete restart Switch RFID 181EIP off and on again. Check parameter command

21x Incorrect parameter command 30x Corrupt message frame from reader / write/read device


Error messages from RFID181_EIP / reader via the negative acknowledgement

Byte 0 1 2

Description

In the case of normal addressing: The tag memory cannot be write-accessed. • Tag memory is defective. • EEPROM tag has been overwritten too frequently and has reached the end of its

service life

E1h FEh 01h

In the case of file handler: The tag memory cannot be write-accessed. • Tag has a smaller memory than specified in the FORMAT command, that is,

parameterize the tag type correctly • Tag memory is defective. • EEPROM tag has been overwritten too frequently and has reached the end of its

service life In the case of normal addressing: Presence error: The tag has moved out of the transmission window of the reader / write/read device. The command was executed only partially. Read command: No data are transmitted to the RFID standard profile. Write command: The tag which just left the field contains an incomplete data record. • Operating distance from reader / write/read device to tag is not being maintained. • Configuration error: The data record to be processed is too large (in dynamic

mode) The next command is automatically executed on the next tag. A read, write or NEXT command is possible. • With timeout: No tag in field

E1h FEh 02h

In the case of file handler: During certain important operations (e.g. writing to the system area of the tag, format tag), the tag must not exit the transmission window of the reader, since otherwise this error would cancel the command. • Start command again • Tag is in the boundary area of the write/read device transmission window In the case of normal addressing: Address error The address area of the tag is exceeded. • Starting address of the command start has been incorrectly issued • The tag is not the right type. • RF300: Attempted write access to write-protected areas

(Address area FF00 … FF90)

E1h FEh 03h

In the case of file handler: • The commands FORMAT or PHYSICAL-READ have been issued with incorrect


• With READ/WRITE/UPDATE: Branching to the FAT is defective; it is shown on a block that is not available on the tag.

• Address error. The address area of the tag is exceeded (the tag is not of the right type)

• The logically accessed address is outside the file. There is an error in the FAT. The tag must be reformatted.

• A FAT block follow-on error has been detected in the READ or WRITE command. The block branching table (FAT) is defective. The tag must be reformatted.

E1h FEh 04h In the case of normal addressing: Only during initialization: Tag is unable to perform the initialization command. • Tag is defective


In the case of file handler: Tag is unable to perform the FORMAT command. The tag is defective.

E1h FEh 05h In the case of file handler: WRITE command: Insufficient memory available on the tag The data are not fully written to the tag. CREATE command: No data block can be reserved for a file when it is created. No further blocks are free In the case of normal addressing: Error in the tag memory The MDS has never been write-accessed or has lost the contents of its memory due to battery failure. • Replace tag (if battery bit is set). • Initialize tag with the handheld • Re-initialize tag

E1h FEh 06h

In the case of file handler: • Tag reports a memory error

The tag has never been write-accessed or has lost the contents of its memory due to battery failure (not with EEPROM tag). 1. Replace tag or battery (if battery_low is set). 2. Test tag by attempting to initialize it with the handheld 3. Format tag with FORMAT

• The tag could not be identified by the file handler. The tag must be reformatted. E1h FEh 07h With normal addressing and file handler:

ECC error (only possible if ECC_mode = TRUE) The data cannot be read by the tag. • Data of the tag have been lost (tag defective). • Tag has not been formatted with ECC driver

→ Reformat tag • Tag with EEPROM has reached the end of its service life; the data have been lost.

→ Replace tag • When overwriting, the tag was moved out of the field

→ The tag is not correctly positioned • Command to RFID 181EIP was issued incorrectly by user. In the case of normal addressing: The tag in the field does not have the expected UID or has no UID.

E1h FEh 08h

In the case of file handler: The wrong UID has been entered in the command or the tag with the UID entered in the command is not (or no longer) in the filed. • Application error; check UID in the command


E2h FEh 01h With normal addressing and file handler: • Field interference on the reader

The reader / write/read device is receiving interference from its environment. 4. External interference field; the field of interference can be verified with the

"inductive field indicator" of the handheld. 5. The distance between two readers / write/read device is too small and does

not correspond to the configuration guidelines 6. The connecting cable to the reader / write/read device is defective or too long

or does not comply with the specification 7. MOBY U: MDS has left the field during communication. 8. MOBY U: Communication between the write/read device and the MDS was

terminated by interference (e.g. person/foreign body moving between reader / write/read device and MDS).

• Too many transmission errors The tag was not able to correctly receive the command or the write data from the RFID 181EIP even after several attempts. 9. The tag is positioned exactly on the boundary of the transmission window. 10. Data transmission to the tag is being affected by external interference.

• CRC sending error 11. The receiver monitor has detected at least one fault during transmission.

(Cause as for field interference on the reader / write/read device) 12. The tag reports CRC error frequently (tag is positioned on the boundry of the

reader / write/read device; tag and/or reader / write/read device has/have a hardware defect)

• Only during initialization: CRC error on receipt of acknowledgement from tag (cause as for field interference on the reader / write/read device)

• When formatting, the tag must be in the transmission window of the reader / write/read device, otherwise a timeout error will occur, that is: 13. The tag is positioned exactly on the boundary of the transmission window 14. The tag needs too much current (defect) 15. EEPROM tag for FORMAT incorrectly parameterized

• on MOBY I with MDS 507: 16. Check MOBY_mode and scanning_time parameters 17. Dialog battery is discharged (check Bit LR_bat; measuring voltage on battery)

In the case of normal addressing: There are more tags in the transmission window than the reader / write/read device can process simultaneously (only 1 tag can be processed at any time with the RFID standard profile).

E2h FEh 02h

In the case of file handler: The number of tags in the field is higher than the parameterized number of tags of "multitag". • Remote the excess tags in the field • The configuring of distance_limiting has been incorrectly set • Search the vicinity of the reader / write/read device for a tag that happens to be in

the field • With MOBY I, generally only one tag can be processed

E3h FEh 02h In the case of file handler: • The file accessed by a command (e.g. WRITE) is not available in the directory.

The file has to be created with CREATE. • Check filename (possibly not in ASCII format)

E3h FEh 03h In the case of file handler: • The type of tag present before the reader / write/read device does not match the

ECC mode set. The MDS must be reformatted in accordance with the desired ECC mode.

• The tag is not a file handler tag; format tag


E3h FEh 04h In the case of file handler: There is no longer a directory entry free. The file specified in the CREATE command can no longer be created.

E3h FEh 05h In the case of file handler: The file specified in the CREATE command already exists in the directory (double names not permissible).

E3h FEh 06h In the case of file handler: • The tag has been locked with the help of the COVER command. A write command

(e.g. UPDATE, CREATE) must not disturb the tag layout and is thus rejected. • Write access (WRITE, UPDATE or DELETE) to a file that must not be modified

(protected with an appropriate attribute) In the case of normal addressing: Short circuit or overload of the 24 V outputs (DQ, error code, presence) • The affected output is turned off. • All outputs are turned off when total overload occurs. • A reset can only be performed by turning the 24 V voltage off and on again. • Then start WRITE-CONFIG

E4h FEh 01h

In the case of file handler: Fault in voltage suppply In the case of normal addressing: • Error in the connection to the reader / write/read device; reader / write/read device

does not answer. 18. Cable between RFID 181EIP and reader is wired incorrectly or cable break. 19. The 24 V supply voltage is not connected or is not on or has failed briefly. 20. Automatic fuse on the RFID 181EIP has blown. 21. Hardware defect 22. Another reader / write/read device is in the vicinity and is active. 23. Execute WRITE-CONFIG after error correction

• The antenna of the reader is turned off. A tag command to the RFID 181EIP was started in this state. 24. Turn on the antenna with the command "antenna on/off." 25. The antenna is turned on (off) and has received an additional turn-on (turn-off)

command.

E4h FEh 03h

In the case of file handler: • Error in the connection to the reader / write/read device:

This error is not indicated when starting system commands (WRITE-CONFIG, NEXT, DEV-STATUS, MEM-STATUS). 26. Cable between RFID 181EIP and reader is wired incorrectly or cable break. 27. The 24 V supply voltage is not connected or it has been switched off. 28. Automatic fuse on the RFID 181EIP has blown. 29. Hardware defect

• Antenna not switched on, or SET-ANT = ON with already switched-on antenna 30. User error; note order of commands

In the case of normal addressing: RFID 181EIP / reader Moby U does not have enough buffer to store the command intermediately.

E4h FEh 04h

In the case of file handler: Buffer overflow in the driver of the RFID 181EIP / reader; system-internal error • Execute WRITE-CONFIG of the RFID 181EIP


In the case of normal addressing: NEXT-command not possible or not permitted • RFID 181EIP works without tag control (MDS_IO_CONTROL = 0.1). • RFID 181EIP has already received a NEXT command. • RFID 181EIP or reader / write/read device doesn't recognize NEXT command.

E4h FEh 06h

In the case of file handler: The started command is not permissible (not defined). • Correct the command parameter in the call In the case of normal addressing: Startup message from RFID 181EIP. The RFID 181EIP was off and has not yet received a WRITE-CONFIG command. • Execute a WRITE-CONFIG

E4h FEh 07h

In the case of file handler: Unmotivated startup message of the tag driver in the RFID 181EIP • Execute WRITE-CONFIG of the RFID 181EIP

E4h FEh 08h A currently processed command was canceled by an initialization (Write-Config) In the case of normal addressing: • Communication error between RFID standard profile and RFID 181EIP.

Handshake error. 31. Check the RFID standard profile command which caused this error. 32. Start WRITE-CONFIG command after error correction.

E4h FEh 8Ch

In the case of file handler: Checksum error on the RFID 181EIP In the case of normal addressing: • Internal communication error of the RFID 181EIP

33. Connector contact problem on the RFID 181EIP 34. Hardware of the RFID 181EIP has a defect; → Send in RFID 181EIP for repair35. Start WRITE-CONFIG command after error correction.

• Internal monitoring error of the RFID 181EIP 36. Program execution error on the RFID 181EIP 37. Turn power of the RFID 181EIP off and on again. 38. Start WRITE-CONFIG command after error correction. 39. MOBY U: Watchdog error on the reader.

E4h FEh 8Dh

In the case of file handler: • Internal driver error of the RFID 181EIP; communication fault between file handler

and tag driver (AB byte) 40. Execute WRITE-CONFIG of the RFID 181EIP

• The file handler is not working correctly. 41. Check command structure or command sequence 42. The hardware of the communication module (firmware) has a defect

• Operating system error (AMOS mailbox) 43. Execute WRITE-CONFIG of the RFID 181EIP

• Operating system error; watchdog error in the RFID 181EIP or reader 44. Execute WRITE-CONFIG of the RFID 181EIP

E4h FEh 8Eh In the case of normal addressing: Running command canceled by WRITE-CONFIG or bus connector removed • Communication with the tag was terminated by WRITE-CONFIG. • This error can only be reported on WRITE-CONFIG or cancel


In the case of file handler: Communication error between file handler and tag driver; the tag driver reports cancellation of WRITE-CONFIG although the file handler does not process WRITE-CONFIG commands • Execute WRITE-CONFIG of the RFID 181EIP

E5h FEh 01h With normal addressing and file handler: Incorrect sequence number order (SN) in the RFID 181EIP In the case of normal addressing: Invalid data block number (DBN) in the RFID 181EIP

E5h FEh 04h

In the case of file handler: The message frame control parameters (DBN or command code) do not come in the correct order. Two or more message frames are written to the same RFID 181EIP. • Check the communication module_address and parameter command • Do not execute the command start with the function "Modify variable" In the case of normal addressing: Invalid data block length (DBL) in the RFID 181EIP

E5h FEh 06h

In the case of file handler: The data block from the reader / write/read device is too long . • The "block length" parameter in the WRITE-CONFIG command is too long (RFID

standard profile error or user error) • Program execution error in the reader / write/read device • Execute complete restart of the RFID 181EIP and restart the command In the case of normal addressing: Previous command is active or buffer overflow The user sent a new command to the RFID 181EIP although the last command was still active. • Active command can only be terminated with a WRITE-CONFIG. • Before a new command can be started, the DONE bit must be 1; exception:

WRITE-CONFIG. • Two RFID standard profile calls are using the same pointer. • Start WRITE-CONFIG command after error correction. • When command repetition (e.g., fixed code tag) is used, no data are fetched from

the tag. The data buffer on the RFID 181EIP has overflowed. Tag data have been lost.

E5h FEh 08h

In the case of file handler: • The file handler is currently executing a command. A WRITE-CONFIG must be

executed urgently. • Communication error; driver is active while a new command is sent

45. Check command sequences in the application 46. Execute complete restart of the RFID 181EIP

In the case of normal addressing: Unknown command RFID standard profile transfers an uninterpretable command to the RFID 181EIP. • "PIB_COMMAND" contains invalid command parameters • "PIB_COMMAND" has been overwritten by the user • The tag has reported an address error.

E6h FEh 01h

In the case of file handler: Communication error between file handler and tag driver; the driver on the RFID 181EIP does not recognize the command from the file handler. • Execute WRITE-CONFIG of the RFID 181EIP

E6h FEh 02h In the case of normal addressing: Invalid command index CI


In the case of file handler: Invalid command index CI In the case of normal addressing: • Incorrect parameterization of the RFID 181EIP

47. Check INPUT parameters in the FB 101/116/132 48. Check parameter command 49. WRITE-CONFIG command has been incorrectly parameterized 50. After a startup, the RFID 181EIP has still not received a WRITE-CONFIG.

• Error when processing the command 51. The data in "PIB_COMMAND" contain errors (e.g. WRITE command with

length = 0); check "PIB_COMMAND" and execute WRITE-CONFIG 52. RFID 181EIP hardware defective: RFID 181EIP receives incorrect data during

WRITE-CONFIG. 53. AB byte does not comply with the user data length

E6h FEh 03h

In the case of file handler: • Impermissible receive ID

54. System error; cannot occur with RFID standard profile • The commands FORMAT, CREATE, WRITE, ATTRIB, UPDATE, COVER,

QUEUE-READ or QUEUE-WRITE have been transmitted with impermissible parameters. 55. FORMAT with impermissible tag name or tag type 56. CREATE with impermissible filename 57. WRITE/UPDATE with length 0 (DLNG=0) 58. Attribute impermissible 59. QUEUE-WRITE or QUEUE-READ with impermissible option or number of files60. COVER with impermissible user (only 0 or 1 permissible)

• The system data transferred by the LOAD command are incorrect. 61. DLNG in LOAD incorrectly parameterized 62. Incorrect data block specified or wrongly parameterized 63. MOVE command incorrectly executed; DIR + FAT on the tag does not match

checksum • The MOVE command cannot be executed. The checksum does not match

DIR + FAT. The data memory has apparently exited the transmission window during execution of system operations (e.g. write DIR + FAT).

• MOBY U: The LOAD and MOVE commands are not supported • A WRITE-CONFIG has been executed by the RFID standard profile with

impermissible parameters. The cause of the error is located in the user program. • COVER command:

The tag name specified in the command does not agree with the actual tag name. • QUEUE-READ command:

Specified file length less than actual file length • QUEUE-READ command:

The skip calculated by the file handler is greater than 0FFFh • QUEUE-WRITE command has been incorrectly parameterized

(DAT_DB_number/DAT_DB_address or length)

Option 0000h:

The file entry parameterized in DAT_DB_number with the number xxx or xxx + 1 contains error(s). Counting of the file entries in DAT_DB_number begins with 1.

Option 0001h:

The file entry parameterized in DAT_DB_number with the number xxx or xxx + 1 contains a filename that already exists on the tag. Counting of the file entries in DAT_DB_number begins with 1.

Note: The file entries are incremented in decimal.


In the case of normal addressing: • Presence error: A tag has passed by a reader / write/read device without being

processed by a command. • Processing error: Command processing of a tag (read and/or write) has not been

concluded with NEXT.

This error message is not reported immediately. Instead, the communication module waits for the next command (read, write, NEXT). This command is immediately replied to with this error. This means that a read or write command is not processed. The next command is executed normally by the RFID 181EIP again.

• A WRITE-CONFIG from the RFID standard profile also resets this error state. • Bit 2 is set in parameter OPT1 and no tag is in the transmission window.

E6h FEh 04h

In the case of file handler: • MDS_IO_CONTROL = 1:

64. A command has been started but there is no tag in the transmission window of the reader / write/read device.

65. The dialog battery on the MDS 507 has discharged (the LR_bat bit did not have to be set; check battery voltage)

• MDS_IO_CONTROL = 0: 66. The old/current tag has exited the transmission window and the next/new tag

has entered the transmission window. A command has been started (not NEXT). This command refers to the new tag, but the old/current tag has not yet been terminated with NEXT.

67. A new tag enters the transmission window of the reader / write/read device and then exits again without a command having been executed with this tag. ("Slip-through of the MDS")

In the case of normal addressing: An error has occurred that makes a WRITE-CONFIG with Config = 3 necessary. • Error(s) in the WRITE-CONFIG command • Start WRITE-CONFIG command after error correction.

E6h FEh 05h

In the case of file handler: The file handler will now only accept a WRITE-CONFIG command mit Config = 3. • The file handler has not yet been initialized by a WRITE-CONFIG • The state can only be resolved by a WRITE-CONFIG

Fxh FEh xxh An FxFExxh error is identical with the corresponding ExFExxh error (see ExFExxh). Byte 3 additionally contains warning information.

6.2.2. Errors of the RFID standard profile concerned to user program The causes of these errors can include: • Incorrect parameterization of the RFID functions in the PLC. The errors according the following table may be generated by the PLC user program.

In case of the PLC user program generates own errors it is recommended to implement the error messages according the following table. If it is done so, the implementation will be in accordance to the RFID standard profile

Error messages from the RFID standard profile


Byte 0 1 2

Description

E5h FEh 02h Incorrect sequence number order (SN) in the RFID standard profile E5h FEh 05h Invalid data block number (DBN) in the RFID standard profile E5h FEh 07h Invalid data block number (DBL) in the RFID standard profile E5h FEh 09h The RFID 181EIP executes a hardware reset (INIT_ACTIVE set to "1"). INIT is expected

from the RFID standard profile (bit 15 in the cyclic control word). E5h FEh 0Ah The "CMD" command code and the relevant acknowledgement do not match. This can

be a software error or synchronization error that cannot occur in normal operation. E5h FEh 0Bh Incorrect sequence of acknowledgement message frames (TDB / DBN) E5h FEh 0Ch Synchronization error (incorrect increment of AC_H / AC_L and CC_H / CC_L in the cyclic

control word). INIT had to be executed E6h FEh 06h INIT timer has expired E7h FEh 01h In this state, only the INIT command is permitted. E7h FEh 02h The CMD command code is not permissible. E7h FEh 03h The length parameter of the command is too long.

It does not match the global data reserved within the send data buffer (TXBUF). E7h FEh 04h Overflow of the receive data buffer (RXBUF)

More data were received than memory available in the RXBUF. E7h FEh 05h This error tells the user that only an INIT command is permissible as the next command.

All other commands are rejected. E7h FEh 06h Wrong index (outside range of 101 to 108) E7h FEh 07h RFID 181EIP does not respond to INIT (INIT_ACTIVE is expected in cyclic status

message). E7h FEh 08h Time violation during INIT

(60 seconds in accordance with TC3WG9) Fxh FEh xxh An FxFExxh error is identical with the corresponding ExFExxh error (see ExFExxh).

Byte 3 additionally contains warning information.

6.2.3. Errors from Ethernet/IP Additional errors from the transport layer of Ethernet/IP are mostly available. For this error messages read the manual of the Ethernet/IP controller. These errors have to be handled in the application program.

6.3 Warnings The RFID 181EIP replies warnings in the CI byte of the acknowledge telegram. See also chapter 5.2. To be in conjunction with this profile, the application programmer may copy the CI byte of the acknowledgement into Error_Code_2 byte of the overall error presenting. Note: Bit 0 (which is the general error indicator) must be always set to 0 by the programmer.

Description of the error structure with warnings.


Byte 0 … 2 Byte 3 Meaning Bit 0 Bit is always "0" Bit 1 ECC correction has been carried out Bit 2 Low Battery if an RFID reader is used Bit 3 Auxiliary battery is low Bit 4 Tag was out of the field Bit 5 READ command has length "0" or file is smaller than read length Bit 6 Tag with new directory has come into the field

FxFExxh

Bit 7 Reserved

6.4 Special error handling This chapter discusses two questions:

• How to detect a switched off ident unit • How to detect a not connected reader

6.4.1. Detecting a switched off ident unit A switched off ident unit cannot report any error message because it is disconnected from the power supply. For detecting a switched off ident unit, the programmer of the PLC must set up cyclically a command to the ident unit to receive the status word (see chapter 3.3). A switched off reader will not respond in this case. This will lead to an error status or notification within the PLC.

6.4.2. Detecting an unconnected reader For detecting an unconnected reader, the programmer of the PLC must set up cyclically a command to the ident unit to receive the status word (see chapter 3.3). A missing reader (SLG) will be indicated by the Error_Flag (Bit 4) within the status word.


7. Test application The RFID 181EIP comes with a simple test application which demonstrates the handling within a RSLogix5000 (v15.01) Ladder Logic program. This test application may help the user to create his own RFID applications with the RFID 181EIP. The test application was developed with following hardware components:

• ControlLogix 1756-L61 PLC • Ethernet/IP interface module 1756-ENBT/A • RFID 181EIP • Two MOBY U readers connected to the RFID 181EIP

The test application is not a full featured function block.

7.1 Structure The main routine of the test application sends at first the parameterization to the RFID 181EIP. It contains no channel specific information so it is send only once. Some tags are then initialized for both channels and the WriteConfig messages for both channels are sent. If WriteConfig (Initialization) of both channels was successful a looping sequence of PIB commands is started. There are two sequences implemented. Sequence 1 contains nearly all PIB commands. The commands are sent one after another without using any linked commands. Sequence 2 contains linked Read and Write Commands which are used for data size exceeding the max. PIB data size of 240 Byte. By setting the tag ‘Sequence type’ to 1 or 2 one of the Sequences can be chosen for looping execution. The following figure shows the structure of the test application:


Parametrization

Initialize Tags Ch0

Initialization Ch0

MainRoutine

Sequence 1 Ch1Sequence 1

or Sequence 2

Sequence 2 Ch0Create Ch1

Format Ch1

Write Ch1

Update Ch1

SetAttr Ch1

Read Ch1

GetDir Ch1

Inventory Ch1

Initialize Tags Ch1

Initialization Ch1

Delete Ch1

DevStatus Ch1

MemStatus Ch1

Sequence 1 Ch0

Create Ch0

Format Ch0

Write Ch0

Update Ch0

SetAttr Ch0

Read Ch0

GetDir Ch0

Inventory Ch0

Delete Ch0

DevStatus Ch0

MemStatus Ch0

Create Ch0

Format Ch0

WriteLargeData Ch0

ReadLargeData Ch0

GetDir Ch0

Delete Ch0

Sequence 2 Ch1

Create Ch1

Format Ch1

WriteLargeData Ch1

ReadLargeData Ch1

GetDir Ch1

Delete Ch1

During the execution of the command subroutines two general type of error are checked (red line in the above figure):

• Errors originating from the Ethernet/IP Error reporting mechanism and therefore from the Ident device itself.

• Errors originating from the communication between the Ident Device and the reader. These errors are indicated in Byte 5 in the response data of an Acyclic Read/Acknowledge. If this Byte 5 is not 0 an error or warning has occurred. The Byte 11-14 of the Acyclic Read/Acknowledge response contain detailed information about errors/warnings. Look at 5.2, Negative Acknowledgement and 6 for details on that.


Occurring of both error types leads immediately to a new initialization and a restart of the chosen command sequence. This behavior is for long term testing only and might not fit to the needs of a user’s application.

7.2 Short description of the sub routines MainRoutine: The main routine does the following: Parameterization of the ident device, initialization of both ident device channels, initialization of important tags, process a PIB command sequence. Therefore it calls the subroutines - PARAMETRIZATION for both channels (see also 3.4 Parameter Telegram) For channel 0: - PIB0_MobyU_Initialization - PIB0_INIT_Tags - PIB0_Sequence1 or PIB0_Sequence2 For channel 1: - PIB1_MobyU_Initialization - PIB1_INIT_Tags - PIB1_Sequence1 or PIB1_Sequence2 PIB0_MobyU_Initialization and PIB1_MobyU_Initialization: The initialization sub routines first announce an initialization to the ident device by raising the INIT bit of the Cyclic Control Word. The ident device answers by setting the INIT_ACTIVE bit of the Cyclic Status Word. If this has happened the INIT bit of the Cyclic Control Word is cleared again by the PLC. After the Ident Device has cleared the INIT_ACTIVE bit in the Cyclic Status Word an WriteConfig PIB command (see Write-Config or Write-Config (FH, DA)detailed coding) is sent to the Ident Device and an acknowledge is fetched. PIB0_INIT_Tags and PIB1_INIT_Tags: Just initializes important tags, doesn’t exchange data PIB0_Sequence1 and PIB1_Sequence1: calls consecutively PIB command routines: - PIB0_MobyU_Format - PIB0_MobyU_Create - PIB0_MobyU_Write - PIB0_MobyU_Read - PIB0_MobyU_Update


- PIB0_MobyU_SetAttr - PIB0_MobyU_GetDir - PIB0_MobyU_Inventory - PIB0_MobyU_Delete - PIB0_MobyU_DevStatus - PIB0_MobyU_MemStatus respectively: - PIB1_MobyU_Format - PIB1_MobyU_Create - PIB1_MobyU_Write - PIB1_MobyU_Read - PIB1_MobyU_Update - PIB1_MobyU_SetAttr - PIB1_MobyU_GetDir - PIB1_MobyU_Inventory - PIB1_MobyU_Delete - PIB1_MobyU_DevStatus - PIB1_MobyU_MemStatus All commands of PIB0_Sequence1 and PIB1_Sequence1 handle PIB commands (header + data) of a size < 240 Byte. PIB0_Sequence2 and PIB1_Sequence2: calls consecutively PIB command routines: - PIB0_MobyU_Format - PIB0_MobyU_Create - PIB0_MobyU_WriteLargeData - PIB0_MobyU_ReadLargeData - PIB0_MobyU_GetDir respectively: - PIB1_MobyU_Format - PIB1_MobyU_Create - PIB1_MobyU_WriteLargeData - PIB1_MobyU_ReadLargeData - PIB1_MobyU_GetDir The command routines *WriteLargeData and *ReadLargeData use chained read and write commands (see 3.1 Communication Principle) to handle PIB commands (header + data) of a size > 240 Byte.


7.3 Mapping of the Communication Principle to Ladder Logic The following screenshot shows the mapping of the communication principle described in 3.1, 3.2. by means of the subroutine for the PIB Format Command. After preparing some tags the Acyclic Write/Command message is sent. By clicking on the

-Button of the MSG command the opening Dialog shows their Object IDs, the used data tags and their length. In the next rung the acknowledge counter is checked and if it’s changed the Acyclic Read/Acknowledge message is sent. As mentioned before the command counter is not checked by the PIB Format Command routine.


7.4 Representation of Cyclic Data The incoming and outgoing cyclic data can be monitored at the Controller Tags section. Currently open in the following figure is the incoming ‘statusword’ of channel 0. The state of the bits is used in the MainProgram. Their meaning is described in 3.3.


7.5 Representation of PIB Command and Acknowledge Data The data arrays for the PIB Commands and Acknowledges are also located in the Controller Tags section. The following screenshot shows an array containing a PIB ‘Write’-Command including filename (in the test application always ‘myfile00’) and the data (Byte 46 – 239, not shown).


The next screenshot shows the acknowledge of a PIB Read Command. Byte 5 is 0, which means that the PIB Read Command was successful. The length of the read data is stored in Byte 10 (here 0xC2, 194 Bytes). The read data is stored in the Bytes 11 to 205.


7.6 Adding new RFID 181EIP devices to the test application To add an additional RFID 181EIP Ident device to the application first (assuming correct cabling and IP-Address data assigned) click in the I/O configuration section with right mouse button on 1756 ENBT/A Ethernet/IP interface → Ethernet. Choose ‘New Module …’ in the context menu which opens the ‘Select Module’-Dialog in the figure below. Then choose ETHERNET-MODULE (Generic Ethernet Module) from the ‘Communications’ section.

This opens the ‘Module Properties’-Dialog (See next page).


On the General Tab enter a name for the new module differing from the existing one(s), a description (optional) and the IP-Address. Then set the Comm Format to ‘Data – INT’. Set the connection parameters as shown in the figure on the right side. Change to the Connection Tab and set the RPI to 20.0 ms. Click OK. The leads to another RFID_181PIB ident device under the I/O configuration → 1756 ENBT/A Ethernet/IP interface → Ethernet section. And in the Controller Tags section the additional I/O Tags are created.


To create the programs/routines and the tags for the additional ident device we suggest the following strategy:

1. Duplicate the Controller Tags per ‘Copy and Paste’: I.e. by opening a second RSLogix5000 with an empty project Copy the existing Controller Tags to the Controller Tags of the empty project Rename the copied Controller Tags by ‘Replace’. Suggestion: PIB0_… (channel 0 of device 0) PIB2_... (channel 0 of device 1) PIB1_… (channel 1 of device 0) PIB3_... (channel 1 of device 1) etc.

2. Duplicate the Program Tags per ‘Copy and Paste’: I.e. by opening a second

RSLogix5000 with an empty project Copy the existing Program Tags to the Program Tags of the empty project Rename the copied Program Tags by ‘Replace’. Suggestion: PIB0_… (channel 0 of device 0) PIB2_... (channel 0 of device 1) PIB1_… (channel 1 of device 0) PIB3_... (channel 1 of device 1) etc.

3. Duplicate the necessary routines of the ‘MainProgramm’ and rename then i.e.

according to the formalism of the Controller and Program Tags above by ‘Replace’.

4. Adjust the tag names and the communication path within the MSG-

Instructions-Dialog(s): • The names of the source and destination data arrays (containing command

and acknowledge data) in the Message Configuration Dialog(s) on the Configuration Tab

• the module path in the Message Configuration Dialog(s) on the Connection Tab

This involves all the MSG-instructions in the new routines.

5. Integrate the new routines for the new ident device in the MainRoutine.


8. Firmware-Update A Firmware-Update for the RFID 181EIP is done by two applications usually coming with Microsoft Windows XP™ - Telnet and FTP. Both are being started at the command prompt of a DOS box (cmd.exe). For a Firmware-Update an Image-file in the ‘ELF’-Format containing the new firmware is needed. In example: ‘RFID 181EIP.elf’. The Firmware-Update step by step:

1. Connect a PC with Microsoft Windows XP™ installed on it to the Ethernet/IP Network (subnet) having the new firmware image file located on it. It is assumed that the Telnet and FTP client are installed on that PC.

2. Open a DOS box. Start Telnet by typing “telnet” at the command prompt followed by the IP address of the device and separated by a blank.

Press enter. After successful connection you are requested to enter a username and a password. Please enter. Username: fwupdate Passwort: R_F_I_D_ (please enter also the underscores – totally 8 characters!)

3. Start the Firmware-Update by typing ‘fwupdate’. Press enter. The screen should show the following or a similar output (may vary depending on the firmware release):


4. Open a second DOS box. Start FTP by typing ‘ftp’ at the command prompt followed by the IP address of the device and separated by a blank. Press enter. After successful connection you are requested to enter a username and a password. Please use the same username/password combination as for the telnet connection above. After the successful login the ftp-prompt is shown.

5. To download the firmware image type ‘put’ followed by the path to the

firmware image file (separated by a blank) as shown in the following figure. Press enter to start the download of the image file to the RFID 181EIP device.


6. After the download process has finished type ‘bye’ and press enter. The ftp

application exits.

7. The DOS box with the telnet application shows now messages that the flash memory is being erased followed by messages that the flash memory is written with new image data.


8. After the successful Firmware-Update the telnet application shows the

following line: "file <FILENAME>, size <…> bytes, flashed <…> bytes, checksum header 12 bytes"

The ident device now reboots automatically and the telnet connection is closed.


9. Appendix

9.1 Using the RFID 181EIP with an Allen-Bradley PLC5 Controller

9.1.1. Preface The RFID 181EIP is a new module to connect two Read/Write Units of the Moby RFID family to CIP over Ethernet/IP (EIP/CIP). It enables the use of Siemens Moby RFID connected to Allen-Bradley ControlLogix Controllers. CIP stands for Common Industrial Protocol standardized by the ODVA. Ethernet/IP is the ethernet specific protocol part encapsulating CIP. The Allen-Bradley PLC5 is not able to communicate over EIP/CIP. It uses an older protocol called PCCC over Ethernet/IP (EIP/PCCC). By the use of firmware version > 2.1 the RFID 181EIP is also able to communicate to Allen-Bradley PLC5 Controllers using the internal or the side car ethernet interface. Therefore the RFID 181EIP ‘understands’ additionally the non standardized PCCC protocol over Ethernet/IP. PCCC stands for Programmable Controller Communication Commands. For the extension of the RFID 181EIP firmware to PLC5 communication the following main requirements have been taken into account:

• Keep all the handling of PIB Moby Commands by the PLC5 as similar as possible to the handling by the ControlLogix.

• Integrate a layer in the RFID 181EIP firmware which transforms PLC5 PCCC-messages into EIP/CIP-Messages. These transformed messages are processed in the same way as messages direct from a ControlLogix using the same routines. Vice versa data returned from the RFID 181EIP module respectively from the connected readers has to be re-transformed by this software layer so that it fits into the PCCC responses to the PLC5.

• The PLC5 doesn’t have the ability for implicit I/O exchange as the ControlLogix Controller. This implicit I/O exchange of the ControlLogix has to be simulated on the PLC5 by explicit messages. Therefore it is strongly recommended to use a second task on the PLC5 running asynchronous to the control task/PIB Moby task for the automation process.


9.1.2. Requirements Hardware:

• One or more RFID 181EIP Ident Device(s) • SIMATIC RFID reader(s) connected to RFID 181EIP Ident Device(s) • An Allen-Bradley PLC5/80 (full memory extension to 102400 Words) with an

Ethernet network interface (internal or side card) suitable for the use together with the RSLogix 5 Software Because of the multiplicity of PLC5 hardware and firmware revisions it was not possible to test the communication between PLC5 and RFID 181EIP with all kinds of them. All testing of the PLC5-functionality was done with a PLC-5/80E Series F rev A.1 with an internal Ethernet interface. Therefore we can ensure correct functionality only for the PLC-5/80E Series F rev B01, FW-Revision A.1 or higher with a build-in Ethernet interface - even it is very likely that communication to PLC5 controllers with other hardware/firmware releases according to the statements of Rockwell (see below) will also work correctly. Rockwell's info dated 2002 says the following regarding Ethernet/IP compatibility: • Series C, revision N.1 or later • Series D, revision E.1 or later • Series E, revision D.1 or later The 1785-ENET Ethernet communication interface module must be • Series B, revision A or later

• A Windows™- or compatible PC with a free 10/100 MBit Ethernet network interface (in the following ‘PC’) and TCP/IP installed and valid IP-Address data assigned to the interface.

Software:

• Windows XP™ with Service Packs installed • FTP and Telnet installed for possible Firmware-Update • RSLogix5™ (7.10.00 (CPR 7) or higher) • RSLinx™ Classic or RSLinx Classic lite (v 2.500.20 (CPR7) or higher) • A DHCP-Server, in example the BOOTP/DHCP-Server 2.3, coming with the

RSLinx™ Software • The EDS Hardware Installation Tool, coming with RSLinx/RSLogix™


9.1.3. Setting the RFID 181EIP into PLC5 mode No special action has to be done to set the RFID 181EIP into PLC5 mode. If the RFID 181EIP has its first cyclic communication to a PLC5 the RFID 181EIP is in PLC5 mode. Then it does not accept connections from a ControlLogix controller until it reboots.

9.2 Comparison: RFID 181EIP connected to ControlLogix or PLC5 Despite the effort of keeping PLC5 handling as similar as possible to ControlLogix there are some differences regarding hardware, firmware and the programming environment.

9.2.1. PLC relevant differences: ControlLogix ↔ PLC5

• The PLC5 Controller is a ‘word machine’ in contrast to the ControlLogix which is a ‘byte’ machine’. Therefore access to a byte or a single character on a PLC5 is more laborious than on a ControlLogix. This might be important for handling PIB RFID commands and data, because some information here is also byte-orientated.

• The maximum memory size of a PLC5 - even at full expansion - is 102400 16-Bit Words which is about 200 KByte. The smallest available memory for a ControlLogix Controller is 750 KByte and can be extended up to several MBytes. From this it follows that memory size not used for PIB Moby handling and available for other automation tasks is relatively smaller on a PLC5, even if it is assumed that the memory consumption on a ControlLogix for the same task is higher than on a PLC5.

• The number RFID 181EIP modules which can be connected to a PLC5, is limited by two factors:

o The memory extension of a PLC5: The maximum memory extension of a PLC5 is 100k 16-Bit words. This is in comparison to the memory of a ControlLogix relatively small.

o The number of concurrent TCP/IP-Connections the PLC5 is able to handle. Communication between RFID 181EIP modules and PLC5 Controllers over Ethernet/IP bases on TCP/Connections. Unfortunately we did not have any information about the max. possible concurrent TCP/IP-Connections of a PLC5. It is also likely that this number will vary across the PLC5 hardware/firmware releases.

Therefore a definite prediction about the number of RFID 181EIP modules which can be controlled by one PLC5 is not possible. It depends strongly on


the process functionality and the experience of the process/system engineer to keep the PLC5 application memory efficient.

To give at least a benchmark: Communication was tested with one PLC5, four RFID 181EIP modules and eight connected readers. For all connected readers a similar sequence of the commands Write-Config, Format, Write, Read and Dev_Status were processed. The test application was not memory optimized to be able to check all states and commands for each reader. This led to a memory consumption of about 2/3 of the PLC5 memory.

• With the RFID 181EIP it is not possible use chained read commands in conjunction with PLC5. Data Volumes lager than 206 must be read with consecutive single read commands. Chained write commands are possible as with the ControlLogix but with a maximum of 172 data bytes per chained write command.


9.2.2. Software relevant differences: RSLogix5000 ↔ RSLogix5

Both programming environments – RSLogix 5 for the PLC5 and RSLogix5000 for the ControlLogix – support Ladder Logic in a similar way. The relevant differences are:

• Output instructions at the end of a rung have to be placed parallel in

RSLogix5:

In RSLogix5000 they also can be placed in a sequence:

• Tag names and sub routine name: Sub routine names in RSLogix5 are limited to 10 Characters, so the RSLogix5000 names had to be adopted. See 9.3.2 for the meaning of the routine names As a tag in RSLogix5 is addressed basically over file number and offset it was the aim to keep the corresponding symbolic names in RSLogix5 as similar as possible to the tag names in RSLogix5000 (Project -> Database -> Address/Symbol). For the file names (files are used to group tags of similar data type and meaning) there is no equivalence in RSLogix5000, so here new names had to given.

• Sending and receiving Messages

Out of the fact that the PLC5 firmware is not able to handle EIP/CIP messages like the ControlLogix another use of the MSG-Instruction is obligatory:

o An EIP/CIP message can contain data in both request and response. To transport a PIB Moby command – for example a ‘write’ instruction - to the module, 2 EIP/CIP messages are used. The first one contains in the request the PIB command and the data. The immediate response is empty. The second one is used to pick up the acknowledge (and in the case of a read instruction – the data). Here the request is empty. The module knows by the means of the Object IDs that the incoming message


wants an acknowledge and fills the acknowledge in the data part of the response. This communication principle is described in detail in chapter 3.1. The message type for both messages is “CIP Generic”. Whether the message is for sending a command or for picking up an acknowledge is distinguished by the service code: 0x41 for a command and 0x40 for an acknowledge

EIP/PCCC messages cannot contain arbitrary data in both request and response. Here for the first and the second message different types must be used to distiguish command and acknowledge: A ‘PLC5 Typed Write’-message for the first message containing arbitrary data only in the request for a command and a ‘PLC5 Typed Read’-message for the second one containing arbitrary data only in the response for picking up the acknowledge.

o An EIP/CIP explicit message contains the CIP Object IDs (Service Code, Class, Instance and Attribute) to determine what is done with the commands/data in the module firmware. To provide the same CIP Object Information for a MSG Instruction in RSLogix5 the tag name of the target tag (Target Device -> Data Table Address) is ‘abused’. An example is provided above: “RFID41800165”. The module firmware extracts the Object IDs out of the tag name in the same order: Prefix RFID, Service 41, Class 80, Instance 01 and Attribute 65. The ‘Source


Length’ from a CIP generic Message equals to ‘This PLC5->Size in Elements’, keeping in mind that the PLC5 controller is a WORD-machine always handling 2 Byte words. Therefore the 65-bytes ‘Source Length’ from the CIP Generic message on the header of the previous page results in a 33-‘This PLC5->Size in Elements’ of a PLC-5 Typed Write or Read message.

o Target IP-Address: The target IP address (the ip address of the RFID 181EIP module) has to be configured in the ‘MultiHop’-tab at RSLogix5 instead of the ‘Communication‘-tab at RSLogix5000:

Another difference affects the data structure behind a MSG instruction. This data structure (data type MESSAGE) can be used to dynamically read or change properties of a MSG instruction. In RSLogix5000 a lot of information can be found in there including the PATH containing the target IP address (see next page).


In RSLogix5 this structure contains only few information:

Here no information of the IP address can be found! This means that the IP address can’t be changed dynamically. If the user/programmer wants to change the IP address he has to go through all the involved MSG instructions of the code.

9.2.3. Exchange of cyclic data

The PLC5 has to simulate implicit I/O communication as this is not provided like in the ControlLogix. Therefore a second task running asynchronously to the automation control task is recommended for the PLC5. The second task just sends and receives continuously explicit messages with the 16-Bit Control Word (3.3.1) and Status Word (3.3.2) for each of the two channels. This explicit cyclic data exchange equals to the implicit cyclic data exchange of the ControlLogix. The RFID 181EIP module firmware has to pull and push this cyclic data in the corresponding routines normally used by the connection manager of the Ethernet/IP-Stack. Below the message dialogs of the second task messages are shown.


Message dialog for the Cyclic Control Words Message dialog for the Cyclic Stautus Words (PLC-5 Typed Write) (PLC-5 Typed Read) To separate this simulated I/O-messages from acyclic messages for the target tag name (Target Device -> Data Table Address) “IO” is used.

9.3 Test application for RSLogix5 / PLC5

9.3.1. Structure The test application for the PLC5/RSLogix5 uses PIB Normal Addressing (NA or DA = Direct Access). The structure of the test application is very similar to the structure of the test application for ControlLogix/RSLogix5000 (7.1). The main difference is that here at first the main routine starts the second task for the explicit exchange of cyclic data before it does the parameterization with the corresponding Routine. The following action is in principle the same as for ControlLogix/RSLogix5000. Each channel is initialized by a Write-Config Command followed by the initialization of the tags. Then a loop of PIB command is started for each channel beginning with a ‘format’ of the tag. In this test application only sequence 1 is realized for PIB Commands containing max. 172 Bytes of Data (single Physical-Write-Command) respectively 206 Bytes of Data (single Physical-Read-Command).


Parameterization

Initialize Tags Ch0

Initialization Ch0

MainRoutine

Sequence 1 Ch1

Sequence 1oder

Sequence 2

Format Ch1

Write Ch1

Read Ch1

Initialize Tags Ch1

Initialization Ch1

Sequence 1 Ch0

Format Ch0

Write Ch0

Read Ch0

Start of Cyclic Exchange(second task)

Compare Read/Write Ch0

Main task

DevStatus Ch0

ChangeData Ch0

Compare Read/Write Ch1

ChangeData Ch1

DevStatus Ch1

(Sequence 2 not realized)


9.3.2. Short description of the sub routines (in brackets the routine name of the equivalent ControlLogix/RSLogix5000 routine is shown) CYC_ACTION: This routine contains the rungs for the cyclic data exchange, done by the second task. Main_PIB (MainRoutine): The main routine does the following: Parameterization of the module, initialization of both module channels, initialization of important tags, process a PIB command sequence repeatedly. Therefore it calls the subroutines - PARA_PIB (PARAMETRIZATION) for both channels (see also 3.4 Parameter Telegram) For channel 0: - P0_PH_INIT (PIB0_MobyU_Initialization) - P0_PH_INIT_TA (PIB0_INIT_Tags) - P0_PH_SEQ1 (PIB0_Sequence1) For channel 1: - P1_PH_INIT (PIB1_MobyU_Initialization) - P1_PH_INIT_TA (PIB1_INIT_Tags) - P1_PH_SEQ1 (PIB1_Sequence1) P0_PH_INIT (PIB0_MobyU_Initialization) and P1_PH_INIT (PIB1_MobyU_Initialization): The initialization sub routines first announces an initialization to the module by raising the INIT bit of the Cyclic Control Word. The module answers by setting the INIT_ACTIVE bit of the Cyclic Status Word. If this has happened the INIT bit of the Cyclic Control Word is cleared again by the PLC. After the module has cleared the INIT_ACTIVE bit in the Cyclic Status Word again an Write-Config PIB command (see Write-Config or Write-Config detailed configuration) is sent to the module and an acknowledge is fetched. P0_PH_INIT_TA (PIB0_INIT_Tags) and P1_PH_INIT_TA (PIB1_INIT_Tags): Just initializes important tags, doesn’t exchange data


P0_PH_SEQ1 (PIB0_Sequence1) and P1_PH_SEQ1 (PIB1_Sequence1): calls consecutively PIB command routines: - P0_PH_FO (PIB0_MobyU_Format) - P0_PH_WRIT (PIB0_MobyU_Write) - P0_PH_READ (PIB0_MobyU_Read) - P0_PH_DEST (PIB0_MobyU_DevStatus) respectively: - P1_PH_FO (PIB1_MobyU_Format) - P1_PH_WRIT (PIB1_MobyU_Write) - P1_PH_READ (PIB1_MobyU_Read) - P1_PH_DEST (PIB1_MobyU_DevStatus) The routine P0_PH_CORW (PIB0_MobyU_Compare_ReadWrite) compares the written and the read data. PO_PH_CHDA (PIB0_MobyU_ChangeData) modifies the data for the next loop. These routines were inserted for system test, they don’t exchange data with the RFID 181EIP. All commands of P0_PH_SEQ1 (PIB0_Sequence1) and P1_PH_SEQ1 (PIB1_Sequence1) handle PIB commands of a size < 218 Byte (header + data), respectively data < 172 bytes (data only).

Documents

RFID 181EIP Ident Device Configuration and Programming - Molex