JEM TR 213 Implementation Guidelines of FA …...JEM-TR 213 TECHNICAL REPORT OF THE JAPAN ELECTRICAL MANUFACTURERS’ ASSOCIATION JEM-TR 213 Implementation Guidelines of FA Control

JEM-TR 213

TECHNICAL REPORT OF

THE JAPAN ELECTRICAL MANUFACTURERS’ ASSOCIATION

JEM-TR 213

Implementation Guidelines of

FA Control Network [FL-net (OPCN-2)]

Established November 28, 2000

Revised on July 3, 2006 (Third revision)

The Japan Electrical Manufacturers’ Association

JEM-TR 213: 2006

Foreword for the English edition

This document is English translation of JEM-TR 213 that is written in Japanese for convenience to users and

developers of FL-net who feel difficult to understand Japanese language. Therefore, the JEM-TR 213

(Japanese) is original while this document is for reference only.

This document may be revised while the original is unchanging to improve English expression without

noticeable version change. The working group on English documentation of the special committee for FL-net

promotion at JEMA, which worked on the translation, welcomes comments and questions on English expression,

which will help it for future improvement.

JEM-TR 213: 2006

Foreword

This is the technical report of the Japan Electrical Manufacturers’ Association that the Steering

Technical Committee revised based on deliberatrions by the Network Subcommittee, the

Programmable Controller Technical Committee and the Standardization Committee.

It should be noted that some parts of this report may conflict with patent rights to technical

properties, patent right registration applications after application public release, patent rights for

utility articles, or patent right registration applications for utility articles after application public

release. The Japan Electrical Manufacturers’ Association accepts no responsibility for confirmations of

such patent rights to technical properties, patent right applications after application public release,

patent rights for utility articles, or patent right applications for utility articles after application public

release.

JEM-TR 213: 2002 CONTENTS

( 1 )

C o n t e n t s

page

1. SCOPE ...............................................................................................................................................1

2. REFERRED STANDARDS ................................................................................................................1

3. DEFINITIONS.....................................................................................................................................2

3.1 TERMS DEFINED IN JIS B 3500.............................................................................................................2 3.2 TERMS DEFINED IN JIS B 3521 .............................................................................................................2 3.3 TERMS DEFINED IN JIS X 0001.............................................................................................................3 3.4 TERMS DEFINED IN JIS X 0005.............................................................................................................3 3.5 TERMS DEFINED IN JIS X 0009.............................................................................................................4 3.6 TERMS DEFINED IN JIS X 5003.............................................................................................................4 3.7 NOTATION USED IN THIS TECHNICAL REPORT .........................................................................................4

4. ABBREVIATIONS..............................................................................................................................5

5. TERMS USED IN LOWER LAYER OF FL-NET ................................................................................6

6. PERFORMANCE ...............................................................................................................................7

6.1 CYCLIC DATA .......................................................................................................................................7 6.2 MESSAGE TRANSMISSION .....................................................................................................................7

7. HARDWARE ......................................................................................................................................7

7.1 TIMER RESOLUTION ..............................................................................................................................7 7.2 GENERATION OF RANDOM NUMBERS .....................................................................................................7 7.3 TRANSMISSION STATUS INDICATION.......................................................................................................7 7.4 NODE NUMBER SWITCH.........................................................................................................................8 7.5 CONNECTORS ......................................................................................................................................8 7.6 GROUNDING AND SHIELD ......................................................................................................................8 7.7 MEMORY RESOURCES ..........................................................................................................................8

8. CLASSIFICATION .............................................................................................................................8

9. PRESENTATION OF INFORMATION ...............................................................................................9

9.1 SOFTWARE VERSION OF NETWORK DEVICE ............................................................................................9 9.2 VENDOR CODE AND MANUFACTURER MODEL NAME ................................................................................9 9.3 STATUS INFORMATION ..........................................................................................................................9

10. LOWER LAYER PROTOCOL..........................................................................................................10

JEM-TR 213: 2002 CONTENTS

( 2 )

10.1 BASIC SPECIFICATIONS....................................................................................................................10 10.2 PHYSICAL AND DATA LINK LAYER .................................................................................................11 10.3 NETWORK LAYER ............................................................................................................................11 10.4 TRANSPORT LAYER .........................................................................................................................11 10.5 ADDRESS SETTING ..........................................................................................................................11

11. FRAME STRUCTURE......................................................................................................................13

12. FA LINK PROTOCOL ......................................................................................................................13

12.1 IN-RING AND OUT-RING MANAGEMENT ..............................................................................................13 12.1.1 In-ring and out-ring of other nodes ........................................................................................13 12.1.2 Out-ring of own-node .............................................................................................................14

12.2 CYCLIC TRANSMISSION....................................................................................................................14 12.2.1 Implementation.......................................................................................................................14 12.2.2 Transmission data size ..........................................................................................................14 12.2.3 Reception data size ...............................................................................................................14 12.2.4 Common memory...................................................................................................................14

12.3 MESSAGE TRANSMISSION ................................................................................................................15 12.3.1 Implementation requirements ................................................................................................15 12.3.2 Request frame and response frame ......................................................................................15 12.3.3 Sequence number management ...........................................................................................16 12.3.4 CBN and TBN ........................................................................................................................17 12.3.5 Note on each message ..........................................................................................................17

13. SUPPLEMENT ON DATA CONSISTENCY .....................................................................................23

13.1 SETTING .........................................................................................................................................23 13.1.1 Node number .........................................................................................................................23 13.1.2 Common memory area setting ..............................................................................................24 13.1.3 LKS (FA link status) of node management information ........................................................25 13.1.4 Coexistence of devices with different token modes............................................................25

13.2 NOTES ON FA LINK HEADERS...........................................................................................................26 13.2.1 Transmission ..........................................................................................................................26 13.2.2 Reception ...............................................................................................................................29

14. TCD RECEPTION BEHAVIOR AT UDP PORT ...............................................................................35

EXPLANATION .........................................................................................................................................37

TECHNICAL REPORT JEM-TR OF

THE JAPAN ELECTRICAL MANUFACTURERS’ ASSOCIATION 213: 2006

Implementation Guidelines of FA Control Network

[FL-net (OPCN-2)]

.

1. Scope This technical report provides guidelines for implementing protocols specified in the FA control network

(FL-net, hereinafter) specifications. The functions described in the guidelines as mandatory shall be

implemented if the products are developed from scratch. This may not be the case for revision or expansion of

existing products.

2. Referred standards The following standards are referred to in this technical report (JEM-TR 213), and constitute portions of this

technical report. The latest versions of these standards and technical reports shall be applied.

JIS B 3500 Glossary of terms used in programmable controller

JIS B 3503 Programmable controllers -- Programming languages

JIS B 3521 Protocol specification for FA control network standard

JIS X 0001 Glossary of terms used in information processing -- Fundamental terms

Remarks “ISO/IEC 2382-1: 1993, Data processing -- Vocabulary -- Part 1: Fundamental terms” is

correspond to this standard.

JIS X 0005 Glossary of terms used in information processing (Representation of data)

Remarks “ISO 2382-5: 1989, Information technology -- Vocabulary -- Part 5: Representation of

data” is correspond to this standard.

JIS X 0009 Glossary of terms used in information processing (Data Communication)

Remarks “ISO/IEC 2382-9: 1995, Information technology -- Vocabulary -- Part 9: Data

communication” is correspond to this standard.

JIS X 0025 Glossary of terms used in information processing -- Local area networks

Remarks “ISO/IEC 2382-25: 1992, Information technology -- Vocabulary -- Part 25: Local area

networks” is correspond to this standard.

JIS X 0026 Glossary of terms used in information processing (Open systems interconnection)

Remarks “ISO/IEC 2382-26: 1993, Information technology -- Vocabulary -- Part 26: Open systems

interconnection” is correspond to this standard.

JIS X 5003 Open Systems Interconnection -- Basic reference model

JIS X 5252 Local area network -- Carrier sense multiple access with collision detection

(CSMA/CD) access method and physical layer specification

Remarks Referred items from “ISO/IEC 8802-3: 1996, Information technology --

2 JEM-TR 213: 2006

Telecommunications and information exchange between systems -- Local and

metropolitan area networks -- Specific requirements -- Part 3: Carrier sense multiple

access with collision detection (CSMA/CD) access method and physical layer

specifications (available in English only)” arecorrespond to this standard.

JEM-TR 214 Device profile common specifications for FA control network [FL-net (OPCN-2)]

3. Definitions Definitions of main and related terms used in this technical report are listed below. These definitions

comply with JIS B 3500, JIS B 3521, JIS X 0001, JIS X 0005, JIS X 0009, JIS X 5003, JIS X 5201 and JIS X 5203.

3.1 Terms defined in JIS B 3500

This technical report uses the following terms defined in JIS B 3500.

a) Execution

b) Internal failure

c) Module

d) Unit

e) Peripheral

3.2 Terms defined in JIS B 3521

This technical report uses the following terms defined in JIS B 3521.

a) FL-net (OPCN-2) Name of controller-level network conforming with JIS B 3521

Remarks Hereafter the network in this technical report means the FL-net.

b) FA link protocol Protocol defined to implement the FL-net. The FA link protocol layer lies between a

transport layer and an application layer. The protocols of token management, cyclic transmission and

message transmission are defined so that each node transmits data equally to each other.

c) FA link Entity to execute the FA link protocol.

d) FA link header Header information part of the frame defined in the FA link protocol

e) Token Temporary right to use the network transmission medium. A token is transferred consecutively

from one node to another.

f) Valid linking state State where a token is consecutively circulated among nodes

g) Network startup state Node status where the node requests to participate in the network in the invalid

linking state

h) In-ring startup state Node status where the node requests to participate in the network in the valid

linking state

i) Cyclic transmission Transmission method where a node transmits data stored in an allocated common

memory area to all the nodes in a broadcast communication mode whenever the node acquires a token.

Refer to 8.3.2 for details.

j) Message transmission Non-cyclic transmission method for transmitting an event between nodes. Refer to

8.3.3

k) Cyclic frame Frame used for cyclic transmission

l) Token frame Frame for transmitting and receiving a token between nodes

m) Message frame Frame used for message transmission

n) Trigger frame Frame used when a node notifies its “participation request frame transmission waiting

3 JEM-TR 213: 2006

timer start” in the network startup state

o) Participation request frame Frame used when a node notifies an existence of a own-node to participate in

the network

p) ACK (message acknowledgment) Information used to acknowledge message frame transmission

q) Version of sequence number Number used to judge if a received message is the same as the latest

received one. The “version of sequence number” is generated when a node participates in the FL-net, and

holds its value until the node secedes from the network.

r) Sequence number Number used to judge if a received message is the same as the latest received one.

The sequence number value is initialized at the network startup time, and is incremented when each

message transmission is completed.

s) TCD: transaction code Code defined in the network to identify each frame. For the transaction code, some

numbers are assigned as reserved by the FA link protocol while others can be defined by users optionally.

Refer to 7.2 for details.

t) Node Data station used in the network.

u) Node number Number for identifying each node connected to the network. Numbers 1 to 254 can be

assigned. In the FA link protocol, the node number is used as information on a transmission destination

address and a transmission source address in the FA link header.

v) Common memory Virtual memory for cyclic transmission defined in the network. It has two areas, “area

1” and “area 2”, with respective memory sizes of 512 words and 8 192 words. Refer to 6.1 for details.

w) Word Unit for indicating quantity of data. One (1) word means two (2) bytes.

x) Virtual address space Accessible memory space in message transmission

y) Token mode Mode where the network can process an independent token frame.

z) Major version Value of the integer part in the FA link protocol version. It is a 4-bit number. When it is

zero (0), it is treated as one (1).

Example 1. Ver.1.00 The major version is 0 or 1.

Example 2. Ver.2.00 The major version is 2.

aa) Minor version Value of the decimal part in the FA link protocol version. It is a 4-bit number.

Example 1. Ver.2.01 The minor number is 1.

Example 2. Ver.2.10 The minor number is 10.

ab) Double word Unit to indicate quantity of data. One (1) double word means 4 bytes.

ac) Final cyclic frame Cyclic frame transmitted just before a token frame

ad) Server function Functions for receiving a request message and transmitting a response message in

message transmission

ae) Client function Functions for transmitting a request message and receiving a response message in

message transmission

af) Protocol type Information for distinguishing protocols from each other

3.3 Terms defined in JIS X 0001

This technical report uses the following terms defined in JIS X 0001.

a) Hardware

b) Software


4 JEM-TR 213: 2006


a) MSB (most significant bit)

b) LSB (least significant bit)



a) Interface

b) Data transmission

c) Data communication

d) Transmission line

e) Data circuit transparency

f) Protocol

g) Data signaling rate

h) Phase

i) Polling

j) Selecting

k) Packet

l) Time out



a) <N>-layer

b) Application layer

c) Presentation layer

d) Session layer

e) Transport layer

f) Network layer

g) Data link layer

h) Physical layer

i) <N>-service

j) <N>-service-access-point

k) <N>-service-data-unit

l) <N>-protocol

m) <N>-protocol-data-unit

n) <N>-interface-control-information

o) <N>-protocol-control-information

p) <N>-connection

q) Packet segmenting/reassembling

3.7 Notation used in this technical report

a) Numbers not especially specified are decimal. To denote a hexadecimal number, “16#” precedes the

number.

Example 1. Decimal numbers -12 0 4 782

Example 2. Hexadecimal numbers 16#FF 16#00 16#12AE

5 JEM-TR 213: 2006

b) In this technical report, “#” precedes a node number.

Example Node number 1 Node #1

c) “Ver.*.*” is used to denote a version of the protocol specifications in this technical report. “*” is a decimal

number 0 to 15. Its integer part denotes a major version, and the cecimal part denotes a minor version.

A minor version consists of two figures.

The version of JEM 1479 (2000) is denoted as “Ver.1.00”.

The version of JIS B 3521 [JEM 1479 (2002)] is denoted as “Ver.2.00”.

A device manufactured and certified in compliance with JEM 1479 (2000) is denoted as a “Ver.1.00

device”.

A device manufactured and certified in compliance with JIS B 3521 (2004) is denoted as a “Ver.2.00

device”.

4. Abbreviations This technical report uses the abbreviations listed in Table 1.

Table 1 Abbreviation list

Abbreviation Term in English

3CWT Three-circulation waiting time

AWT Message acknowledge waiting time

BCT Broadcast transmission

BSIZE Current block size

CBN Current fragment block number

C_AD1 Common memory area 1 data top address


C_SZ1 Common memory area 1 data size


DA Destination address

DNA Node address of destination side

H_TYPE Header type

LKS FA link status

MAJ_VER FA link protocol version (major version)

MFT Allowable minimum frame interval time

MIN_VER FA link protocol version (minor version)

MODE FA link protocol version (major version, minor version), token mode

MSN Manufacturer model name of node information

M_ADD Message offset-address in virtual address space

M_CTL Message control

M_RLT Message result

M_SZ Message data size in virtual address space

NDN Node name of node information

PAT Participation request frame acceptance time

PDU Protocol data unit

PPT Peer to peer transmission

PRI Message priority

6 JEM-TR 213: 2006

Abbreviation Term in English

PWT Participation request frame transmission waiting time

P_TYPE Protocol type

RCT Allowable refresh cycle time

RMT Refresh cycle measurement time

RPA Response data by ACK

SA Source address

SDU Service data unit

SEQ Sequence number

SNA Node address of source side

TBN Total fragment block number

TCD Transaction code

TDT Joining token detection time

TFL Total frame octet length of header and data

TM Token mode

TW Token watchdog time

TrWT Trigger frame transmission waiting time

ULS Upper layer status

VDN Vendor code of node information

VER Program version

V_SEQ Version of sequence number

5. Terms used in lower layer of FL-net Table 2 shows terms used in the lower layer of FL-net.

Table 2 Terms used in lower layer of FL-net

Abbreviation Term in English Explanation Reference

ARP Address resolution protocol

Protocol to search a MAC address from an IP address RFC 826

ICMP Internet control message protocol

IP network diagnostic protocol for IP packet error notification etc.

RFC 792

IP Internet protocol Network layer protocol to be used in the internet RFC 791

IP address 32-bit address information to be used in the IP RFC 791

MAC address Media access control address

Device-specific ID number for connection to an JIS X

5252 network -

TCP Transmission control protocol

Transport layer protocol to be used in the internet RFC 793

UDP User datagram protocol Transport layer protocol to be used in an internet RFC 768

Class C General-use unicast address level with a standard 24-bit prefix when networks are classified systematically.

RFC 796

Subnet mask Masking value to find a subnet address from an IP address

RFC 950

Checksum Sum of check values. A method used to check whether or not transmitted data has an error in data transmission.

RFC 791

Node Each computer or terminal in a network -

7 JEM-TR 213: 2006

Abbreviation Term in English Explanation Reference

Broadcast Data transmission not to a specific host but to all IP devices

RFC 922

6. Performance 6.1 Cyclic data

It is desirable for one-way throughput in 32 nodes to be less than or equal to 50ms, provided the total

amount of data for the whole 32 nodes is 2 048bits +2 048 words. In case that the allocation of node common

memory is “4 words for area 1” and “64 words for area 2”, it is desirable that the time from reception of a token

till transmission of the token to next node be 1.56 ms or less.

6.2 Message transmission

500ms or less is desirable for transmission time of a one-way transparent message from a node to another in

32-node network with cyclic data of 2 048 bits +2 048 words.

7. Hardware 7.1 Timer resolution

The token watchdog timer shall work at a resolution of one (1) ms. Its tolerance may be up to ±50 ％.

7.2 Generation of random numbers

Method for generating random numbers used in the version of sequence number shall be equipped as either

hardware or software.

7.3 Transmission status indication

The system shall be equipped with the following five indicators as basics provided data transmission status

is indicated by LED (light emitting diode) indicators.

Any color LED indicator can be used. But, basically, green is used to indicate a normal status and red is

used to indicate an abnormal status.

Table 3 Recommended transmission status indicators

Status Symbol Explanation

Sending

TX

Receiving RX

These indicators use the output of the JIS X 5252 controller. If some reason does not allow the two separate indicators, “TX” and ”RX”, a single indicator “COM” (Sending/Receiving) can replace them.

Communication Error

LER/LE The indicator “LER/LE” indicates whether the system is connected to the FA link. Alternatively, it may indicate when the communication is normal. In this case, the status is “Communication Normal” and Symbol is “LNK/LN”.

Unit Error HER/HE This indicator “HER/HE” indicates that the unit must be replaced.

8 JEM-TR 213: 2006


Parameter Error PER/PE Alternatively, “HER/HE” may indicate that the system is normal. In this case, the status is “Unit Normal” and the symbol is “RUN/RN”. If some reason does not allow the two separate indicators, “HER/HE” and ”PER/PE”, a single indicator can replace them. In this case, the indicator should light continuously for “Unit Error” and blink for “Parameter Error”. The symbol is “ERR/ER”.

Status indication in Table 4 is optional.

Table 4 Optional status indicator


Power-on PWR/POW It shall be provided if nearby units do not offer the power indication.

7.4 Node number switch

The node number shall be set either by an external switch or by a program in the upper layer of the FL-net.

Two 4-bit switches (capable of setting hexadecimal values) shall be provided if setting by switch is selected.

7.5 Connectors

Recommended transmission methods, connectors and cables are shown in Table 5.

Table 5 Transmission methods, connectors and cables

Transmission method

Connector Cable

10BASE-5 AUI connector (D-sub15 pins) AUI cable

10BASE-2 N-type connector (RG58A/U connector) Coaxial cable

10BASE-T RJ-45 connector Twisted cable

100BASE-TX RJ-45 connector Twisted cable

100BASE-FX SC connector/ST connector Optical fiber (Muti mode/Single mode)

Connectors and cables based on other specifications are also applicable.

7.6 Grounding and shield

Manufacturers can select grounding and shield practice optionally, which should be described in the

manuals.

7.7 Memory resources

The system shall provide 17 408 bytes or more common memory to support cyclic transmission. It shall

provide 8 (eight) or more received-message queue-buffers, each of which can process 1 024 bytes of data, to

support message transmission.

8. Classification The following two classes are defined considering differences among necessities of FL-net transmission

functions for various devices.

9 JEM-TR 213: 2006

Table 6 Implementation class of FL-net

Cyclic transmission Message transmission Class

Sending Receiving Client function Server function

1 Mandatory Mandatory Optional Optional

2 Not applicable Optional Optional Optional

Remarks

1. “Sending“ of “cyclic transmission” indicates a function that the node allocates

common memory and that it transmits data in the common memory of the own

node to other nodes cyclically.

2. “Receiving“ of “cyclic transmission” indicates a function that the system receives

data from the common memory of other nodes cyclically.

3. The “client function” of “message transmission” indicates a function that the node

transmits request messages and that it receives response messages.

4. The “server function” of “message transmission” indicates that the node processes

request messages and that it returns response messages.

9. Presentation of information

9.1 Software version of network device

The software version of each network device that implements the FA link protocol shall be recognized at a

glance (without removing the device from the equipment).

Examples are as follows:

Identification by a maintenance tool

Identification label or the like attached so that it can be easily read.

9.2 Vendor code and manufacturer model name

The vendor code shall be unique for each manufacturer.

The vendor code shall be 5 to 10 bytes long.

Each manufacturer can define manufacturer model name for its product. The manufacturer model

names shall be unique for devices and shall be equal to or more than 5 bytes long.

If the name data length is less than these specified bytes, all blanks in the name field must be filled

with space characters.

9.3 Status information

Table 7 shows status information identifiable by the upper layer accompanied by its conforming level.

Table 7 Status information tables identifiable by the upper layer and its conforming level

Table name Information Conforming

level

Own-node management Node number Mandatory

table Area 1 data top address Optional

Area 1 data size Optional

Area 2 data top address Optional

Area 2 data size Optional

10 JEM-TR 213: 2006

Table name Information Conforming

level

Upper layer status Mandatory

Token watchdog time Optional

Allowable minimum frame interval

time

Optional

Vendor code Optional

Manufacturer model name Optional

Node name Optional

Protocol type Optional

FA link status Mandatory

Own-node status Mandatory

Participating node Node number Mandatory

management table Upper layer status Mandatory

Area 1 data top address Mandatory

Area 1 data size Mandatory

Area 2 data top address Mandatory

Area 2 data size Mandatory

Allowable refresh cycle time Optional

Token monitoring time Optional

Allowable minimum frame interval

time

Optional

FA link status Mandatory

Network management Token holding node number Optional

table Allowable minimum frame interval

time

Mandatory

Allowable refresh cycle time Optional

Refresh cycle measurement time

(Current value)

Mandatory


(Maximum value)

Optional


(Minimum value)

Optional

10. Lower layer protocol 10.1 Basic specifications

It is precondition to install a device with FA link protocol that the device have protocols conforming to

technical information shown in Table 8.

11 JEM-TR 213: 2006

Table 8 Protocols and their standard and technical information to install FA link protocol

OSI layer Protocol Conforming standards and technical information

Conforming level

Physical layer JIS X 5252 Mandatory

Ethernet RFC 894 Mandatory Data link layer

ARP RFC 826 Optional

IP RFC 791 Mandatory

ICMP RFC 792 Optional

Broadcast-related RFC 919, RFC 922 Mandatory

Network layer

Subnet-related RFC 950 Optional

Transport layer UDP RFC 768 Mandatory

10.2 Physical and data link layer 10BASE-5, 10BASE-2, 10BASE-T, 100BASE-TX and 100BASE-FX are recommended. 100BASE-T2 and

100BASE-T4 are also applicable.

10.3 Network layer

The IP address of FL-net shall be Class C (RFC 791) and use 192.168.250.N as default. N=255 is used as a

broadcast address (RFC 919). The host address (N: 1 to 254) for the lower layer should be equal to the node

number of the FL-net. The network layer shall be able to receive 255.255.255.255 that is defined as the

broadcast address.

10.4 Transport layer

It is recommended to send UDP with a checksum (RFC 768) value of zero (0). In this case, the receiving node

does not check the checksum value.

10.5 Address setting

Figure 1 explains addresses used in each layer. It shows the relation between the OSI basic reference model

of the ISO standards and the protocol specifications of the FL-net.

12 JEM-TR 213: 2006

Figure 1 Relation between OSI basic reference model of ISO standards and FL-net protocol specifications

a) MAC address The default set in the device is used as the MAC address.

b) IP address The IP address is set from the upper layer of the FA link. The subnet (RFC 950) mask is also

set from the upper layer of the FA link. The typical value of the transmission source is specified as

192.168.250.N (N=node number: 1 to 254). The typical value of the transmission destination is specified

as 192.168.250.255. For the IP address, class C is used and its structure is shown in Figure 2.

It is recommended that the lower host address be matched with the FA link protocol node number.

Remark 1. When class C addresses are expressed in decimal, they are AAA.BBB.CCC.0 to

AA.BBB.CCC.255, being 256 addresses in total. Of these, AAA.BBB.CCC.0 and

AAA.BBB.CCC.255 are used as the subnet mask address and the broadcast address.

Accordingly, 254 addresses of AAA.BBB.CCC.1 to AAA.BBB.CCC.254 are used in the FL-

net.

2. In the figure, b31, b28, b27, b8, b7 and b0 show bit addresses.

Figure 2 Structure of IP address

FA link layer

ISO/IEC 8802-3

Controller interface

(FL-net protocol specifications)

Application

Transport layer

Network layer

Data link layer

Physical layer

Session layer

Presentation layer

Application layer

1

2

3

4

5

6

Layer7

(OSI basic reference model)

UDP layer

IP layer

Data link layer

Port number

IP address

MAC address

FA link lower layer

Controller programs

1 1 0 x Network address Host address

b31 b28 b27 b8 b7 b0

Fixed

13 JEM-TR 213: 2006

c) Port number

1) For reception

1.1) Token frame and cyclic frame port number (For system: 55 000 fixed)

1.2) Message frame port number (For system: 55 001 fixed)

1.3) Trigger frame and participation request frame port number (For system: 55 002 fixed)

2) For transmission

2.1) Transmission port number (For system: 55 003 fixed)

11. Frame structure Figure 3 shows the frame structure for each layer of the network.

Figure 3 Frame structure for each layer of network

12. FA link protocol 12.1 In-ring and out-ring management

12.1.1 In-ring and out-ring of other nodes

a) Basic concept A node manages the in-ring/out-ring status of other nodes by the order of the token

circulation. Basically, a node does not judge out-ring of other nodes by its own timer for the node. This is

to eliminate inconsistent out-ring judgment, which would be influenced by the timer precision among

nodes.

b) Token watchdog time Each node shall implement token watchdog timers. When a watchdog timer

FA link data UDP header IP header Ethernet header FCS

FA link data UDP header IP header

FA link data UDP header

User data FA link header

User data

UDP segment

IP datagram

1 024 octets or less

64 to 96 octets or less

8 octets or less

20 octets or less

14 octets or less

Frame

Upper application

layer

FA link layer

Lower layer

of FA link

14 JEM-TR 213: 2006

expires, the node shall set another watchdog timer for the next node to the time-out node. At this time,

it does not execute out-ring process for the time-out node except the next node is itself. At the latter case,

out-ring process shall be executed, so that a new token frame may be sent in an order other than the one

in normal token circulation.

c) Participation to network Participation processing is executed when the sequence of a token flow is

different from what is expected (in case the number of nodes increases). When the node number of the

latest cyclic frame transmission source is not found in the “participating node management table”,

information pertaining to the node is set in the management table.

d) Exit from network Exit processing is executed when the token flow sequence is different from what is

expected (in case the number of nodes decreases). The “out-ring counter” is incremented by one to the

node between the source node issuing the previous token and another source node issuing the current

token.

The node whose out-ring count reaches a preset value of 3 is treated as an out-ringed node. (The

secession of the node is notified to the upper layer through the participating node management table.)

12.1.2 Out-ring of own-node

a) Time-out processing The own-node secedes from the network when the token holding time expires three

times. The own-node notifies it to the upper layer and the own-node status in the “own-node management

table” is changed.

b) Token holding time The token holding time is set as a value less than the token watchdog time. In that

case, it shall have a sufficient margin, considering time delay by internal processing of each node.

12.2 Cyclic transmission

12.2.1 Implementation

For “class 1” node, the data exchange services by cyclic transmission shall be implemented. The node, which

does not require data exchange via the common memory, may implement the token management only as

“class 2”. When a node belongs to class 2 and does not support the cyclic transmission function, it sets both the

address and size of common memory to zero and deactivates the “common memory setting completion” flag.

12.2.2 Transmission data size

The transmission data size may be any of up to 17 408 bytes. In other words, a node can transmit data of up to

17 408 bytes.

12.2.3 Reception data size

A node shall receive data of up to 17 408 bytes, the maximum data size.

12.2.4 Common memory

When a cyclic transmission function is implemented, common memory (a total of area 1 and area 2) must have

17 408 bytes or more.

The following conditions shall be considered so that a node may have more than 17 408-byte common

memory.

1) Common memory size will be checked when the upper layer sets the own-node common memory.

2) Common memory size will not be checked when the common memory setting of other nodes is written in

the participating node management table.

3) A receiving node who does not have the area registered in the participating node management table

discards the corresponding data without writing in the common memory.

15 JEM-TR 213: 2006

4) A node who receives data that is more than the common memory area size (17 408 bytes) discards the

exceeding portion of the data.

a) Common memory data Data in the common memory is defined as 16-bit word arrays. These data arrays

are transferred as little-endian data through the network. Each vendor shall provide documents on

handling and processing of “MSB, LSB, and byte strings” of data in the common memory.

b) Common memory data and their allocation to user programs Allocation of the common memory data to

user programs of respective devices is left to vendors. If the user program cannot recognize the common

memory data as it is the vendor shall provide a table correlating common memory data to user program

addresses.

12.3 Message transmission

12.3.1 Implementation requirements

Table 9 lists implementation requirements for message services of the FA link protocol.

Table 9 Implementation requirements for message services

Server function Client function Message type

1 to 1 (peer-to-peer)

1 to n (broadcast)

1 to 1 (peer-to-peer)

1 to n (broadcast)

Byte block read Optional None Optional None

Byte block write Optional None Optional None

Word block read Optional None Optional None

Word block write Optional None Optional None

Network parameter read Mandatory None Optional None

Network parameter write Optional None Optional None

Stop command Optional None Optional None

Start command Optional None Optional None

Profile read Mandatory None Optional None

Log data read Mandatory None Optional None

Log data clear Mandatory Mandatory Optional Optional

Echo back message Mandatory None Optional None

Vendor specific message Optional Optional Optional Optional

Transparent mode message Optional Optional Optional Optional

The server function is the one that receives request messages, generates response frames, and sends them.

The client function is the one that sends request messages and receives response frames.

Reception of the above messages is usually notified from the FA link layer to the upper layer for processing.

However, “log data read”, “log data clear”, and “echo back message” are not notified to the upper layer, and

processed in the FA link layer.

“Log data clear” shall be processed for a broadcast request because all nodes must process to keep

synchronization.

12.3.2 Request frame and response frame

Receiving peer-to-peer message request frame, the node shall send a response frame. Any node shall not send

a response frame to a broadcast request frame. Messages and TCD Codes currently defined are shown in Table

10. The TCD of a response frame shall be 200 greater than the TCD of the corresponding request frame. When

16 JEM-TR 213: 2006

a node receives a peer-to-peer request frame from another node that is not implemented, it shall send a “non-

implementation” response frame. Also, when a node receives a peer-to-peer request frame with an undefined

TCD (65017 to 65199), it shall transmit a response frame having a TCD that is 200 greater than the TCD of

the request frame and showing “non-implementation”. No response frame may be generated for request

frames with the other TCDs.

Table 10 Messages and TCD Codes TCD Code Message type

Request frame Response frame

Byte block read 65 003 65 203

Byte block write 65 004 65 204

Word block read 65 005 65 205

Word block write 65 006 65 206

Network parameter read 65 007 65 207

Network parameter write 65 008 65 208

Stop command 65 009 65 209

Start command 65 010 65 210

Profile read 65 011 65 211

Log data read 65 013 65 213

Log data clear 65 014 65 214

Echo block message 65 015 65 215

Vendor specific message 65 016 65 216

Transparent mode message 10 000...59 999 10 000...59 999

Because the transparent mode messages do not classify transaction codes (TCD) for request and response

frames, the upper layer need to define request-response distinction.

The response frame to the request frame from the other nodes can be transmitted before ACK header

transmission.

12.3.3 Sequence number management

a) Initial value The sequence number is initialized in startup.

b) Transmission side

1) peer-to-peer transmission In peer-to-peer transmission, the transmitter sets a sequence number for

each node, and it increases one by one each time a transmission succeeds. In case of re-transmission (up

to three times), the same sequence number must be used, and the number increases by one for normal

transmission completion and after three re-transmissions.

2) broadcast transmission In broadcast transmission, the transmitter sets a sequence number for each

network, and it increases one by one each time a transmission completes.

c) Reception side

1) peer-to-peer transmission In peer-to-peer transmission, the receiver stores the sequence number when

the message has been processed normally. If the sequence number of the next received message is equal

to the stored one, the node returns an ACK reply as a re-transmission request. If the sequence number

is not equal to the stored one, the node processes the message asa new message and returns ACK.

2) broadcast transmission In broadcast transmission, the receiver stores the sequence number

unconditionally. A node does not check whether or not the sequence number of the received broadcast

17 JEM-TR 213: 2006

message is correct.

12.3.4 CBN and TBN

CBN and TBN shall not be used.

Remarks These will be used for multi-frame messages in the future.

12.3.5 Note on each message

a) Network parameter read/write message

1) Server function Implementation of the server function to read network parameters is always required.

This processing is executed in the FA link layer.

Implementation of the server function to write network parameters is optional.

2) Client function Implementation of client functions to read and write network parameters is optional.

b) Block data read/write message

1) Server function The server functions to read and write block data may support selectively word- or

byte- data according to the requirement of the application in the FA link upper layer. If the block read

function and block write function are supported, the allocation of the virtual address space shall be

disclosed. When a message is processed, its result shall be transmitted. It is also required to disclose

error codes that will be transmitted when message processing fails.

2) Client function Implementation of the client functions to read and write block data is optional. If

these functions are implemented, it is necessary that an offset address and size of the virtual address

space can be set and transmitted.

c) Size of virtual address space When receiving the request frames of the byte block write and the word

block write, the node shall check whether the size of message data is valid. Behavior upon message

processing failure shall be disclosed.

d) Start /stop command message

1) Server function Implementation of server functions to process the start command and the stop

command is optional. When the message is processed, its result must always be transmitted. It is also

required to disclose error codes that will be transmitted when message processing fails.

2) Client function Implementation of client functions to process start command and stop command is

optional.

e) Profile read message

1) Server function The server function to read profile messages shall be implemented as defined in the

“Device profile common specification for FA control network [FL-net (OPCN-2)]” (JEM-TR 214).

2) Client function The client function to read profile messages is optional.

f) Log data read/clear messages

1) Server function The server function to read and clear log data shall be implemented. There are two

kinds of log data: mandatory items and optional items. It is necessary to disclose the optional log items

that are implemented.

2) Client function The client function to read and clear log data is optional.

A node shall have the function to display the contents of the log data either on request or

continuously.

A log shall contain the following:

2.1) Data pertaining to transmission

18 JEM-TR 213: 2006

Total number of transmissions at socket unit

Total number of transmission errors at socket unit

It is desirable that the log contain the following as Ethernet information:

Number of transmission timeouts

2.2) Data pertaining to reception

Total number of receptions at socket unit

Total number of reception errors at socket unit

It is desirable that the log contain the following as Ethernet information:

Number of frames discarded

Number of CRC error frames received

Number of frame size errors received

2.3) Data pertaining to cyclic transmission

Number of cyclic reception errors

2.4) Data pertaining to message transmission

Number of message retransmissions

Number of message over-retransmissions

Number of message reception errors

2.5) Data pertaining to ACK

Number of ACK errors

2.6) Data pertaining to token

Number of token multiplications recognized

Number of tokens discarded

Number of tokens re-issued

2.7) Data pertaining to status

Number of frame waiting states

Number of participations

Number of self-exits

Number of exits by skipping

Number of exits of other nodes recognized

Table 11 shows log data and format.

Each item of data is 4 bytes long.

Table 11 Log data and format

Offset Data name Explanation Implemen-tation

0 Total number of transmissions at socket unit

Data pertaining to transmission and reception

Mandatory

4 Total number of transmission errors at socket unit


Mandatory

8 Number of Ethernet transmission errors Data pertaining to transmission and reception

Optional

12 - Data pertaining to transmission and reception (Reserved)

-

19 JEM-TR 213: 2006



-


-

24 Total number of receptions at socket unit Data pertaining to transmission and reception

Optional

28 Total number of reception errors at socket unit


Mandatory

32 Number of Ethernet reception errors Data pertaining to transmission and reception

Optional


-


-


-

48 Number of tokens transmitted Data pertaining to frame types Optional

52 Number of cyclic frames transmitted Data pertaining to frame types Optional

56 Number of peer-to-peer messages transmitted

Data pertaining to frame types Optional

60 Number of broadcast messages transmitted

Data pertaining to frame types Optional

64 - Data pertaining to frame types (Reserved) -


72 Number of tokens received Data pertaining to frame types Optional

76 Number of cyclic frames received Data pertaining to frame types Optional

80 Number of peer-to-peer messages received Data pertaining to frame types Optional

84 Number of broadcast messages received Data pertaining to frame types Optional



96 Number of cyclic reception errors Data pertaining to cyclic transmission Mandatory

100 Number of cyclic address size-errors Data pertaining to cyclic transmission Optional

104 Number of cyclic CBN errors Data pertaining to cyclic transmission Optional

108 Number of cyclic TBN errors Data pertaining to cyclic transmission Optional

112 Number of cyclic BSIZE errors Data pertaining to cyclic transmission Optional

116 - Data pertaining to cyclic transmission (Reserved)

-


-


-


-


-

20 JEM-TR 213: 2006



-


-

144 Number of message retransmissions Data pertaining to message transmission Mandatory

148 Number of message over-retransmissions Data pertaining to message transmission Mandatory

152 - Data pertaining to message transmission (Reserved)

-


-


-


-

168 Number of message reception errors Data pertaining to message transmission Mandatory

172 Number of message version-of-sequence number errors

Data pertaining to message transmission Optional

176 Number of message sequence number retransmissions recognized

Data pertaining to message transmission Optional


-


-


-

192 Numbers of ACK errors Data pertaining to ACK Mandatory

196 Number of ACK version-of-sequence number errors

Data pertaining to ACK Optional

200 Number of ACK sequence number errors Data pertaining to ACK Optional

204 Number of ACK node number errors Data pertaining to ACK Optional

208 Number of ACK TCD errors Data pertaining to ACK Optional

212 - Data pertaining to ACK (Reserved) -







240 Number of token multiplications recognized

Data pertaining to token Mandatory

244 Number of tokens discarded Data pertaining to token Mandatory

248 Number of tokens re-issued Data pertaining to token Mandatory

252 - Data pertaining to token (Reserved) -



21 JEM-TR 213: 2006


264 Number of token holding timeouts Data pertaining to token Optional

268 Number of token monitoring timeouts Data pertaining to token Optional





288 Total service time Data pertaining to service status, participation and exit of node

Optional

292 Number of frame waiting states Data pertaining to service status, participation and exit of node

Mandatory

296 Number of participations Data pertaining to service status, participation and exit of node

Mandatory

300 Number of self-exits Data pertaining to service status, participation and exit of node

Mandatory

304 Number of exits by skipping Data pertaining to service status, participation and exit of node

Mandatory

308 Number of exits of other nodes recognized Data pertaining to service status, participation and exit of node

Mandatory

312 - (Reserved) -

316 - (Reserved) -

320 - (Reserved) -

324 - (Reserved) -

328 - (Reserved) -

332 - (Reserved) -

336 List of participation recognized nodes Data pertaining to participation recognized nodes

Optional


Optional


Optional


Optional


Optional


Optional


Optional


Optional

368 - (Reserved) -

372 - (Reserved) -

376 - (Reserved) -

380 - (Reserved) -

384 - (Reserved) -

22 JEM-TR 213: 2006


388 - (Reserved) -

392 - (Reserved) -

396 - (Reserved) -

400 - (Reserved) -

404 - (Reserved) -

408 - (Reserved) -

412 - (Reserved) -

416 - (Reserved) -

420 - (Reserved) -

424 - (Reserved) -

428 - (Reserved) -

432 - (Reserved) -

436 - (Reserved) -

440 - (Reserved) -

444 - (Reserved) -

448 - Data pertaining to manufacturer-definable area (Reserved)

-


-


-


-


-


-


-


-


-


-


-


-


-


-


-

23 JEM-TR 213: 2006



-

g) Echo back message

1) Server function The server function to echo back a message shall be implemented. This function

generates a response frame within the communication unit, and echoes it back. When receiving a

message of TCD number 65 015, a node shall return message data of TCD number 65 215, whose size

and contents are the same as those of the received message, to the transmission source node.

2) Client function Implementation of client function to echo back messages is optional.

h) Vendor specific message

1) Server function Implementation of the server function to process vendor specific messages is optional.

The function is used to provide a specific service specified by the vendor. Vendors can specify the

function. When the node cannot recognize the FA link header (VNAME) of the vendor specific message,

the node transmits a “non-implementation” message (M_RLT=2) as a response message. When the node

cannot recognize the FA link header (SCODE) of the vendor specific message, it transmits an “error

response ” message (M_RLT=2) as a response message. The VNAME of the response frame of the

vendor specific message is the same as that of the request frame, and the SCODE is as specified by the

vendor.

2) Client function Implementation of the client function to process vendor specific messages is optional.

The function is used to provide a specific service specified by the vendor. Vendors can determine the

specifications of the function.

i) Transparent mode message There is no distinction between the server functions and the client functions

because the transparent mode message does not have any pre-determined request message.

Implementation of the transparent mode message functionis optional.

13. Supplement on data consistency 13.1 Setting

13.1.1 Node number

a) Own-node

1) Range check Check whether its node number is in the range of 1 to 254 during startup. (Node

numbers zero and 255 are invalid.) The result of the check is reflected to the “own-node status” of the

own-node management table.

2) Checking of node number duplication Whether the node number already exists is checked in the FA link

layer, and its result is reflected to the “own-node status” of the own-node management table.

b) Other nodes

1) Range check Check whether the other node number is in the range of 1 to 254, when the node receives

a participation request frame from some other node and when it receives the last cyclic frame from a

node whose in-ring status is not recognized. (Node numbers zero and 255 are invalid.) The participating

node management table is built up from the check result.

24 JEM-TR 213: 2006

2) Checking of node number duplication Whether or not the other node number duplicates with the own-

node number is checked in the FA link layer, and the result is reflected to the “own-node status” of the

own-node management table.

13.1.2 Common memory area setting

All initial values shall be set to zero.

a) Setting by upper layer

1) Range check When the common memory allocation is set by the upper layer, the area size of the

common memory shall be checked. At the time of startup and setting, the FA link layer shall check the

area size (area 1 of up to 1 024 bytes and area 2 of up to 16 384 bytes). The result of the check is

reflected to the “own-node status” of the own-node management table.

2) Address overlapping check The address overlapping check shall be executed when the node requests to

participate in the network. In the in-ringed state, the address overlapping check will not be executed.

The check result is reflected to the “FA link status” of the own-node management table.

b) Setting by the network

1) Range check When the common memory allocation is set by the network, the area size of the common

memory is not checked. Therefore no error information is output. Vendors shall describe behavior of

their nodes upon this case in their manuals.

If the received cyclic data exceeds the common memory area of the own-node, the excess data is

discarded and only the data corresponding to the common memory area size is copied.

2) Address overlapping check A node checks whether or not the addresses in the own-node information

and in the information of other nodes overlap each other. However, it does not check possible overlaps

among other nodes. If an overlapping address is found in the settings on the own-node, it is notified to

the upper layer. It is not notified to the other node that made the setting.

c) Processing in in-ringed state Check the common memory settings of the cyclic frame and the token frame,

and also those in the participating node management table.

25 JEM-TR 213: 2006

13.1.3 LKS (FA link status) of node management information

a) LKS bits-0 and -1 in the node management information may be used as status information to notify the

upper layer as shown in Figure 4. (Its implementation is optional.)

These LKS bits-0 and -1 may be used only to notify the upper layer, and the corresponding bit positions of the

protocol shall be fixed values (zero).

The “in-ring/out-ring” flag of a node shows that the node is in-ringed or out-ringed. The “communication

invalidity” flag shows that there is a frame of different token mode in the network.

LKS

0 1 2 3 4 5 6 7

0 0

Node status on in-ring/out-ring →(0: in-ring, 1: out-ring)

Communication invalidity →(0: not detected, 1: detected)

Reserved

Upper layer operation signal error

Common memory data validity notification

Common memory (top address/size) setting completion

Address overlapping detection

Figure 4 LKS Data

13.1.4 Coexistence of devices with different token modes

a) Coexistence of devices with different token modes (TM) in the FA link header “MODE” is inhibited. Table

12 shows that devices with different token modes can be connected to each other or not.

Table 12 Connectability of devices with different token modes

Self-device

Other device

Device with TM = 0 Device with TM = 1

Device with TM = 0 P N

Device with TM = 1 N P

Remarks P: Connection is permitted, N: Connection is inhibited

a) Table 13 shows the behavior of a device whose TM is one (1) while devices with different token modes

coexist.

26 JEM-TR 213: 2006

Table 13 Behavior of TM=1 device while devices with different token modes coexist

State in case of coexistence Behavior of TM=1 device

Startup state When the node recognizes a frame of a TM=0 device, it discards the frame, does not

issue the participation request frame, transits to the “startup request” state in the state

transition, and does not participate in the data link.

The node sets the “communication invalidity” flag in the LKS of the own-node

management information. (Its implementation practiceis optional.)

In-ring startup of TM=0

device to TM=1 device data

link

When the node recognizes a frame of a TM=0 device, it discards the frame, and holds its

participation in the data link.

The node sets the “communication invalidity” flag in the LKS of the TM=0 device node

management information. (Its implementation practice is optional.)

In-ring startup of TM=1

device to TM=0 device data

link

When the node recognizes a frame of a TM=0 device, it discards the frame, does not

issue the participation request frame, transits to the “startup request” state in the state

transition, and does not participate in the data link.

The node sets the “communication invalidity” flag in the LKS of the own-node


Connection of TM=0 device

data link and TM=1 device

data link

When the node recognizes a frame of a TM=0 device, it discards the frame.

The data link behavior of the network as a whole is not guaranteed.

The node sets the “communication invalidity” flag in the LKS of the TM=0 device node


1) In either case of Table 13, a data link cannot be configured between the devices where their token

modes of FA link header MODE differ with each other.

13.2 Notes on FA link headers

The FA link header’s parameters that need be set when sending a frame and that shall be checked when

receiving are specified below.

13.2.1 Transmission

Table 14 shows the FA link header’s parameters of the transmission frame.

Table 14 FA link header’s parameters of the transmission frame

Symbol Name Cyclic header (TBN‡CBN)

Last cyclic header

(TBN=CBN)

Token header

Message header

Participation request/trigger

header

Explanation

H_TYPE Header type R R R R R Sets a fixed value for every frame.


R R R (Fixed as 64)

R R (Fixed as 96)

Sets for every frame.

SA (Except SNA)

Source address R R R R R Sets for every frame.

27 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation

DA (Except DNA)

Destination address

R R R R R Sets for every frame.







SEQ Sequence number

N N N R N Sets for a message frame.





RPL Existence of

transmission

acknowledgment

(ACK) data

R (Fixed as 0)

R R (Fixed as 0)

N N Sets for the last cyclic frame. Sets zero (0) for a cyclic frame except above and a token frame.


N R R N N Sets for the last cyclic frame and a token frame.


N N N R N Sets for a “block data read/write” message frame.

M_ADD Message offset address in virtual address space

N N N R N Sets for a “block data read/write” message frame.


N R R N R Sets the current value for the last cyclic frame, a token frame, and a participation request/trigger frame.

M_RLT Response message result




VER Program version number.

R R R R R Sets a fixed value for every frame.


R R R N R Sets for a (the last) cyclic frame, a token frame, and a participation request/trigger frame.

28 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation







MODE (Except TM)

FA link protocol version


TM Token mode R R R R R Sets a fixed value for every frame.

P_TYPE Protocol type R R R R R Sets a fixed value for every frame.




R R R (Fixed as 1)

R N Sets a calculated value for a (the last) cyclic frame. Sets a fixed value for a token frame. Sets a value notified from the upper layer for a message frame.


R R R (Fixed as 1)

R N Sets a calculated value for a (the last) cyclic frame. Sets a fixed value for a token frame. Sets a value notified from the upper layer for a message frame.


R R R (Fixed as 64)

R R (Fixed as 96)

Sets for every frame.

LKS FA link status N R R N N Sets a current value for the last cyclic frame and a token frame.


N R R N R Sets for the last cyclic frame, a token frame, and a participation request/trigger frame.

29 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation


N R R N N Sets a current value for the last cyclic frame and a token frame.

Remarks R: Setting is required. N: Setting is not required. (Setting of zero (0) is recommended. For a

cyclic header, it is recommended to set the same value as that of the last cyclic header.)

13.2.2 Reception

a) Table 15 shows the FA link header’s parameters of the reception frame in in-ring status.

Table 15 FA link header’s parameters of the reception frame (in-ring status)

Symbol Name Cyclic header (TBN‡ CBN)

Last cyclic header

(TBN= CBN)

Token header

Message header


header

Explanation

H_TYPE Header type M M M M M Checks for every frame.


N N N M M Checks for a message frame and a participation request/trigger frame. (It is recommended to check for every frame.)

SA (Except SNA)

Source address N N N N N Does not check for any frame

DA (Except DNA)

Destination address

N N N N N Does not check for any frame


M M M M M Checks for every frame. Generates the participating node management table for a participation request/trigger frame and the last cyclic frame sent from a node whose in-ring has not been recognized. Used to transmit ACK for a message frame.


N N M M N Checks for a token frame and a message frame. The DNA of a token frame indicates a node number having the next token.


N N N M N Checks for a message frame.

SEQ Sequence number


30 JEM-TR 213: 2006


Last cyclic header

(TBN= CBN)

Token header

Message header


header

Explanation


N N N U N Notifies it to the upper layer unconditionally with a message frame. It is not necessary to check its value.



RPL Existence of

transmission

acknowledgment

(ACK) data

N M N N N Checks for the last cyclic frame whether the frame has ACK.


N U N N N Notifies the value of the last cyclic frame to the upper layer. It is not necessary to check its value.






N U N N U Generates the participating node management table for a participation request/trigger frame and the last cyclic frame sent from a node whose in-ring has not been recognized. It is not necessary to check its value.




M M M M M Checks for every frame.



31 JEM-TR 213: 2006


Last cyclic header

(TBN= CBN)

Token header

Message header


header

Explanation


N M N N M Checks consistency with the participating node management table for the last cyclic frame. Generates the participating node management table for a participation request/trigger frame.







MODE (Except TM)



TM Token mode M M M M M Checks for every frame.

P_TYPE Protocol type N N N N N Does not check for any frame




M M M N N Checks for a (the last) cyclic frame and a token frame.



32 JEM-TR 213: 2006


Last cyclic header

(TBN= CBN)

Token header

Message header


header

Explanation



LKS FA link status N U N N N Notifies it to the upper layer unconditionally with the last cyclic frame. It is not necessary to check its value.




N U N N N Notifies it to the upper layer unconditionally with the last cyclic frame. It is not necessary to check its value.

Remarks M: Must be checked, N: Need not be checked, U: Used, but need not be checked

b) Table 16 shows the FA link header’s parameters of the reception frame in joining operation (network

startup state and in-ring startup state).

Table 16 FA link header’s parameters of the reception frame (in joining operation status)


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation

H_TYPE Header type M M M M M Checks for every frame.


N N N N M Checks for a participation request/trigger frame. (It is recommended to check for every frame.)

SA (Except SNA)

Source address N N N N N Does not check for any frame

DA (Except DNA)

Destination address


33 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation


N M M N M Checks for the last cyclic frame, a token frame, and a participation request/trigger frame. Generates the participating node management table for a participation request/trigger frame and the last cyclic frame sent from a node whose in-ring has not been recognized.


N N M N N Checks for a token frame. The DNA of a token frame indicates a node number having the next token.



SEQ Sequence number






RPL Existence of

transmission

acknowledgment

(ACK) data



N U N N N Notifies the value of the last cyclic frame to the upper layer. It is not necessary to check its value.





34 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation






M M M N M Checks for a (the last) cyclic frame, a token frame, and a participation request/trigger frame.




N M N N M Generates the participating node management table for a participation request/trigger frame and the last cyclic frame sent from a node whose in-ring has not been recognized.







35 JEM-TR 213: 2006


Last cyclic header

(TBN=CBN)

Token header

Message header


header

Explanation

MODE (Except TM)



TM Token mode N M M N M Checks for the last cyclic frame, a token frame, and a participation request/trigger frame. (It is recommended to check for every frame.)。

P_TYPE Protocol type N N N N N Does not check for anyframe









LKS FA link status N U N N N Notifies it to the upper layer unconditionally with the last cyclic frame. It is not necessary to check its value.




N U N N N Notifies it to the upper layer unconditionally with the last cyclic frame. It is not necessary to check its value.

Remarks M: Must be checked, N: Need not be checked, U: Used, but need not be checked

14. TCD reception behavior at UDP port Table 17 shows the behavior of the UDP (user datagram protocol) ports defined in the FL-net (OPCN-2) when it

receives a frame corresponding to TCD (transaction code). In case a UDP port not defined in the FL-net

(OPCN-2) receives a frame, it is optional to discard or process it.

36 JEM-TR 213: 2006

Table 17 TCD reception in UDP port

TCD For token frame and

cyclic frame

(UDP port=55 000)

For message frame

(UDP port=55 001)

For trigger frame and

participation request

(UDP port=55 002)

00 000...09 999 Discarded Processed or Discarded Discarded

10 000...59 999 Discarded Processed (For Transparent

message)

Discarded

60 000...64 999 Discarded Discarded Discarded

65 000...65 001 Processed Discarded Discarded

65 002 Discarded Discarded Processed

65 003...65 011 Discarded Processed Discarded

65 012 Discarded Discarded Processed


65 017...65 199 Discarded Processed as not yet supported

(Returns M_RLT=2 response.)

Discarded



65 212 Discarded Discarded Discarded


65 217...65 399 Discarded Processed or Discarded Discarded


Remarks While a TCD is defined, the same code number shall not be assigned even if UDP port

numbers are different.

JEM-TR 213: 2006

Implementation guidelines for FA control network [FL-net (OPCN-2)]

Explanation

This article comments on the contents specified and described in the body of this technical report, and

explains the circumstances related to this technical report. The article is not a part of the technical report.

1. Purpose and particulars of establishment, development and revision

1.1 Purpose and particulars of establishment The Japan Electrical Manufacturers’ Association (hereafter

abbreviated as JEMA) established “Field network standard for programmable controller (level 1): OPCN-1” as

the communication network standard to connect programmable controllers and field devices. Furthermore,

JEMA has studied the standardization of the network among upper-level programmable controllers. As a result,

JEMA decided to adopt “FA control network: FL-net”, which the Manufacturing Science & Technology Center

(hereafter abbreviated as MSTC) had developed, as the upper level network standard (OPCN-2).

For specifications, the FL-net has used not only “protocol specifications” as a basis, but also various other

specifications such as “conformance test specifications” and “interconnectibility test specifications” for the

certification test, “device profile common specifications” on device profiles. This technical report specifies

functions to be implemented when equipment is manufactured on the basis of JIS B 3521 “Protocol specification

for FA control network standard”.

1.2 Purpose of revision As revision issued on Febrary 28, 2002, a token mode that was newly specified in

the protocol specification must be implemented and the cyclic frame data with a token has been separated into

two frames, that is, a frame with cyclic data only and a frame with a token only. As a result of this revision,

description of behaviors upon co-existence of both devices with the token mode and without the mode is added to

this technical report. Furthermore, revisions on the detailed specifications have been made and their

description has been added following experiences.

1.3 Purpose of revision 2006 Considering market trends for the network products according to JIS X

5252 on which FL-net is based, some of the description were added or revised to accomodate 100Mbps

standard specified in JIS X 5252.

2. Future trend on JIS X 5252 network The JIS X 5252 network specification, which is the basis of the FL-

net, is the standard based on the protocol developed by Xerox, DEC and Intel in 1978.

Cables used as communication media are standardized as the EIA/TIA-568 standard established by the

Electronic Industries Association and Telecommunications Industry Association in the United States. They are

classified into three types: twisted pair cables (10 BASE-T and 100 BASE-T), coaxial cables (10 BASE2 and

10 BASE5) and optical fiber cables (10 BASE-F, 100 BASE-FX and FDDI). Such expressions as 10 BASE

(10 Mbps), 100 BASE (100 Mbps), etc. are used, depending on transmission speed.

Furthermore, standardization of wireless data communication using radio waves and infrared rays as

JEM-TR 213：2006

communication media is in progress.

3. RFC rules RFC (Request for Comments) is referred in the body of this technical report. It is a series of

formal documents published as proposals from discussions in the Internet Community of IETF (The Internet

Engineering Task Force). The contents of the RFC are open to the public in various web sites of IETF etc. Refer

to these web sites for details.

Documents

JEM TR 213 Implementation Guidelines of FA …...JEM-TR 213 TECHNICAL REPORT OF THE JAPAN ELECTRICAL MANUFACTURERS’ ASSOCIATION JEM-TR 213 Implementation Guidelines of FA Control