STANDARD OF
THE JAPAN
ELECTRICAL
MANUFACTURERS’ASSOCIATION

JEM
1479
First edition
2000-11-28
Third edition
2012-09-27

Protocol Specification for
FA Control Network Standard

In case of any doubt arising as to this English edition, the original
JEM 1479 in Japanese shall prevail.

Reference number
JEM 1479:2012(J)JEM 1479：2012

CONTENTS
Page

Introduction ························································································································· 1
1

Scope··························································································································· 22References ···················································································································· 23

Terms and definitions ······································································································· 24Notation and Abbreviation ································································································· 6

4.1
Notation ················································································································ 6
4.2
Abbreviation ·········································································································· 6
5 Product Categories·········································································································· 96Basic Specifications ········································································································ 12

6.1
Relation between OSI Reference Model and FL-net ······················································ 12
6.2
The number of nodes to be connected········································································ 13
6.3
UDP and TCP superimposition ················································································· 13
6.4
Load Measure Function ··························································································· 15
6.5
General purpose Command Server Function ······························································· 16
6.6
Device level network function ··················································································· 17
7 Service ························································································································ 20
7.1
Common Memory ·································································································· 21
7.2
Message Transmission ··························································································· 25
7.3
Network Management Service ·················································································· 43
7.4
Load Measure Service ···························································································· 47
7.5
IO Allocation Setting Service ···················································································· 48
7.6Service to lower layers ···························································································· 49
7.7
Solicitation frame transmission service ······································································· 50
8 Functions ····················································································································· 53
8.1
Node ID (no.) ········································································································ 53
8.2
Protocol data unit ··································································································· 53
8.3
Octet order ··········································································································· 55
8.4
General purpose command server ············································································· 57
8.5
System Configuration of Device Level Network Function ················································ 73
8.6
IO Definition ········································································································· 80
8.7Timer ·················································································································· 99
9 Operation ··················································································································· 101
9.1
Management of Transmission Right ········································································· 101
9.2
Joining and Disengaging Node ··············································································· 103
9.3
Data Communication between Nodes······································································· 107
9.4
Device Level Network ··························································································· 113
10 FA Link Frame Format ·································································································· 121
10.1
10.2
10.3
10.4
10.5
10.6

Header Format ···································································································· 121
ACK Data··········································································································· 136
User Data ·········································································································· 138
Solicitation frame ································································································· 146
IO Allocation Setting Frame ··················································································· 149
IO Allocation and Read Frame ················································································ 153

JEM 1479：2012

10.7 Token Retention Time Measuring Flame ··································································· 156
10.8 The Message Frame of General Purpose Communication Data Sender Log ····················· 159
10.9 Configuration Parameter Setting Frame ···································································· 162
10.10 Participating Node Management Information Parameter Read Frame ····························· 165
10.11 Read frame of self node management information parameter ······································· 169
10.12 Read Frame of Self node Configuration Information Parameter ····································· 176
10.13 Node Reset Frame ······························································································ 179
Appendix A (Reference) The State Transition Diagram of the FA Link Protocol ································ 182
Appendix B (Reference) Log data ·························································································· 199
Appendix C (Reference) Port Number List ··············································································· 205

JEM1479：2012

The Japan Electrical Manufacturers’ Association Standard____________PROTOCOL SPECIFICATIONFOR FA CONTROL NETWORK STANDARDFOREWORD FOR THE ENGLISH EDITION
This document is English translation of JEM 14 79 that is written in Japanese for convenience
to users and developers of FL-net who feel difficult to understand Japanese language.
Therefore, the JEM 1479 (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 Specification of the Special
Committee for FL-net Promotion at JEMA, which worked on the translation, welcomescomments and questions on English expression, which will help it for future improvement.

JEM 1479：2012

FOREWORD
This is the standard of the Japan Electrical Manufacturers’ Association deliberated by theWorking Group on Specification, the Special Committee for FL-net Promotion and theStandardization Committee, and revised by the Steering Technical Committee.
It should be remarked that some parts of this standard may conflict with patent rights totechnical properties, patent right registration applications after application public re lease,patent rights for utility articles, or patent right registration application 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 rightapplications after application public release, patent rights for utility articles, or patent rightapplications for utility articles after application public release.

–1–

JEM1479：2012

PROTOCOL SPECIFICATION FOR FA CONTROL NETWORK STANDARD

Introduction
This standard applies to portable type a.c. generating sets driven by diesel engine or gasoline
engine having rated output power above 3 kVA and less than 1 0 kVA.
This document provides protocol specifications for controller-level to device level networks for
efficiently executing data exchange between various control units in manufacturing systems offactory CIMs such as programmable logic controllers (hereinafter referred to as PLC), robot
controllers (hereinafter referred to as RC), numerical control units (hereinafter referred to asNC), FA controllers, and personal computers for control purposes (hereinafter referred to as
personal computers).
Figure 1 shows the positioning of the FA control n etwork covered by this document in the
OSI/CIM model.

CIM model
Level 6

Central host computerEnterprise
Level 5

Factory hostcomputer
Plant

Management
computer

Backbone network

Level 4
FA computerArea

FA personal computer

Information network

Level 3
FA controller
Cell

Personal computer

Controller-levelnetwork(FL-net Ver.1.00~Ver.3.00)

Level 2
PLC
StationRC

NC

Indicator

Device-levelnetwork(FL-net Ver.3.00)

Level 1
SensorTransducer

PLC
Remote IO

Manifold
solenoidvalve

ID card controller
Bar code reader

Equipment

Figure 1 - Positioning of FL-net in OSI/CIM Model

InverterservoIntelligent
indicator

–2–

JEM1479：2012
1

Scope

This document prescribes the protocol specifications for the FA control network (FL-net
1)(OPCN-2) (hereinafter referred to as FL-net)) which covers two level networks; thecontroller-level network between PLC, RC, NC, and FA controllers or personal computers, andthe device level network for device level communication between PLC, FA controllers,personal computers, and input/output devices and drive controllers.
The FL-net has the following versions.
―

JEM 1479: 2000 version is expressed as Ver. 1.00.

―

Devices manufactured and certified based on JEM 1479: 2000 are expressed as Ver. 1.00
devices.

―

JIS B 3521: 2004 and JEM 1479: 2002 versions are expressed as Ver. 2.00.

―

Devices manufactured and certified based on JIS B 3521: 2004 are expressed as Ver. 2.00
devices.

―

JEM 1479: 2012 version is expressed as Ver. 3.01.

―

Devices manufactured based on JEM 1479:2012 and certified at the implementation classes 3 to
7 are expressed as Ver. 3.01 devices.

The Ver. 1.00 product and the Ver. 2.00 product have no compatibility in connectivity, and thespecification of the Ver. 3.01 products includes that o f Ver. 2.00 and Ver.3.00 products. In thisdocument, description of FL-net Ver. 3.01 is added to the functions specific to Ver. 3.01.
The compatibility of the FL-net is maintained by implementing this specification, whichprescribes network specifications for the FA control network services and protocols, inequipment and/or devices. However, verification of the compatibility and interconnectivity of
implemented products is not included within the scope of this document.
Note 1) Stands for FA Link network (Open Programmable Controller Network - level2).
2

References

The following standards are incorporated to be part of this document by reference. The latest
edition of the references is applied (including addenda).

3

JIS B 3521

Protocol specification for FA control network standard

JIS X 5252

Local and metropolitan area networks - Specific requirements - Part 3: Carrier
sense multiple access with collision detection (CSMA/CD) access method andphysical layer specifications

JEM-TR 214

Device profile common specification for FA control network [FL-net(OPCN-2)]

Terms and definitions

The definitions of the main terms used in this document shall be based on the definition of JIS
B 3521 and the following.
3.1

FA link protocol

A protocol defined to implement the FL-net network. The FA link protocol corresponds to thedata link layer, the network layer, the transport layer, and the application layer, and prescribes
the protocols for token management, cyclic transmission, and message transmission so thateach node can equally perform transmission.
3.2

FA link

An entity to implement the FA link protocol.

–3–
3.3

JEM1479：2012

FA link header

The header information part of a frame defined in the FA link protocol.
3.4

token

A temporary permission granted to use media on the network. A token is successively passed
from one node to another.
3.5

valid linking state

A state in which a token circulates around the several nodes on the network.
3.6

network startup state

The state of a node attempting to participate in the network when not in the valid linking state.
3.7

in-ring startup state

The state of a node attempting to participate in the network when in the valid linking state.
3.8

cyclic transmission

A cyclic transmission system that a node transmits data stored in the common memory area,
which is specified every time a token is obtained, to all the nodes by broadcast. For details,
refer to 9.3.2.
3.9

message transmission

An aperiodic transmission system for notification of e vents generated between nodes. For
details, refer to 9.3.3.
3.10 cyclic frame
A frame used when performing cyclic transmission.
3.11 token frame
A frame to send and receive a token between nodes.
3.12 message frame
A frame used when performing message transmission.
3.13 trigger frame
A frame that a node in the network startup state sends notification that the timer for waitingtime for the transmission of the participation request frames in each node gets started.
3.14 participation request frame
A frame for a node to notify its existence when the node participates the network.
3.15 ACK(message acknowledge)
Information used for confirmation of receipt of message frames.
3.16 version of sequence number
The static number that is used to determine whether the message data frame has previously
received or not. The version of sequence number is created when a node participates in the
FL-net, and the value is maintained until the node leaves the network.
3.17 sequence number
The sequential number that is used to determine whether the message data frame has
previously received or not. The sequence number is initialized when starting, and isincremented every time a message transmission is completed.
3.18 TCD：transaction code
A Code to identify each frame defined in this network. The transaction codes include theJEM1479：2012–4–numbers reserved by the FA link protocol and the numbers which users can freely define. For
details, refer to 8.2.
3.19 node
Data stations used in this network.
3.20 node number
The number to identify nodes linked to this network. The numbers from 1 to 254 can be
specified. In the FA link protocol, these numbers are used as information for destination
addresses and source addresses in FA link headers.
3.21 common memory
Virtual memory for cyclic transmission defined in this network. There are two types: area 1
and area 2; each of which has the size of 512 words and 8,192 words, respectively. For
details, refer to 7.1.
3.22 word
The unit for the amount of data. One word means two octets.
3.23 virtual address space
A memory space which can be accessed in message transmission.
3.24 token mode
Mode to indicates whether independent token frames are supported.
3.25 major version
The version of the FA link protocol is expressed as a major version in the range of four bits
using integral values without the digits after the decimal point. When this version number is0(null), it is regarded as 1.
Example: The major version of Ver. 3.01 is 3.
3.26 minor version
The version of the FA link protocol is expressed as a minor version in the range of four bits
using the digits after the decimal point.
Example 1: The minor version of Ver. 2.01 is 01.
Example 2: The minor version of Ver. 2.10 is 10.
3.27 double word
A unit for the amount of data. One double word means four octets.
3.28 final cyclic frame
A cyclic frame transmitted just before a token frame.
3.29 server function
A function to receive request messages and to send response messages in message
transmission.
3.30 client function
A function to transmit request messages and to receive response messages in message
transmission.
3.31 protocol type
Information for distinguishing from similar industrial Ethernet protocols.

–5–

JEM1479：2012

3.32 device level network function
A function between a master node and slave nodes(devices) to exchange IO data that is
assigned in the common memory.
3.33 master node
A node to receive data generated by slave nodes or deliver data to be processed to slaves inthe device level network configuration, and to function as a controller in the system. It issometimes written simply as a master.
3.34 slave node
A node, in the device level network configuration, which receives data distributed by themaster node, or transmits data to be collected by the master, and which functions a s a device(terminal) in the system. It is sometimes written simply as a slave.
3.35 input data
Data assigned in the common memory that sent from slave nodes to a master node.
3.36 output data
Data assigned in the common memory that sent from a master node to slave nodes.
3.37 setting tool
A tool for setting node information, IO allocation, etc.
3.38 solicitation frame
Setting frame from a master to a slave in the device level network function.
3.39 UDP/IP, TCP/IP superimpose function
A function to mix general Ethernet(UDP, TCP, etc.) transmission with the FL-net network.
3.40 load measure function
A function to measure the network load of a node.
3.41 general purpose communication
General purpose Ethernet communication (such as UDP, TCP, etc.) which are not prescribedin the FA link protocol.
3.42 IO define
A definition of IO allocation of the common memory by a master node to slave nodes.
3.43 multi masterA function to constitute a FL-net network with multiple configuration that consist of a masternode and a number of slaves(it does not mean multiple master nodes can be assigned to one
slave node).
3.44 alternate transmission order
The transmission order for transmitting either a message frame or a solicitation frame whenholding a token.

–6–

JEM1479：2012
4
4.1

Notation and Abbreviation
Notation

The following notation shall be used.
a)b)

Decimal shall be used unless specifically notified in this document. Hexadecimal iswritten in any one of 2-digit, 4-digit, or 8-digit notation. 8-digit hexadecimal notation isseparated with “_” (underscore) for every 4 digits.
Example 1: Decimal

12

0

4782

65 546

Example 2: Hexadecimal

16#FF

16#00

16#12AE

16#0001_000A

The # symbol is added in front of the number of node numbers used in this document.
Example: Node number 1c)Node #1

The version of the protocol specification prescribed in th is document is expressed as
Ver.*.*. The asterisk (*) symbol indicates any decimal value from 0 to 15. The integral
value without the digits after the decimal point is a major version, and the digits after thedecimal point shall be a minor version.
Only a major version is used about the general term of a protocol (Ver.2 protocol etc.).

4.2

Abbreviation

The abbreviated terms used in this document shall be shown in Table 1.

–7–

JEM1479：2012

Table 1 - List of abbreviations and terms
Abbreviations

Terms

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_AD2

common memory area 2 data top address

C_SZ1

common memory area 1 data size

C_SZ2

common memory area 2 data sizeDA

destination address

DNA

Node number of destination side

H_TYPE

header type

LKS

FA link status

MFT

allowable minimum frame interval timeMODE

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

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 ACKSAsource address

SDU

service data unit

–8–

JEM1479：2012

Table 1 - List of abbreviations and terms (Continued)
Abbreviations
SEQ
SNA
TBN
TCD
TDT
TFL
TM
TW
TrWT
ULS
VDN
VER
V_SEQ
SFBTFI
SFTWT
Ver.2.00
Ver.3.01

Terms
sequence number
Node number of source side
total fragment block number
transaction codejoining token detection time
total frame octet length of header and data
token mode
token watchdog time
trigger frame transmission waiting time
upper layer statusvender code of node information
program version
version of sequence number
solicitation frame batch transmission frameinterval
solicitation frame transmission waiting time
FL-net Version2.00
FL-net Version3.01

–9–
5

JEM1479：2012

Product Categories

Table 2 shows functions that are required when developing FL -net products. For functions
using IO, refer to the category of the slave and the master. In case of superimposing UDP,
TCP protocols, FL-net Ver.3.00 nodes are recommended to implement token retention ti memeasurement and a sender log function (to be used for investigation when a node showsabnormal behavior by superimposing).

Table 2 - Summary list of functions by product category
Product
category

Implementation Function category
class
Node types

Node before Class 1
FL-net Ver.
2.00

Basic function

FL-net message
transmissionfunction

Device level network function

Command server for setting tool

Token
CyclicRequired Optional IO data
Flexible
Solicitation Read Node
Load
IO
Othersparticipation transmission message message exchange
slave
response node setting measurement allocation
response function
solicitation
state
transmission

Ver. 2.00 standard
nodes, such as
PLCs, personal
computers

R

R

R

O

N

N

N

N

N

N

N

N

Class 2

Ver. 2.00 nodes(Setting tool)

R

P

R

O

N

N

N

N

N

N

N

N

FL-net Ver. Class 3
3.00 masternode

Controllers andflexible master,such as PLCs,
personalcomputers

R

R

R

O

O

O

N

R

R

R

O

O

Class 4

Flexible master,such as PLCs,
personalcomputers

R

N

R

O

R

R

N

R

R

O

R

O

Class 5A fixed master,such as PLCs,
personalcomputers

R

N

R

O

R

N

N

P

O

O

N

O

Class 6

Flexible slave
input/output
devices

R

N

R

O

R

N

R

P

R

O

N

O

Class 7

Fixed slave
input/output
devices

R

N

R

O

R

N

N

P

O

O

N

O

FL-net Ver.
3.00 slavenode

R: Required P: Partially required O: Optional N: Not necessary
Note: Refer to Table 3 for the list of functions included in the product categories.

– 10 –JEM1479：2012

Table 3 - Detailed list of functions by product category
Function

Type 1

Type 2

Commonfunction

Token participation

CyclicClientFL-netmessage

ServerServerClientRead/Writemessage

Operationcommandmessage
Vendorspecific
Read/Writemessage

Operationcommandmessage
Vendorspecific

Command
Token frame
Participation request frame
Trigger frame
Cyclic frame

TCD
65 00065 00265 01265 001

Network parameter read frame (response)

65 207

Profile read frame (response)

65 211

Message return frame (response)

65 215

Log data read frame (response)

65 213Log data clear frame (response)

65 214

1
a)
R

2
a)
R

3
a)
R

b)

R

c)

R

R

b)

R
a)
R

d)

R

R

Class No.
4
5
a)
a)
R
R

6
a)
R

7
a)
R

b)

N

N

N

N

b))

b)

O
a)
R

R
a)
R

N
a)
R

N
a)
R

N
a)
R

N
a)
R

d)

R

d)

R

d)

R

d)

R

d)

R

e)

e)

e)

e)

e)

e)

d)
e)

Transparent message frame

10 000～59 999

O

O

O

O

O

O

O

Byte block read frame (response)

65 203

Oa)

Oa)

Oa)

Oa)

Oa)

Oa)

Oa)

Byte block write frame (response)

65 204

Word block read frame (response)

65 205

Word block write frame (response)

65 206

Network parameter write frame (response)

65 208Stop command frame (response)
Operation command frame (response)

65 20965 210Vendor specific message frame (response)

65 216

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

Transparent message frame

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

Log data clear frame (request)

10 000～59 99965 014

Byte block read frame (request)

65 003

Oa)

Oa)

Oa)

Oa)

Oa)

Oa)

Oa)

Byte block write frame (request)

65 004

Word block read frame (request)

65 005

Word block write frame (request)

65 006

Network parameter read frame (request)

65 007

Network parameter write frame (request)

65 008

Profile read frame (request)

65 011

Log data read frame (request)

65 013Message return frame (request)

65 015

Stop command frame (request)

65 009Operation command frame (request)

65 010Vendor specific message frame (request)

65 016

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

Oe)

– 11 –JEM1479：2012

Table 3 - Detailed list of functions by product category (continued)
Function
Devicelevel
networkCommandserverType 1

Type 2

Command

TCD

Transmission

Cyclic frame

65 001

ClientReception
Solicitation

Solicitation frame

65 017

N

N

Ob)

Rb))

ServerSolicitation

Solicitation frame

65 017N

N

N

N

Server(UDP)

Read/Writemessage

Byte block read frame (response)

65 203N

N

O

Byte block write frame (response)

65 204

Word block read frame (response)

65 205

Word block write frame (response)

65 206

Network parameter read frame (response)

65 207

Network parameter write frame (response)

65 208

Profile read frame (response)

65 211

Log data read frame (response)

65 213Log data clear frame (response)

65 214

Message return frame (response)

65 215

Stop command frame (response)
Operation command frame (response)

65 20965 210N

N

IO allocation setting frame (response)

65 218N

IO allocation read frame (response)

65 219Load
Start frame of token retention time measurement
measurement (response)
End frame of token retention time measurement(response)
Start frame of measurement in general purpose
communication data sender log (response)
End frame of measurement in general purpose
communication data sender log (response)
Node setting Configuration parameter setting frame (response)

65 220

Read node
statusDataexchange

Operationcommandmessage
IO allocation

Read frame of participating node management
information parameter (response)
Read frame of self node management information
parameter (response)(Read node information)
Read frame of self node configuration information
parameter (response)

Reset(Read node information in the memory in the node)
Node reset frame (response)

2
N

3
Ob)

Class No.
4
5
Rb)
Rb)

1
N

6
Rb)

7
Rb)

N

N

N

N

Rb)

N

O

O

O

O

O

O

O

O

O

N

O

R

N

N

N

N

N

R

O

O

O

O

65 224

N

N

R

R

O

R

O

65 225

N

N

R

R

R

N

N

65 226

N

N

R

R

R

R

R

65 227

N

N

R

R

O

R

O

65 228

N

N

O

O

O

R

R

65 22165 22265 223

– 12 –JEM1479：2012

Table 3 - Detailed list of functions by product category (continued)
Function

Type 1

Command Server
server(TCP)(Continued)

Type 2
Read/Writemessage

Command

TCD

Byte block read frame (response)

65 203

Byte block write frame (response)

65 204

Word block read frame (response)

65 205

Word block write frame (response)

65 206

Network parameter read frame (response)

65 207

Network parameter write frame (response)

65 208

Profile read frame (response)

65 211

Log data read frame (response)

65 213Log data clear frame (response)

65 214

Message return frame (response)

65 215

Operationcommandmessage

Stop command frame (response)

65 209Operation command frame (response)

65 210

IO allocation

IO allocation setting frame (response)

65 218

1
N

2
N

3
O

Class No.
4
5
O
O

6
O

7
O

N

N

O

O

O

O

O

N

N

O

O

O

O

O

N

N

O

O

N

N

N

N

N

O

O

O

O

O

IO allocation read frame (response)

65 219Load
Start frame of token retention time measurement
measurement (response)
End frame of token retention time measurement(response)
Start frame of measurement in general purpose
communication data sender log (response)
End frame of measurement in general purpose
communication data sender log (response)
Node setting Configuration parameter setting frame (response)

65 22065 224

N

N

O

O

O

O

O

Read nodestate

65 225

N

N

O

O

O

N

N

65 226

N

N

O

O

O

O

O

N

N

O

O

O

O

O

Read frame of participating node management
information parameter (response)
Read frame of self node management information
parameter (response)(Read node information)
Read frame of self node configuration information
parameter (response)

65 22165 22265 22365 227(Read node information in the memory in the node)
Reset
Node reset frame (response)
R: Required O: Optional (included as an authentication item when implemented)
Only 1 to 1 communication supported unless otherwise specified.
Note: The implementation of command server functions in TCP shall be optional.
Notea) Only 1 to 1b)
Support only 1 to n communicationc)Required, but the data size is 0d)
Support both 1 to 1 communication and 1 to n communicatione)
Optionally support 1 to 1 communication and 1 to n communication

6

65 228
N: Not necessary

Basic Specifications

6.1

Relation between OSI Reference Model and FL-net

The relation between the OSI reference model and the FL-net protocol specification shall beshown in Figure 2. The presentation layer and the session layer prescribed in the OSI
reference model shall not be used in this document according to the attribute of the control
system within the scope. This document defines the transport layer, the network layer, and thedata link layer as the FA link lower layer. Any function other than a broadcast communication
function shall not be prescribed for the FA link lower layer.
6.1.1

JIS X 5252 is used for the physical layer.

The FA link layer is defined as the upper layer of these specifications. The FA link prescribes
the cyclic transmission for collecting and distributing data of each node at a fixed interval andthe message transmission for event notification in addition to the network management
function. The upper layer of the FA link is the upper application. The upper layer described inthis document indicates the upper application.

– 13 –(OSI basic reference model)

Application

Layer 7

Application layer

Layer 6

Presentation layer

Layer 5

Session layer

Layer 4

Transport layer

Layer 3

Network layer

Layer 2

Data link layer

Layer 1

Physical layer

JEM1479：2012(FL-net protocol specification)

Upper application

FA link layer

FA link lower layer

JIS X 5252

Figure 2 – Relation between OSI reference model and FL -net protocol specification

6.2

The number of nodes to be connected

The number of nodes which can be connected to the network shall be 254 nodes at the
maximum.
6.3

UDP and TCP superimposition

FL-net Ver.3.00 is allowed to coexist with UDP and TCP communication that are used by
setting tools, monitoring and information systems, an Internet connectivity, OA equipment, etc.
on the FL-net network.
The UDP and TCP communication can be overlaid with or without the token of general OA
equipment or each node. However, UDP and TCP superimposition increases the network load.
Since the FA link protocol does not implement a function to adjust the load of overlaid UDP
and TCP communication, a load measure function has been added to allow the user toconsider the network load.
Using the load measure function, the user who uses the UDP/IP, TCP/IP superimpose
function in the FL-net system can adjust the parameters for the FL-net communication
performance after understanding of the influence on the real -time performances (cyclic
transmission etc.) required by the system.
An example of the system configuration for the overlaid UDP and TCP shall be shown in
Figure 3.

– 14 –JEM1479：2012

Internet

Personalcomputer formonitoring

General purpose
personalcomputer(setting tool)

FL-netPrinter (OAequipment)

FL-net nodes(PLC etc.)

FL-net nodes(PLC etc.)

FL-net nodes(PLC etc.)

Figure 3 – Example of the system configuration for the overlaid UDP and T CP

In addition, the overlaid UDP and TCP communication enables access to FL -net Ver. 3.00
nodes from general purpose personal computers outside of the segment via standard routers.
An example of access between different segments via a router installed on the network shallbe shown in Figure 4.

– 15 –

FL-net Ver. 3.00 node 1

JEM1479：2012

FL-net Ver. 3.00 node 2

IP: 192.168.250.XXX network

HUB

Segment 1

Router
The segment 1 side: 192.168.250.254
The segment 2 side: 192.168.200.254

General purpose
setting tool of
personal computer

HUB

Segment 2
IP: 192.168.200.XXX network

Common functions, cyclic function, message function, device
level network function

General purpose command server
function

Figure 4 - Example of access from different segment (connect ed via a router)

Examples of IP address setting shall be shown in Table 4.

Table 4 - Examples of IP address setting
DeviceFL-net Ver. 3.00 node 1
FL-net Ver. 3.00 node 2
General purpose setting tool of personal
computerRouterSegment 1
Segment 2

6.4

IP address

Gateway address

192.168.250.1
192.168.250.2

Subnet mask
address255.255.255.0
255.255.255.0

192.168.200.100
192.168.250.254
192.168.200.254

255.255.255.0
255.255.255.0
255.255.255.0

192.168.200.254
──

192.168.250.254
192.168.250.254

Load Measure Function

The load measure function is a function in FL-net Ver. 3.00 to record the log of the network
load for each node in order to consider the load on the network due to the overlaid UDP and
TCP.

JEM1479：2012– 16 –The load measure function includes two processing: token retention time measurement
processing and general purpose communication data sender log processing.
a)

Token retention time measurement processing

Measures the minimum and maximum values of the time for which a node holds a token, andthe elapsed time until the maximum value is measured from the start of measurement, andsaves those values in a logging area. In addition, followed information are saved in the log asfactor to have influence on the token retention time(For details, refer to 8.4.4.1); the latest
time of token cancellation, the latest time of token reissuing, the latest time of token retention
timeout, the latest time of token monitoring timeout, number of tokens while measuring thetoken retention time, detection time for the maximum refresh cycle, detection time for error inreceiving cyclic frame, and detection time for error in receiving message frame.
b)

General purpose communication data sender log processing

Measures the number of reception for the first ten frames per sender IP when the node
receives a general purpose communication frame. (For details, refer to 8.4.4.2).
6.5

General purpose Command Server Function

The setting tool for FL-net Ver. 3.00 can configure and read various parameters.
The command server processes requests that received with Ethernet TCP or UDP protocol
and returns response.
The request from a setting tool is received by TCP or an UDP protocol from a network, is
processed according to the request TCD by application, a general purpose command server,
or FL-net protocol processing, and transmits a response from the same course as the time ofreception.
When a response data sending request is received from a message sending process and asystem message process, it is transmitted via the received path.
Nodes without functions for each command of the command server functions are required tosend the unimplemented response of M_RLT (= 2) within one second, or send no response(For M_RLT, refer to Part 9.4.6).
The outline of the general purpose command server interface sh all be shown in Figure 5.

– 17 –JEM1479：2012

Application

FL-net protocol process

General purpose
command server

TCP

UDP

IP
Ethernet

TCP

UDP

FL-net protocol
Network

Note: Refer to Chapter 5 for implementation level details of the general purpose
command server functions.
Figure 5 - Outline of general purpose command server interface

6.6

Device level network function

FL-net Ver. 3.00 can perform device-level I/O data exchange between I/O devices directly
connected to the FL-net network by the master/slave method using the common memory.
An example of configuration of the device level network s ystem shall be shown in Figure 6.

JEM1479：2012– 18 –

Figure 6 - Example of configuration of the device level network system

The device level network function is achieved by prescribing the memory map of the common
memory shared by each node using the conventional cyclic frames.
There are two setting modes of IO data exchange: a fixed setting mode with fixed common
memory allocation for simple user settings and an optional setting mode that allows the user
to freely define common memory allocation for flexible system configuration.
6.6.1

Setting Mode

The setting mode shall be as follows.
a)Fixed setting mode

Fixed setting mode Is basically designed to operate with the minimum settin gs.
The node numbers of default behavior are configured as 100 for the master and in the range
from 1 to 64 for slaves. This determines unique addresses of the common memory (Fordetails, refer to 8.6).
The slaves can identify the existence of the master with the master node number 100, and themaster and slaves input and output via the common memory corresponding to the node
number. When slave nodes have a master node number setting function, the system
configuration which can set up a master node arbitrar ily and has two or more master nodes in
one system is possible. Also in this case, the common memory of the slaves is fixed with thenode numbers and two or more masters cannot output to the same slave.
The size of input and output is fixed to 4 words for inputs and 4 words for output, but the IO
area is extensible to 4 or more words by the settings of the number of IOs of the slaves andthe slave type in the master status areas from the master.
The common memory allocation in the fixed setting mode shall b e shown in Figure 7.

– 19 –
Common memoryarea 1
16#0000 IO data
16#00FF
16#0100 Master data

JEM1479：2012

Common (transmission) memory ofslaves #1 to #64
Common (transmission) memory of themaster

16#01FF・ At the maximum configuration, the whole 512-words of area 1 are allocated.
・ The unused area with no slave allocated can be used as the shared memory.
Common memory area 2
16#0000 Status data

16#03FF
16#0400 Master status data

16#07FF
16#0800 Shared memory

Common (transmission) memory ofslaves #1 to #64

Common (transmission) memory of themaster

Unused area

16#1FFF・ At the maximum configuration, the 2000 words of the 8000-word of the area 2 are allocated.
・ The unused area with no slave allocated can be used as the shared memory.

Figure 7 - Common memory allocation in the fixed setting modeb)

Flexible setting mode

Allows the user to arbitrarily set the node numbers of the master and the slaves and thecommon memory allocation. However, the common memory area assigned to one node shallbe a continuous area. Although the configuration with two or more masters (multi -master) is
possible, two or more masters cannot output to the same slave.
When the user configures a master for the setting of each slaves, the master distributes
configuration information to each slaves using the solicitation frames.
The common memory allocation in the flexible setting mode shall be shown in Figure 8.
Common memory area 1
16#0000 Optional
16#01FF

Common memory area 2
16#0000 Optional

16#1FFF・ The unused area with no slave allocated can be used as the shared memory.

Figure 8 - Common memory allocation in the flexible setting mode

– 20 –JEM1479：2012
6.6.2

Solicitation frame

The solicitation frames is for defining common memory allocation of each slave station in theflexible setting mode, and are transmitted from the master to corresponding slaves.
The slave node number, fixed settings and flexible settings identification flags, IO data areas,and status areas are set in the data part of the solicitation frame. (For details, refer to 10 .4.1).
The data part of the solicitation frame shall be shown in Figure 9.

Data part of solicitation a frame
16#00 MSB: Setting mode (1 = flexible
setting)
Slave node number
16#02 MSB: Area specification
Input data address
16#04 Input data size
16#06 MSB: Area specification
Output data address
16#08 Output data size
16#0a MSB: Area specification
Input status address
16#0c MSB: Area specification
Output status address
16#0e Lock ID
16#10
・
・
・

Figure 9 - Data part of the solicitation frame

The data size of a solicitation frame is 8 words(16 octets) per node.
One transmission shall be up to 64 nodes (1024 octets) according to the defined transmission
frame size.
When the transmission exceeds 64 nodes, the solicitation fram e is transmitted in multiple
times (up to four times).
7

ServiceThis chapter prescribes services provided and required by the FL -net. The services prescribedhere shall be as follows.
a)Services to the upper layer

The services to the upper layer shall be as f ollows.
1)

Read and write to the common memory data

2)

Message―

Byte block read service―

Byte block write service

– 21 –―

Word block read service―

Word block write service―

Network parameter read service―

Network parameter write service―

Stop command service―

Operation command service―

Profile read service―

Transparent message service―

Log data read service―

Log data clear service―

Message return service―

Vendor specific message service

3)

Network management―

Configuration parameter setting―

Read self node management information parameter―

Read participating node management information parameter―

Read network management information parameter―

Read message sequence number management information―

Read node status

4)

Device level network―

Load measurement―

IO allocationb)Services to the lower layer

JEM1479：2012

The service to the lower layers shall be as follows.
―

SAP for transmission―

SAP for cyclic transmission―

SAP for message transmission and reception―

SAP for receiving participation requests―

Transmission of solicitation frames

7.1

Common Memory

7.1.1

Outline

The common memory provides a function which can be treated as a common global memory
among nodes which perform cyclic transmission. This service shall be optionally implemented.
The common memory has two types of areas including the area 1 and the area 2; the area 1

– 22 –JEM1479：2012

has the data capacity of 512 words, and the area 2 has the data capacity of 8,192 words. The
capacity for the common memory prepared by the communication part of one node shall be
the fixed size of 512 words + 8,192 words = 8,704 words. However, the nodes wh ich do not
implement this service need not prepare a common memory.
Any sizes can be specified within the maximum space of the area 1 and the area 2 as thetransmission area of one node in the area of the common memory.
7.1.2

Common Memory Allocation

The node can allocate transmission areas to each of the area 1 and the area 2 of the common
memory. The transmission area of each node shall not overlap with the transmission area ofother nodes.
Each node can set any sizes by word as the transmission area of the nod e within the range
from 0 to 512 words for the area 1 and from 0 to 8,192 words for the area 2. The transmission
area of each node is set with the start address and the size of the area.
An example of the common memory allocation shall be shown in Figure 1 0.
Area 1MSB

Area 2MSB

LSB

16#000Start address

16#0000

LSB

Start
address
Size

Size

16#1FF
16#1FFF

Note: The bit length shall be 16 bits.

Figure 10 - Example of the common memory allocation

7.1.3

Data Sharing Function

Each node provides a function to share the same data across the system by broadcasting thedata of the transmission area of the node allocated in the common memory at a constantfrequency. Each node on the network avoids overlapping the transmission area of each node
when allocating and using the common memory.
In operation of the common memory, the area in the common memory allocated to a certain
node is used as a transmission area of the node, and is used as a receiving area for othernodes (refer to Figure 11). In addition, a node may use the common memory only as areceiving area (example: node #01 in Figure 12).
The nodes which have not implemented the common memory discard all the received data
(example: node #01 in Figure 13).

– 23 –
Commonmemory ofnode #01

JEM1479：2012

Commonmemory ofnode #02

Commonmemory ofnode #03

Commonmemory ofnode #04

・

・

・

・

・

・

・

・

・

・

・

・

・

・

・

・

Figure 11 - Example of data sharing function

Commonmemory ofnode #01

Commonmemory ofnode #02

Commonmemory ofnode #05(Receive)(Receive)(Transmit)(Receive)(Transmit)(Receive)

Figure 12 - Example of a node which only performs receiving operation

Commonmemory ofnode #01

Commonmemory ofnode #02

Commonmemory ofnode #05(Discard)(Receive)(Transmit)(Discard)(Transmit)(Receive)

Figure 13 - Example of a node without a common memory

7.1.4

Data transmission

Data transmission shall be as follows.
a)

Write request to the common memory

The upper layer sets data in the common memory by performing a write request to theapplicable area in the common memory. The parameter of the write request shall be as
follows.
―

The address of the common memory

JEM1479：2012―

Data size

―

Data

b)

Request to send

– 24 –The upper layer requests to transmission data in the transmission area in the common
memory to the FA link layer.
The FA link layer which received the request to send transfers the data of the node allocatedin the common memory to the transmission buffer, prepares for transmission, and transmits insequence when the node obtains a token. When the data size from the transmission node islarger than the size which can be transmitted in one frame (1024 octets), the da ta in the buffer
is divided into two or more frames for transmission. Each node transmits all the transmission
data in the common memory each time it obtains a token. An example of the data flow in thecommon memory shall be shown in Figure 14.
7.1.5

Data reception

Data reception shall be performed as follows.
a)

Read request to the common memory

The upper layer reads the data in the common memory by performing read request to theapplicable area in the common memory. The parameters of the read request shall be as
follows.
―

Common memory address―

Data sizeb)Request to receive

The upper layer requires the FA link layer to transfer received data to the applicable area inthe common memory
Each node transfers the data to the applicable area in the common memory when a cycl ic
frame is received. At this time, the receiving node updates the corresponding area while
synchronizing with the upper layer when it finished receiving all the cyclic data from one node.
In other words, even when cyclic data is divided into several frame s for transmission, datatransfer to the common memory area is performed when all the frames transmitted from one
node is received. When any one of all the frames divided for transmission from the node is
missing, all the data transmitted from the node are discarded. An example of the data flow inthe common memory shall be shown in Figure 14.

– 25 –

Upper layer

Transmission node
FA link layer

Lower layer

Lower layer

JEM1479：2012
Receiving node
FA link layer

Write request to
the common
memorya)Upper layer

CommonmemoryCommonmemoryTransmission areac)Transmission
bufferRequest to
send

Read request to
the common
memoryBatch transfer

Batch transfer

Receive
bufferd)f)

Receivingarea

Cyclic frame 1b)g)Request toreceivee)
Cyclic frame 2

Cyclic frame N

Divide into N
piecesa)

The upper layer of the transmission node writes data to the transmission area in the common memory withthe write request to the common memory.

b)

The upper layer of the transmission node sends a request to send to the FA link layer when all the data havebeen written in the transmission area.

c)

The FA link layer performs batch transfer of the data from the transmission area to the transmission bufferwhen the request to send is received from the upper layer.

d)

The FA link layer transmits data in the transmission buffer to other nodes by broadcast as cyclic frames
when its node received and is holding a token. At this time, if the amount of the transmission data is larger
than 1024 octets, the data in the buffer is divided into two or more frames for transmission. The FA link layerof the receiving node temporarily stores all the received cyclic frames in the receive buffer.

e)

The upper layer of the receiving node sends a request to receive to the FA link layer.

f)

The FA link layer of the receiving node performs batch transfer of the data in the receive buffer to an
applicable receiving area with the request to receive from the upper layer.

g)

The upper layer of the receiving node reads data from the receiving area in the common memory with a readrequest to the common memory.

Figure 14 - Example of data flow in the common memory

7.2
7.2.1

Message Transmission
OutlineMessage transmission is a function to exchange aperiodic data generated between nodes.
The maximum amount of message data that can be transmitted at one time is 1024 octets.
The message transmission function includes peer to peer transmission which specif ies adestination node and 1 to n broadcast for all nodes. The 1 to 1 message transmission
prescribes a function to confirm reception and a response message for checking whether or
not the destination has received the data in order to maintain the reliabil ity of delivery of
message data.
7.2.2

Type of Service

This document provides services from a) to n) as message transmission. Among the provided
services, the transparent message service, the log data clear service, and the vendor specificmessage service prescribe 1 to 1 and broadcast transmission, and others prescribe only peer
to peer transmission. Each of the message transmission service except for the tran sparent
message service defines requests and responses. The type of each message is defined withthe transaction codes. In addition, each message has two transaction codes: one for request
and one for response. However, the transaction codes for response and request for

– 26 –JEM1479：2012transparent messages are defined by users as necessary.
a)

Byte block read serviceb)

Byte block write servicec)

Word block read serviced)

Word block write servicee)

Network parameter read servicef)

Network parameter write serviceg)

Stop command serviceh)Operation command servicei)

Profile read servicej)Transparent message servicek)

Log data read servicel)

Log data clear servicem) Message return servicen)Vendor specific message service

7.2.3

Byte Block Read Service

The byte block read service shall be as follows.
a)Function

This service reads byte block data of a destination node from a source node. This service
uses the area defined in the virtual address space.
The virtual address space of the byte block shall be shown in Figure 15. The virtual address
space is a 32 bit address space, and each node defines its contents.
MSB

LSB

16#0000_00
00

Byte block
The data length ofan address shall be
8 bits.

16#FFFF_FF
FF

Figure 15 - Virtual address space of a byte block– 27 –b)

JEM1479：2012

ProtocolThe sequence of the byte block read service shall be shown in Figure 16.
Request nodeUpper layer
Byte block read(request)

Response node

FA link layer
a)

i)

b)
c)

d)
e)
f)

g)
h)

i)
j)

FA link layer

Upper layerc)

Byte block readd)(instruction)g)

Byte block read(response)f)

Byte block read(confirmation)

j)

ACK

h)

ACK

a)

Lower
layer

b)

Byte block read(confirmation)e)

Byte block read(confirmation)

Lower
layer

The upper layer of the request node sets the following parameters and sends a byte block read request to
the FA link layer.
― The number of the request destination node: DNA― The offset address of the byte block to be requested (address for the virtual address space): M_ADD― The size of the byte block to be requested (data size for the virtual address space): M_SZ
The FA link layer of the request node takes in a PDU (request) from the upper layer as an SDU and sends arequest to send to the lower layer.
The FA link layer of the response node requests the lower layer to transmit an ACK to the PDU (instruction)
received from the lower layer and provides the PDU (instruction) to the upper layer.
When the response process of the response node is completed before the response node obtains the token,
the following f), g), and h) may be performed in advance before transmitting the ACK for the request.
The upper layer of the response node takes in the PDU (instruction) as an SDU, and starts a process for therequest.
The upper layer of the request node checks whether or not the response node received the request with the
ACK received from the lower layer.
The upper layer of the response node sets the following parameters with the completion of the byte block
read process and responses to the FA link layer about the byte block read request.
― Source node number: DNA― The offset address of the byte block to respond (address for the virtual address space): M_ADD― The size of the byte block to respond (data size for the virtual address space): M_SZ
― The message result: M_RLT― Response data (byte block data which was read): data
The FA link layer of the response node takes in a PDU (response) from the upper layer as an SDU andsends a request to send to the lower layer.
The FA link layer of the request node requests the lower layer to transmit the ACK to the PDU (response)
received from the lower layer, and provides the PDU (confirmation) to the upper layer. The ACK does notcontain response data.
The upper layer of the request node takes in the PDU (confirmation) as an SDU and receives the response
data for the byte block read request.
The upper layer of the response node checks whether or not the request node received the response datafrom the ACK received from the lower layer.

Figure 16 - The sequence of the byte block read service

– 28 –JEM1479：2012
7.2.4

Byte Block Write Service

The byte block write service shall be as follows.
a)Function

This service writes byte block data from the source node to the destination node. This service
uses the area defined in the virtual address space. For the virtual address space, refe r to
7.2.3.
b)

ProtocolThe sequence of the byte block write service shall be shown in Figure 17.
Request nodeUpper layer

Response node

FA link layer

Byte block write(request)a)Byte block write(confirmation)

Lower
layer

Lower
layer

FA link layerb)c)Upper layer
Byte block write(instruction)d)Byte block write(response)f)

Byte block write(confirmation)

j)

ACK
e)

Byte block write(confirmation)
i)

g)

h)

ACK
a)

b)
c)

d)
e)
f)

g)
h)
i)
j)

The upper layer of the request node sets the following parameters and sends a byte block write request to the FA
link layer.
―
The number of the destination node: DNA―
The offset address of the byte block to be requested (address position for the virtual address space): M_ADD―
The size of the byte block to be requested (data size for the virtual address space): M_SZ―
Requested data (byte block data to be written): data
The FA link layer of the request node takes in a PDU (request) from the upper layer as an SDU and sends a request
to send to the lower layer.
The FA link layer of the response node requests the lower layer to transmit an ACK to the PDU (instruction) received
from the lower layer and provides the PDU (instruction) to the upper layer. At this time, the ACK does not contain
requested data.
The response process of the response node is completed before the response node obtains the token, the followingf), g), and h) may be performed in advance before transmitting the ACK for the request.
The upper layer of the response node takes in the PDU (instruction) as an SDU, and starts a process for the request.
The upper layer of the request node checks whether or not the response node received the request from the ACK
received from the lower layer.
The upper layer of the response node sets the following parameters with the completion of the byte block write
process and responses to the FA link layer about the byte block write request.
―
Source node number: DNA―
The offset address of the responded byte block (address position for the virtual address space): M_ADD―
The size of the responded byte block (data size for the virtual address space): M_SZ―
The message result: M_RLTThe FA link layer of the response node takes in the PDU (response) from the upper layer as an SDU and sends arequest to send to the lower layer.
The FA link layer of the request node request the lower layer to transmit an ACK to the PDU (response) received
from the lower layer and provides the PDU (confirmation) to the upper layer.
The upper layer of the request node takes in the PDU (confirmation) as an SDU, and receives a process completion
for the byte block write request.
The upper layer of the response node checks whether or not the request node received the process completion with
the ACK received from the lower layer.

Figure 17 - The sequence of byte block write service

– 29 –
7.2.5

JEM1479：2012

Word Block Read Service

The word block read service shall be as follows.
a)Function

This service reads word block data of a requested node from a requesting node. It uses areas
defined in virtual address space. Figure 18 shows the virtual address space for a word block.
Virtual address space is 32-bit address space, and its content is defined by each node.
MSB

LSB

16#0000_0000
Word block

The data length of one
address shall be 16 bits.
16#FFFF_FF
FF

Figure 18 - Virtual Address Space for a Word Block– 30 –JEM1479：2012b)

ProtocolThe sequence of the word block read service shall be shown in Figure 19.
Requesting nodeUpper layer

Answering node

FA link layer

Word block
read (request)

a)

b)
c)

d)
e)
f)

g)
h)

i)
j)

FA link layer

Upper layer
Word block
read (direction)d)

Word block
read (response)

f)

ACK

g)

h)

ACK

a)

Lower
layer

c)

b)

Word block read(acknowledgment) e)

Word block read(acknowledgment) i)

Lower
layer

Word block read(acknowledgment j))

The upper layer of the requesting node sets the following parameters and requests the FA link layer for aword block read.
― Node number of destination side: DNA― Offset address of the word block to request (address in virtual address space): M_ADD― Size of the word block to request (data size in virtual address space): M_SZ
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process for therequest.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of the word
block read and responds to the FA link layer for a word block read request.
― Node number of source side: DNA― Offset address of the word block to respond to (address in virtual address space): M_ADD― Size of the word block to respond to (data size in virtual address space): M_SZ
― Message result: M_RLT― Response data (read word block data): data
The FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the word block read request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the response data.

Figure 19 - Sequence of the Word Block Read Service

– 31 –
7.2.6

JEM1479：2012

Word Block Write Service

The word block write service shall be as follows:a)Function

This service writes word block data from a requesting node to a requested node. It uses areas
defined in virtual address space. For virtual address space, refer t o 7.2.5.
b)ProtocolThe sequence of the word block write service shall be shown in Figure 20.
Requesting nodeUpper layer

Answering node

FA link layer

Word block write(request)a)Word block write(acknowledgment)e)Word block write(acknowledgment) i)

b)

Lower
layer

Lower
layer

FA link layerc)Upper layer
Word block write(direction)d)

Word block write(response)

f)

ACK

h)

g)

Word block write(acknowledgment
)

a)

b)
c)

d)
e)
f)

g)
h)
i)
j)

j)

ACK
The upper layer of the requesting node sets the following parameters and requests the FA link layer for aword block write.
― Node number of destination side: DNA― Offset address of the word block to request (address position in virtual address space): M_ADD― Size of the word block to request (data size in virtual address space): M_SZ
― Request data (word block data to write): data
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer. In this case, ACK does notcontain response data.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process for therequest.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of the word
block write and responds to the FA link layer for a word block write request.
― Node number of source side: DNA― Offset address of the word block to which it responded (address position in virtual address space):
M_ADD― Size of the word block to which it responded (data size in virtual address space): M_SZ
― Message result: M_RLTThe FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives aprocess completion for the word block write request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the process completion.

Figure 20 - Sequence of the Word Block Write Service

– 32 –JEM1479：2012
7.2.7

Network Parameter Read Service

The network parameter read service shall be as follows:a)Function

This service reads network parameters of a requested node from a requesting node.
b)

ProtocolThe sequence of the network parameter read service shall be shown in Figure 21.
Requesting nodeUpper layer

Network parameterread (request)

Answering node

FA link layer

a)

i)

b)
c)

d)
e)
f)

FA link layer

Upper layer
Networkparameter
read (direction)d)Network parameterread (response)f)

Network parameterread(acknowledgment)

j)

ACK

g)

h)

ACK
a)

Lower
layer

c)

b)

Network parameterread (acknowledgment) e)

Network parameterread (acknowledgment)

Lower
layer

The upper layer of the requesting node sets the following parameters and requests the FA link layer for a
network parameter read.
― Node number of destination side: DNA
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process for therequest.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of the
network parameter read and responds to the FA link layer for a network parameter read request.
― Node number of source side: DNA― Message result: M_RLT― Response data (network parameter of the self node): data
― Node name of node information: Optionally set by the user.
― Vender code of node information: Set optionally by the vendor.
― Manufacturer model name of node information: Optionally set by the manufacturer.
― Area 1 data top address― Area 1 data size
― Area 2 data top address― Area 2 data size
― Token watchdog time
― Allowable minimum frame interval time
― FA link status― Protocol type
― Upper layer status― Allowable refresh cycle time setting value― Refresh cycle measurement (current value)― Refresh cycle measurement (maximum value)― Refresh cycle measurement (minimum value)

Figure 21 - Sequence of the Network Parameter Read Service

– 33 –JEM1479：2012g)

The FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer andrequests the lower layer for transmission.
h)
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
i)
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the network parameter read request.
j)
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the response data.

Figure 21 - Sequence of the Network Parameter Read Service (continued)

7.2.8

Network Parameter Write Service

The network parameter write service shall be as follows:a)Function

This service writes network parameters from a requesting node to a requested node.
b)

ProtocolThe sequence of the network parameter write service shall be shown in Figure 22.

– 34 –JEM1479：2012
Requesting nodeUpper layer
Network parameter
write (request)

Answering node

FA link layer

a)

b)
c)

d)
e)
f)

g)
h)
i)
j)

FA link layer

Upper layerc)Network parameter write(direction)d)g)

Network parameter write(response)f)

Network parameter write(acknowledgment)

j)

ACK
h)
ACK

a)

Lower
layer

b)

Network parameter write(acknowledgment)e)Network parameter write(acknowledgment)
i)

Lower
layer

The upper layer of the requesting node sets the following parameters and requests the FA link layer for a
network parameter write.
― Node number of destination side: DNA― Request data (network parameters to write): data
― Setting parameter flags:― 16#01: For writing only the data top address and data size of area 1 and area 2― 16#02: For writing only the node name of node information― 16#03: For writing the data top address, data size, and node name of node information ofarea 1 and area 2― Area 1 data top address― Area 1 data size
― Area 2 data top address― Area 2 data size
― Node name of node information: Optionally set by the user.
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer. In this case, ACK does
not contain response data.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process forthe request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of the
network parameter write and responds to the FA link layer for a network parameter write request.
― Node number of source side: DNA― Message result: M_RLTThe FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives aprocess completion for the network parameter write request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the process completion.

Figure 22 - Sequence of the Network Parameter Write Service

– 35 –

7.2.9

JEM1479：2012

Stop Command Service

The stop command service shall be as follows:a)Function

This service requests a requested node for the stop command from a requesting node.
b)

ProtocolThe sequence of the stop command service shall be shown in Figure 23.
Requesting nodeUpper layer

Answering node

FA link layer

Stop command(request)a)Stop command(acknowledgment)Stop command(acknowledgment
)

b)

b)
c)

d)
e)
f)

g)
h)
i)
j)

FA link layer

Upper layer
Stop command(direction)d)Stop command(response)f)Stop command(acknowledgment)

j)

ACK

h)

g)

ACK
a)

Lower
layer

c)

e)

i)

Lower
layer

The upper layer of the requesting node sets the following parameters and requests the FA link layer forthe stop command.
― Node number of destination side: DNA
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process forthe request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of thestop command and responds to the FA link layer for the stop command request.
― Node number of source side: DNA― Message result: M_RLTThe FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer
and requests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives aprocess completion for the stop command request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the process completion.

Figure 23 - Sequence of the Stop Command Service

– 36 –JEM1479：2012
7.2.10Operation Command Service

The operation command service shall be as follows:a)Function

This service requests a requested node for the operation command from a requesting node.
b)

ProtocolThe sequence of the operation command service shall be shown in Figure 24.
Requesting nodeUpper layer
Operation commanda)(request)

Answering node

FA link layer

b)
c)

d)
e)
f)

g)
h)
i)
j)

FA link layer

Upper layerc)Operation command(direction)d)g)Operation command(response)f)Operation command(acknowledgment)

j)

ACK

h)

ACK
a)

Lower
layer

b)

Operation command(acknowledgment) e)
Operation command(acknowledgment) i)

Lower
layer

The upper layer of the requesting node sets the following parameters and requests the FA link layer forthe operation command.
― Node number of destination side: DNA
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process forthe request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of theoperation command and responds to the FA link layer for the operation command request.
― Node number of source side: DNA― Message result: M_RLTThe FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer
and requests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives aprocess completion for the operation command request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the process completion.

Figure 24 - Sequence of the Operation Command Service

– 37 –
7.2.11JEM1479：2012

Profile Read Service

The profile read service shall be as follows:a)Function

This service reads the profile of a requested node from a requesting node.
b)

ProtocolThe sequence of the profile read service shall be shown in Figure 25.
Requesting nodeUpper layer
Profile read(request)

Answering node

FA link layera)b)Profile read(acknowledgment e))

Profile read(acknowledgment i)
)

b)
c)

d)
e)
f)

g)
h)

i)
j)

Lower
layer

FA link layerc)Upper layer
Profile read(direction)d)Profile read(response)f)Profile read(acknowledgmen
t)

j)

ACK

h)

g)

ACK
a)

Lower
layer

The upper layer of the requesting node sets the following parameters and requests the FA link layer forthe profile read.
― Node number of destination side: DNA
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process forthe request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The upper layer of the answering node sets the following parameters by completing the process of the
profile read and responds to the FA link layer for a profile read request.
― Node number of source side: DNA― Message result: M_RLT― Response data (read profiles): data
The content of the data is beyond this standard (Refer to JEM-TR 214 (device profile common
specifications)).
The FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer
and requests the lower layer for transmission.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the profile read request.
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the response data.

Figure 25 - Sequence of the Profile Read Service

– 38 –JEM1479：2012
7.2.12

Transparent message service

The transparent message service shall be as follows:a)Function

This service sends user-defined service from a requesting node to a requested node. It does
not define responses. It uses a user-defined transparent message for a response.
b)

ProtocolThe sequence of the transparent message shall be shown in Figure 26.
Requesting nodeUpper layer

FA link layer

Transmission message(request)

a)Transmission message(acknowledgment)e)b)Answering node
Lower
layer

Lower
layer

FA link layerc)Upper layer
Transmission message(direction)

d)

ACK

a)

The upper layer of the requesting node sets the following parameters and requests the FA link layer for thetransparent message.
― Transmission form: one-to-one transmission (PPT)/one-to-n transmission (BCT)― Node number of destination side: DNA― User data (optionally defined by the user): datab)
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
c)
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
d)
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process for therequest.
e)
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
Note For one-to-n transmission, there is no ACK [c)] or transparent message (acknowledgment) [e)].

Figure 26 - Sequence of the Transparent Message Service

– 39 –
7.2.13

JEM1479：2012

Log Data Read Service

The log data read service shall be as follows:a)Function

This service reads log data of a requested node from a requesting node.
b)

ProtocolThe sequence of the log data read service shall be shown in Figure 27.
Requesting nodeUpper layer

Answering node

FA link layer

Log data read(request)

a)

b)

c)

d)
e)

f)

g)
h)

Upper layer

ACK
Log data read(response)

g)

e)

f)

ACK

b)

FA link layer

c)
d)

a)

Lower
layer

Log data read(direction)

Log data read(acknowledgment)

Log data read(acknowledgmen
t)

Lower
layer

h)

The upper layer of the requesting node sets the following parameters and requests the FA link layer forthe log data read.
― Node number of destination side: DNA
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer captures the PDU (direction) received from the lower layer as an SDU and starts theprocess for the log data read request, requesting the lower layer to send ACK for the PDU (direction)
received from the lower layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses e) and f) before sending ACK for the request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The FA link layer of the answering node sets the following parameters by completing the process of thelog data read and responds to the lower layer for a log data read request.
― Node number of source side: DNA― Message result: M_RLT― Response data (read log data): data
For the content of the data, refer to Annex B.
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the log data read request.
The FA link layer of the answering node discards the ACK received from the lower layer.

Figure 27 - Sequence of the Log Data Read Service

– 40 –JEM1479：2012
7.2.14

Log Data Clear Service

The log data clear service shall be as follows:a)Function

This service clears log data of a requested node from a requesting node.
b)

ProtocolThe sequence of the log data clear service shall be shown in Figure 28.
Requesting nodeUpper layer

Answering node

FA link layer

Log data clear(request)

Lower
layer

Lower
layer

FA link layer

Upper layer

Log data clear(direction)a)b)

Log data clear(acknowledgment)c)d)

Log data clear(acknowledgment) g)

ACK
Log data
clear (response)

e)

f)

ACK

h)

a)

The upper layer of the requesting node sets the following parameters and requests the FA link layer forthe log data clear.
― Transmission form: one-to-one transmission (PPT)/one-to-n transmission (BCT)― Node number of destination side: DNAb)
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
c)
The FA link layer captures the PDU (request) received from the lower layer as an SDU and starts theprocess for the log data clear request, requesting the lower layer to send ACK for the PDU (direction)
received from the lower layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses e) and f) before sending ACK for the request.
d)
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
e)
The FA link layer of the answering node sets the following parameters by completing the process of thelog data clear and responds to the lower layer for a log data clear request.
― Node number of source side: DNA― Message result: M_RLTf)
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
g)
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the log data clear request.
h)
The FA link layer of the answering node discards the ACK received from the lower layer.
Note For one-to-n transmission, ACK [c)], d), and subsequent processes are not conducted.

Figure 28 - Sequence of the Log Data Clear Service

– 41 –
7.2.15

JEM1479：2012

Message Return Service

The message return service shall be as follows:a)Function

This service sends the received message data by return and conducts a message
transmission test.
b)

ProtocolThe sequence of the message return service shall be shown in Figure 29.
Requesting nodeUpper layer

Answering node

FA link layer

Message return(request)

a)

Lower
layer

Lower
layer

FA link layer

Upper layer

Message return(direction)b)c)Message return(acknowledgment)d)

ACK
Message return(response)

Message return(acknowledgment)

g)

f)

e)
ACK

a)

b)
c)

d)
e)

f)

g)
h)

h)

The upper layer of the requesting node sets the following parameters and requests the FA link layer for a
message return.
― Node number of destination side: DNA― Return data: data
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
The FA link layer captures the PDU (request) received from the lower layer as an SDU and starts theprocess for the message return request, requesting the lower layer to send ACK for the PDU (direction)
received from the lower layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses e) and f) before sending ACK for the request.
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
The FA link layer of the answering node sets the following parameters by completing the process of themessage return and responds to the lower layer for a message return request.
― Node number of source side: DNA― Message result: M_RLT― Response data (return data): data
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the message return request.
The FA link layer of the answering node discards the ACK received from the lower layer.

Figure 29 - Sequence of the Message Return Service

– 42 –JEM1479：2012
7.2.16

Vendor-specific Message Service

The vendor-specific message service shall be as follows:a)Function

This service requests a requested node for a vendor -specific message from a requesting node.
b)

ProtocolThe sequence of the vendor-specific message service shall be shown in Figure 30.
Requesting nodeUpper layer

Answering node

FA link layer

Lower
layer

Lower
layer

FA link layer

Vendor specific message(request)

a)

c)

b)

Upper layer
Vendor specific message(direction)d)Vendor specific message(acknowledgment)

e
)

ACK

Vendor specific message(acknowledgment)

i)

h)

ACK

g)

Vendor specificmessage (response)f)

Vendor specific message
j)(acknowledgment)a)

The upper layer of the requesting node sets the following parameters and requests the FA link layer for a
vendor-specific message.
― Transmission form: one-to-one transmission (PPT)/one-to-n transmission (BCT)― Node number of destination side: DNA― Vender code of node information: VDN― Sub code: SCODE― Message data: datab)
The FA link layer of the requesting node captures the PDU (request) as an SDU from the upper layer andrequests the lower layer for transmission.
c)
The FA link layer of the answering node requests the lower layer to transmit ACK for the PDU (direction)
received from the lower layer, and passes the PDU (direction) to the upper layer.
If the answering node finishes the answering process before it acquires the token, it may conduct theprocesses f), g), and h) before sending ACK for the request.
d)
The upper layer of the answering node captures the PDU (direction) as an SDU and starts a process forthe request.
e)
The upper layer of the requesting node verifies with the ACK received from the lower layer whether theanswering node received the request.
f)
The upper layer of the answering node sets the following parameters by completing the process of thevendor-specific message and responds to the FA link layer for a vendor-specific message request.
― Node number of source side: DNA― Message result: M_RLT― Vender code of node information: VDN― Sub code: SCODE― Message data: datag)
The FA link layer of the answering node captures the PDU (response) as an SDU from the upper layer
and requests the lower layer for transmission.
h)
The FA link layer of the requesting node requests the lower layer to transmit ACK for the PDU (response)
received from the lower layer, and passes the PDU (acknowledgment) to the upper layer. ACK does notcontain response data.
i)
The upper layer of the requesting node captures the PDU (acknowledgment) as an SDU and receives
response data for the vendor-specific message request.
j)
The upper layer of the answering node verifies with the ACK received from the lower layer whether therequesting node received the response data.
Note For one-to-n transmission, ACK [c)], e), and subsequent processes are not conducted.

Figure 30 - Sequence of the Vendor-specific Message Service

– 43 –
7.3

JEM1479：2012

Network Management Service

7.3.1

Setting Configuration Parameters

Configuration parameters are used to define the operations of the FA link. Set theconfiguration parameters as per the following:a)Node number

The upper layer sets the Node number for the FA link layer as the initial value. The range of
the Node number shall be 1 to 254. If the Node number is not set, the node will not participate
in the network. If the node detects an overlapping Node number when it is trying to participate
in the network, it will not send any frames. If the node is participating in the network, thisparameter shall not be changed.
b)Common memory area 1 and 2 data top address and data size

Can be set from the upper layer and the network. If the node is participating in the network,
this parameter shall not be changed.
If this parameter is not set from the upper layer, the FA link layer determines th at the node
has no transmission area and participates in the network. If the network parameter write
service and configuration parameter setting service are used from the network to set thisparameter, the node leaves the network after receiving the messag e and participates in the
network again in an in-ring startup state.
The ranges of common memory areas 1 and 2 data top address and data size are as per thefollowing. When these parameters are set, the FA link layer will set the common memory
setting completion flag to the FA link status.
1)

Common memory area 1 data top address (16#0000-16#01FF)

2)

Common memory area 1 data size (16#0000-16#0200)

3)

Common memory area 2 data top address (16#0000-16#1FFF)

4)

Common memory area 2 data size (16#0000-16#2000)c)

Node name of node information

Can be set from the upper layer and the network.
If the network parameter write service and configuration parameter setting service are usedfrom the network to set this parameter, the node leaves the network after receiving themessage and participates in the network again in an in-ring startup state. If only the nodename is changed, the node does not leave the network and continues the communication.
Set the node name by using up to 10 ASCII characters.
d)Token watchdog time

The time is a node-specific value and may be set to the node as the initial value from theupper layer. If this value is not set, the node will not participate in the network. If the node isparticipating in the network, this parameter shall not be changed.
Set the token watchdog time in the range of 1 to 255 in steps of 1 ms.
e)Allowable minimum frame interval time

The interval is a node-specific value and may be set to the node as the initial value from theupper layer. If this value is not set, the node will not part icipate in the network. If the node isparticipating in the network, this parameter shall not be changed.
Set the allowable minimum frame interval time in the range of 0 to 50 in steps of 100 s.
7.3.2

Reading the Local Node Management Information Parameters

The self node management information parameters provide data on the settings andJEM1479：2012– 44 –

operations of the self node set by the upper layer or the network parameter write service andthe configuration parameter setting service when starting the node.
The FA link layer uses the information of the self node management information parameters
as information of the participation request frame and network parameter read. A value withinparentheses indicates a data length.
a)Parameter

The parameters are as per the following:1)

Node number (1 octet): 1-254

2)

Common memory area 1 data top address (2 octets): Word address (16#0000 -16#01FF)

3)

Common memory area 1 data size (2 octets): Size (16#0000 -16#0200)

4)

Common memory area 2 data top address (2 octets): Word address (16#0000 -16#1FFF)

5)

Common memory area 2 data size (2 octets): Size (16#0000 -16#2000)

6)

Upper layer status (2 octets): Operating information, error information, etc. Refer to 7.3.6a) for details.

7)

Token watchdog time (1 octet): 1-255: by 1 ms

8)

Allowable minimum frame interval time (1 octet): 0-50: by 100 s

9)Vendor code of node information (10 octets): Name of the vendor

10) Manufacturer model name (10 octets): The Manufacturer model name of the node11) Node name of node information (10 octets): Name of the node set by the user
12) Protocol type (1 octet): 16#80 fixed13) FA link status (1 octet): Participation, leaving, etc. Refer to 7.3.6 b) for details.
14) Self node status (1 octet): Detecting overlapping Node numbers, etc. Refer to 7.3.6 c) for
details.
7.3.3

Reading the Participating Node Management Information Parameters

The participating node management information parameters provide the information of thecondition of each node participating in the network. The FA link layer manages the parameterdata for each node participating in the network.
a)

Parameter

The parameters are as per the following:1)

Node number (1 octet): 1-254

2)Upper layer status (2 octets): Operating information, error information, etc. Refer to 7.3.6a) for details.

3)

Common memory area 1 data top address (2 octets): Word addr ess (16#0000-16#01FF)

4)

Common memory area 1 data size (2 octets): Size (16#0000 -16#0200)

5)

Common memory area 2 data top address (2 octets): Word address (16#0000 -16#1FFF)

6)

Common memory area 2 data size (2 octets): Size (16#0000 -16#2000)

7)

Allowable refresh cycle time (2 octets): 0-65535: by 1 ms

8)

Token watchdog time (1 octet): 1-255: by 1 ms

– 45 –
9)

JEM1479：2012

Allowable minimum frame interval time (1 octet): 0-50: by 100 s10) FA link status (1 octet): Information of participation, leaving, etc. Refer to 7.3.6 b) for
details.
The information of parameters are contained in the frame received by each node, except the
information of participation/leaving and communication invalidity detection contained in "10)FA link status." Each node updates the participating node management informati on
parameters when it receives the final cyclic frame from a participation request frame or an
unrecognized node. However, "2) Upper layer status" and "7) Allowable refresh cycle time"
update the parameters whenever they receive the final cyclic frame.
A node changes the information of participation/leaving and communication invalidity
detection contained in the FA link status of the applicable node to the participation statuswhen it receives a participation request frame or token frame from each node. Whe n it
recognizes a leaving node by three continuous detections of the receive timeout of a token
frame from each node, it changes the inform ation of participation/leaving contained in the FA
link status of the applicable node to the leaving status.
7.3.4

Reading the Network Management Information Parameters

The network management information parameters provide information of the state common to
the network.
a)

Parameter

The parameters are as per the following:
1)

Token holding Node number (1 octet): The number of the node currently holding the token(1-254)

2)

Allowable minimum frame interval time (1 octet): 0-50: by 100 s

3)

Allowable refresh cycle time (2 octets): 0-65535: by 1 ms

4)

Refresh cycle measurement time (current value) (2 octets): 0 -65535: by 1 ms

5)

Refresh cycle measurement time (maximum value) (2 octets): 0-65535: by 1 ms

6)

Refresh cycle measurement time (minimum value) (2 octets): 0 -65535: by 1 ms

7.3.5

Reading the Message Sequence Number Management Information

The message sequence number management information provides i nformation of thesequence number and version of sequence number in a message transmission.
a)

For transmission

Prepare the following for the transmission table:
1)

Version of sequence number (4 octets): 16#0000_0001 -16#FFFF_FFFF

2)

Sequence number (one-to-n transmission) (4 octets): 16#0000_0001-16#FFFF_FFFF

3)

Sequence number
16#FFFF_FFFFb)

For receiving(one-to-one

transmission)(4octets)x

256:

16#0000_0001-

Prepare the following 254 (number of nodes) 12-octettables as a receiving table. If thesequence number is "0," it indicates that no message has been received yet.
1)

Version of sequence number (4 octets): 16#0000_0000 -16#FFFF_FFFF

2)

Sequence number (one-to-n transmission) (4 octets): 16#0000_0000-16#FFFF_FFFF

3)

Sequence number (one-to-one transmission) (4 octets): 16#0000_0000-16#FFFF_FFFF

– 46 –JEM1479：2012
7.3.6

Reading the Node Status

The node status has three types: upper layer status, FA link status, and self node status.
a)Upper layer status

The upper layer status consists of the operating information and error information of the upper
layer (Refer to Table 5.).
1)

Operating information of the upper layer

1.1) RUN
Indicates that the "upper layer program" is operating.
1.2) STOP
Indicates that the "upper layer program" is halted.
Note 1 An "upper layer program" is a program that has the upper layer of the FA link andinterfaces such as a controller (e.g. PLC).
Note 2 The definition of "operating" and "halted" shall be determined by the upper layer andbeyond this standard.
2)

Error information of the upper layer

2.1) NORMAL
Indicates that the upper layer is normal and the cyclic data and message data are valid.
2.2) WARNING
Indicates that an abnormal condition where operation can be continued is occurring in theupper layer but the cyclic data and message data are valid.
2.3) ALARM
Indicates that an abnormal condition where operation cannot be continued is occurring in theupper layer and the cyclic data and message data are not valid.
2.4) Error content of the upper layer
Indicates the error content of the "upper layer program."
Table 5 - Conditions of the Upper Layer
Error
Information
NORMALWARNINGALARMb)Operating Information
RUN
STOP
The "upper layer program" is operating and
The "upper layer program" is halted and thethe cyclic data and message data are valid.
cyclic data and message data are valid.
The "upper layer program" is operating and
The "upper layer program" is halted and has
has an anomaly, but the cyclic data andan anomaly, but the cyclic data and message
message data are valid.
data are valid.
The cyclic data and message data are not
The cyclic data and message data are notvalid.
valid.

FA link status

Of the FA link status information, the information of participation/leaving and communication
invalidity detection of each node is managed for each node. Other information is contained inframes in the network. For the configuration on the frame structure, refer to 10.1.1.
1)Address overlap detection flagIndicates that there is an overlap in the common memory area settings for the nodeconnected to the network.
2)

Common memory setting completion flagIndicates that the common memory settings for the node are complete.

– 47 –
3)

JEM1479：2012

Common memory data validity notice flagIndicates that the cyclic data is valid.
4)Upper layer actuating signal error flagIndicates that updates of survival signals in the upper layer cannot be recognized.
5)

Communication invalidity detection flagIndicates that frames with a different token mode exist in the network.
6)

Node participation/leaving flagIndicates whether the node is participating in the network or not.
c)

Self node status

Information of the self node to provide for the upper layer
1)

Node number overlap flagIndicates that a node with the same node number as the setting value for the self node exists
in the network.
2)

Token watchdog time error flagIndicates that a transmission process does not finish within the token watchdog time set tothe self node.
3)

Receiving waiting status flagIndicates a state of waiting for receiving a frame without receiving any frames in theinitialization of the network.
4)

Initialization error flagIndicates that there was an error in the initial settings or resetting parameters.
7.4

Load Measure Service

This service conducts the start and termination request of load measure for the Node Ver.
3.00 via UDP or TCP communication from the setting tool.
The measurement result is added as a data division to a response frame for the termination
request.
The measurement items include the token retention time and gener al purpose communication
data sender log.
Table 6 shows a list of the transaction codes used by the load measure service.
Note
An unimplemented node shall conduct an unimplemented response of M_RLT(message result in the FA link header) = 2 within one second or conduct no response.

– 48 –JEM1479：2012

Table 6 - Load Measure Service Transaction Code List
Name
Transaction CodeStart frame of token retention time measurement (request)
65 020
End frame of token retention time measurement (request)
65 021
Start frame of measurement in general purpose communication
65 022
data sender log (request)
End frame of measurement in general purpose communication
65 023
data sender log (request)
Start frame of token retention time measurement (response)
65 220
End frame of token retention time measurement (response)
65 221
Start frame of measurement in general purpose communication
65 222
data sender log (response)
End frame of measurement in general purpose communication
65 223
data sender log (response)
Note Use "55004" for the port number at the time of transmission and receiving.

7.5

IO Allocation Setting Service

7.5.1

Overview

There are two methods of IO allocation settings: downloading by directly connecting a vendor specific tool and downloading from the setting tool through UDP or TCP protocol
communication via the network. Figure 31 shows an example of settings via the network.
Table 7 shows a list of the transaction codes used by the IO allocation settings.
Note
An unimplemented node shall conduct an unimplemented response of M_RLT(message result in the FA link header) = 2 within one second or conduct no response.
PC setting tool
FL-net

#1

#2

#3

#4

#64

Flexible master node

Vendor-specific tool

Figure 31 - IO Allocation Setting Service

Table 7 - IO Allocation Setting Service Transaction Code List
Name
Transaction CodeIO allocation setting frame (request)
65 018
IO allocation setting frame (response)
65 218Note Use "55004" for the port number at the time of transmission and receiving.

7.5.2

IO allocation setting

IO allocation setting shall be as follows.
a)Fixed setting

Default with which no operation for IO allocation setting is required.

– 49 –b)

JEM1479：2012

Flexible setting

The user can define each master node with respect to the number of slaves (total number)
under the control of the master node, ID nos. of these slave nodes, IO data addr ess and size,and IO status address.
Flexible setting, shall be shown in Figure 32.
Setting tool
Flexible master node#50

Flexible master node#70

Control range

Slave node

#1

#2

#3

#1

Slave node ID (1W)

#3

#4

#64

Slave node ID

#101

#131

#150

Control range

#201

#249

Number of slaves (1W) = 4#101

Slave node ID (1W)

Input data address

Input data address

Input data size

Input data size

Output data address

Output data address

Output data size

Output data size

Input status address (1W)

Input status address

Input status address

Output status address (1W)

Output status address

Output status address

Reserve(1 W)

Reserve

Reserve

Input data address (1W)
Input data size (1W)
Output data address (1W)
Output data size (1W)

#2

Control range

Number of slaves (1W) = 3

Number of slaves (1W) = 2

Flexible master node

Information on slave #2 (8W)

#4Information on slave #4#150

Information on slave #150

#64

Information on slave #64#201

Information on slave #201

#249

Information on slave #249

#70

#50
Define slaves placed
under the control of Node#50

Define slaves placed
under the control of Node
#70

#131
Define slaves placed
under the control of Node#131

Figure - 32 IO Allocation by Flexible Setting mode

7.6

Service to lower layers

This service available on the interface between FA link layer and lower layers is to permit the
FA link layer and FA link entities on the same layer to exchange protocol data units.
The lower layers shall prepare four different SAPs available for the FA link layer: transmission,

JEM1479：2012– 50 –

receiving a cyclic data, receiving a message, and receiving a request for participation. The FA
link layer and lower layers execute request or command ing operations under each SAP to
exchange information.
7.6.1

Function of the “transmission” SAP

The “transmission” SAP provides the FA link layer a request for transmission.
a)Parameters

Uses the following parameters
1)

Address of the request receiver2)

SAP of the request receiver

3)

SDU

7.6.2

Function of the “receiving a cyclic data” SAP

The “receiving a cyclic data” SAP provides the FA link layer instructions for receiving cyclic
frames.
a)Parameters
Uses the following parameter

1)

SDU

7.6.3

Function of the “receiving a message” SAP

The “receiving a message” SAP provides the FA link layer instructions for receiving amessage.
a)Parameters

Uses the following Parameter
1)

SDU

7.6.4

Function of the “receiving a request for participation” SAP

The “receiving a request for participation” SAP provides the FA link layer instructions forreceiving a frame containing a request for participation.
a)Parameters

Uses the following parameter
1)

SDU

7.7
7.7.1

Solicitation frame transmission service
Overview

This service provided by the master is to give the slaves information on IO allocation settings.
Max. 1024 octets of data can be sent at a time. If a solicitation data exceeds 1024 octets (ifthe solicitation frames to be sent to the slaves exceed 64 nodes), the master shall divide theframes into groups and transmit them separ ately.
This solicitation frame transmission is a broadcast service over all slaves, which prevents themaster from checking acknowledgement from each slave. Therefore the application shallcheck such acknowledgement by checking whether the slave is partici pating in the network,and by referencing the master node ID contained in the status area of each slave.
For a multi-master system, it is necessary to check duplicated use of slaves by referencing
the master node ID contained in the status area of each sla ve.
Table 8 shows the list of solicitation frame transmission service transaction codes.

– 51 –JEM1479：2012

Table - 8 List of Solicitation Frame Transmission Service Transaction Codes
NameTransaction code
Solicitation frame
65 017
Note: The UDP port number shall be 55 003 for transmission and 55 002 for receiving
operation.

– 52 –JEM1479：2012
7.7.2

ProtocolThe solicitation frame transmission service sequence shall be shown in Figure 33
Request nodeUpper layer

Response node

FA link layer

IO definition

Transmission ofsolicitation framea)b)Multiple transmission ofsolicitation frame
d)

Lower
layer

Lower
layer

FA link layer

Upper layer

Solicitation frame(instruction)
c)

e)

a)

The upper layer at the request node side requests, per the IO definitions, the FA link layer to transmit asolicitation frame.
b)
The FA link layer at the request node side generates, per the IO definitions, a solicitation frame and requests
the lower layer to transmit the frame after the participation request frame acceptance times out (i.e. during
the network startup state), or during retention of the token (i.e. during the valid linking state).
c)
The FA link layer at the response node side executes the relevant processes in accordance with the IO
definitions intended for the node contained in the solicitation frames that the FA link layer have received fromthe lower layer.
d)
If the IO definitions exceed 64 nodes, the FA link layer at the request node side provides the lower layer arequest for transmitting the remaining solicitation frame after the solicitation frame batch transmission frameinterval (SFBTFI) is up (i.e. during the network startup state) or during retention of the token, and after thea)solicitation frame transmission waiting time (SFTWT) is up [i.e. during the valid linking state ].
e)
The FA link layer at the response node side executes the relevant processes in accordance with the IO
definitions intended for the node chosen among those contained in the solicitation frames that the FA link
layer have received from the lower layer. When a slave received two or more IO definitions, use the one
received last.
Note: A solicitation frame may be divided into pieces depending on the size so that they can be transmitted
separately. Each node shall pick up only the IO definitions intended for its self node from each segment of theframe. The remaining segments that do not contain such IO definitions can be discarded. Each slave does
not have to retain the divided data or put them together.
a)Note Transmitting a solicitation frame in the valid linking state means that the master shall transmit the frame
while it has a token.
To transmit a message frame or solicitation frame, satisfy the following four conditions.
1) If the refresh measuring time (RMT) is not greater than 90% of the maximum allowable refresh cycle time(RCT), the message frame or solicitation frame that shall currently be transmitted first according to thealternate transmission order can be transmitted in the one-frame transmission mode.
2) If the refresh measuring time (RMT) is greater than 90% of the maximum allowable refresh cycle time(RCT) but smaller than RCT, and if the solicitation frame shall be transmitted first according to the current
alternate transmission order, the solicitation frame can be transmitted in the one-frame transmission
mode.
3) If the refresh measuring time (RMT) is greater than the maximum allowable refresh cycle time (RCT),
neither message frame nor solicitation frame can be transmitted irrespective of which of message frameor solicitation frame shall be transmitted first according to the current alternate transmission order.
4) If there are no message frames or solicitation frames to be transmitted, no frames will be transmitted
irrespective of which of message frame or solicitation frame shall be transmitted first according to thecurrent alternate transmission order.

Figure 33 Solicitation Frame Transmission Service Sequence
The transmission order for solicitation frames is determined as follows. Solicitation frametransmission orders . shall be shown in Figure 34.
a)

In the case that a solicitation frame shall be transmitted according to the current alternate
transmission order, where no cyclic data or message data exist and yet -to-participate
slaves exist, transmit the solicitation frame, cyclic frame without data and token frame inthis order.

b)

In the case that a solicitation frame shall be transmitted first according to the current
alternate transmission order, where both cyclic data and yet -to-participate slaves exist,

– 53 –JEM1479：2012transmit the solicitation frame, cyclic frame and token frame in this order.
c)

In the case that a solicitation frame shall be transmitted first according to the current
alternate transmission order, where both divided cyclic data and yet -to-participate slave
exist, transmit the solicitation frame, divided cyclic frame and token frame in this order.

a)

Solicitation frame(for max. 64
stations)

Solicitation frame(for max. 64
stations)

Cyclic frame

b)

Token
frame

Solicitation frame(for max. 64
stations)

Cyclic frame

Cyclic framec)Cyclic frame (without cyclic
data)

Token
frame

Token
frame

Figure - 34 Transmission Order of Solicitation Frame8
8.1

Functions
Node ID (no.)

FL-net specifies node nos. as their identification information. Node nos. are used for “SNA”
and “DNA” presentation in the FA link header (see 10.1).
―

FL-net uses node nos. from 1 to 254. However node nos. from 250 to 254 are reserved formaintenance purpose.

―

Node no. 0 shall not be used.

―

Node no. 255 shall be used for DNA for broadcast message.

―

For token frames, use DNA for presenting the Node number of the next token transmission
destination.

8.2

Protocol data unit

The FA link protocol uses “frame” as a protocol data unit (PDU).
Data transmitted via a network are defined for each layer of the ne twork. The frame structure
is as shown in Figure 35.
The authenticity of the frames flowing in the network is guaranteed at the layers lower.than
the transport layer. Therefore this standard checks the authenticity of the frames by detecting
the authenticity of FA link information (FA link header) only. Frame types depend on the TCD
in the FA link header. The frame types defined by the FA link shall be shown in Table 9.
For the details of the FA link header, see 10.1.

– 54 –JEM1479：2012

Max. 1024 octets

User data

FA link header

Lower layer
headerUser data

FA link part

TrailerFrame
Max. 1500 octets

Figure - 35 Frame Structure

Table - 9 Fames Defined by FA Link
Name
(Reserved)
Transparent message frame(Reserved)
Token frame
Cyclic frame
Participation request frame
Byte block read frame (request)
Byte block write frame (request)
Word block read frame (request)
Word block write frame (request)
Network parameter read frame (request)
Network parameter write frame (request)
Stop command frame (request)
Operation command frame (request)
Profile read frame (request)
Trigger frame
Log data read frame (request)
Log data clear frame (request)
Message return frame (request)
Vendor specific message frame (request)
Solicitation frame
IO allocation setting frame (request)
IO allocation read frame (request)
Start frame of token retention time measurement (request)
End frame of token retention time measurement (request)
Start frame of measurement in general purpose communication
data sender log (request)
End frame of measurement in general purpose communication
data sender log (request)

Transaction code
0 to 9999
10000 to 59999
60000 to 64999
65000
65001
65002
65003
65004
65005
65006
65007
65008
65009
65010
65011
65012
65013
65014
65015
65016
65017
65018
65019
65020
65021
65022
65023

– 55 –JEM1479：2012

Table 9 Fames Defined by FA Link (continued)
Name
Configuration parameter setting frame (request)
Read frame of participating node management information
parameter (request)
Read frame of self node management information parameter(request)
Self node setting information parameter read frame (request)
Node reset frame (request)(Reserved) (for future extension)
Byte block read frame (response)
Byte block write frame (response)
Word block read frame (response)
Word block write frame (response)
Network parameter read frame (response)
Network parameter write frame (response)
Stop command frame (response)
Operation command frame (response)
Profile read frame (response)(Reserved)
Log data read frame (response)
Log data clear frame (response)
Message return frame (response)
Vendor specific message frame (response)(Reserved)
IO allocation setting frame (response)
IO allocation read frame (response)
Start frame of token retention time measurement (response)
End frame of token retention time measurement (response)
Start frame of measurement in general purpose communication
data sender log (response)
End frame of measurement in general purpose communication
data sender log (response)
Configuration parameter setting frame (response)
Read frame of participating node management information
parameter (response)
Read frame of self node management information parameter(response)
Self node setting information parameter read frame (response)
Node reset frame (response)(Reserved) (for future extension)(Reserved)

8.3

Transaction code
65024
65025
65026
65027
65028
65029 to 65202
65203
65204
65205
65206
65207
65208
65209
65210
65211
65212
65213
65214
65215
65216
65217
65218
65219
65220
65221
65222
65223
65224
65225
65226
65227
65228
65229 to 65399
65400 to 65535

Octet order

The frames defined by the FA link uses the rules for determining the order of octets as shownin Figure 36.
a)Octet order for header part―

The header of the token frame uses Big endian to order octets.

―

The header of the cyclic frame uses Big endian to order octets.

―

The header of the message frame uses Big endian to order octets.

―

The participation request frame uses Big endian to order octets.

―

The trigger frame uses Big endian to order octets.

―

The ACK data uses Big endian to order octets.

―

The header of the solicitation frame uses Big endian to order octets.

– 56 –JEM1479：2012b)

Octet order for data part―The data part of the cyclic frame uses Little endian to order octets.

―

The data part of the message frame uses Little endian to order octets.

―

Note that the data (parameters) part of the profile read frame uses Big endian to order octets.

―

The data part of the solicitation frame uses Little endian to order octets.

Cyclic frame
Without ACK data
Cyclic header

Area 1

Area 2

ACK data

Area 1

With ACK data
Cyclic header

Area 2

Token frame
Token header
Message frame
Message header

Message data

Participation request frame
Participation request
headerTrigger frame
Trigger header
Solicitation frame
Solicitation header

Solicitation data

: Big endian

Figure - 36 Octet Order for FA Link Frame: Little endian

– 57 –
8.4

JEM1479：2012

General purpose command serverThis is an interface function for setting and reading in various parameters from setting tools,
and for requesting start and stop of load measuring functions.
For commands available for the general purpose command server, see Table 3.
For the details of the frames of the commands, see part 10.
8.4.1

Communication sequence for the general purpose command server and setting
tools

The general purpose command server and setting tools use TCP and UDP. Theircommunication sequence is, as shown in Figure 37, basically such that a response shall occur
following a request irrespective of which of these protocols is used.
This contains a watchdog function for detecting missing of data to allow the setting tool toresend the request for transmission.
Note 1: Whether or not to resend depends on the setting tool and vendor application. The
protocol does not specify rules for the resending operation.
Note 2: Response time limit is determined by the setting tool.
Note 3: When the setting tool received a response from a node to a request aft er the
response time limit, setting tool discards the response. A judgment of an excess of responsetime limit is made by the sequence number (SEQ) set to each command header part at thetime of a request.
Note 4: The number of connections for each of TCP and UDP shall be 1 or larger respectively.
The maximum number of connections depends on the vendor.
Note 5: The node’s operation when the number of connections exceeds the limit isconsidered as vendor dependence.
Note 6: Nodes that do not support the comm ands from the general purpose command server
shall return M_RLT (message result in the FA link header) = 2 command not supported within
1 second, or return nothing.

– 58 –JEM1479：2012
Setting tool
(PC)

Node

RequestSEQ＝Basic sequence

Response
Response time limit

SEQ＝
RequestNo response arrived

SEQ＝

Response
Response time limit

SEQ＝
Request(resend)
SEQ ＝  ＋
1
Response

Response time limit

SEQ＝＋1

RequestResponse time limit

SEQ＝
Request (resend)

No request arrived

SEQ＝＋1
Response

Response time limit

SEQ＝＋1
RequestDelay of response

A response has been madebut it arrived at the PC later
than the specified responsetime limit.

SEQ＝

Response time limit
Request (resend)
Response 1
SEQ＝＋1
SEQ＝

Response time limit

Response(resend)1

SEQ＝＋1

Frames that arrived later than the specified
response time limit shall be discarded.

Figure 37 Basic Sequence of Response to Request

– 59 –
8.4.2

Communication sequence for TCP

8.4.2.1

Sequence for TCP

JEM1479：2012

When using TCP, the setting tool uses the sequence shown in Figure 38.

TCP
Setting
(PC)

tool

Node

SYN

SYN ACK
Connection open
ACK

Reque
st
ACK
Commandcommunication

Response
ACK

FIN

Connection close

FIN ACK
ACK

Note: The frames written in bold are checked by TCP to determine whether they havearrived.
Figure 38 Sequence for TCP
8.4.2.2

Connection open/close sequence

When using TCP, the setting tool executes “connection open” before starting communica tionand executes “connection close” after the communication.
For any operation of the tool (e.g. operation of pressing a button associated with a request for
executing multiple commands), “connection open” shall occur prior to the request for the firstcommand and “connection close” shall occur after th e final request.
The “connection open/close” sequence shall be shown in Figure 39.

– 60 –JEM1479：2012

Setting tool andmonitor tool(PC)

Connection open

Node

(SYN)
Connection open
ACK(SYN ACK)

ACK
Request for command A

ACK
Response to request forcommand A
ACK
・
・
・
・

Operationfrom the tool

Request for command Z

ACK
Response to request forcommand Z
ACKConnection close(FIN)

Connection close
ACK(FIN ACK)
ACK

Note: The frames written in bold are checked by TCP to determine whether they havearrived.
Figure 39 Connection Open/Close Sequence

– 61 –
8.4.3

JEM1479：2012

Communication sequence for UDP

Unlike TCP, no “connection open” or “connection close” sequence is required for starting andending communication. Under UDP, communication shall begin with transmission of a frame
containing a request for command execution.
When using UDP, the general purpose command server operates in the unicast mode.
When using UDP, the setting tool uses the sequence shall be shown in Figure 40.

Setting tool
(PC)

UDP
Node

RequestCommunication
for commandexecution

Response

Figure 40 Sequence for UDP

– 62 –JEM1479：2012
8.4.4

Load measuring function

This function measures the following items. The information obtained by this function isavailable for analyzing errors (see Table 10). All of the measurements are stored in the log
data area.
a)Missing of tokenb)Token retention timec)Refresh cycle timed)Number of the events of receiving cyclic datae)

Number of errors in receiving message dataf)Source IP address for TCP general purpose communicat ion to the self node, and thenumber of receiving events
Table 10 Error Events and Corresponding Measuring Items
Event 1)Disturbed token

Event 2)
Missing of token

Extension of token
retention time

Extension of refresh
cycle time
Missing cyclic data

Missing message data
Highercommunication
frequency of othernodes than FL-net

8.4.4.1

Communication to self
node

Load measuring item
Number of the events of discarding token
Time when the event of discarding token was
detected last
Number of the events of reissuing token
Time when reissuance of token occurred last
Number of the events of token retention timeout
Time when the token retention timeout event
occurred last
Number of the events of token watchdog timeout
Time when the token watchdog timeout event
occurred last
Maximum token retention time
Minimum token retention time
Detection time for the maximum token retention
time
Measuring time for token retention time
Number of tokens while measuring the token
retention time
Detection time for the maximum refresh cycle
Number of the events of receiving cyclic frame
Number of errors in receiving cyclic frame
Detection time for error in receiving cyclic frame
Number of errors in receiving message frame
Detection time for error in receiving message frame
Measuring time for general purpose communication
data sender log
General purpose communication data source IP
address (up to the first 10 IP addresses)
Number of the events of receiving general purpose
communication data (up to the first 10 IP
addresses)

Token retention time measuring function

This is to measure token retention time to determine whether or not communication frequency
of nodes other than those of FL-net is higher (see Figure 41).
It measures the minimum and maximum values of the time for which a node holds a token,
and the elapsed time until the maximum value is measured from the start of measurement,
and saves those values in a logging area.(for measuring items, see Table 12).

– 63 –JEM1479：2012

The measurement of token retention time starts when receiving a command for starting
measurement from the setting tool and ends when receiving a command for ending themeasurement (see Figure 42).
The measuring result is appended to the response data for the ending command.
If another start command is received during measurement, the current measurement shall be
stopped and new measurement shall be started. If an ending command is received again after
the measurement is ended, the latest measurement shall be appended to the respo nse for thecommand. Note that setting tools are not managed for issuance of commands, which meansthat the node can accept an ending command or another start command from other than thesetting tool that has now issued the start command for the current me asurement session.
In the event that power interruption or resetting of the node occurs during measurement, themeasurement data shall be discarded.
Measurement data can be compared with the preliminarily measured data of token retention
time in normal operation to know the difference in the intensity of load to determine whether
an error has occurred.
The transaction codes for measurement starting and ending commands shallbe shown in
Table 11.
Table 11 Transaction Codes for Measuring Token Retention Time
Name
Start frame of token retention time measurement (request)
End frame of token retention time measurement (request)
Start frame of token retention time measurement (response)
End frame of token retention time measurement (response)
Note: use port no. ”55 004” for transmission and receiving operation

Transaction code
65 02065 02165 22065 221

Table 12 List of Measuring Items for Token Retention Time
Measurement item
Unitb)
Number of the events of discarding token
Time
Time when the event of discarding token was detected
c)
sec
last
b)
Number of the events of reissuing tokenTimec)Time when reissuance of token occurred lastsecb)Number of the events of token retention timeout
Time
Time when the token retention timeout event occurred
c)
sec
last
b)
Number of the events of token watchdog timeout
Time
Time when the token watchdog timeout eventc)secoccurred last
Maximum token retention timeµSec (1/1 000 000 sec)
Minimum token retention timeµSec (1/1 000 000 sec)c)
Detection time for the maximum token retention timesecc)Measuring time for token retention timesec
Number of tokens while measuring the token retention
b)
Time
time
c)
Detection time for the maximum refresh cyclesecb)Number of the events of receiving cyclic frameTimeb)
Number of errors in receiving cyclic frameTimec)
Detection time for error in receiving cyclic framesecb)Number of errors in receiving message frameTimec)
Detection time for error in receiving message frameseca)Note O: New items since Ver. 3.00─：Log data items since Ver. 2.00b)
The number is as counted by a free-run counter.
c)Elapse since start of measurement (sec.)

Added by Ver. 3.00
─
○
─
○
─
○
─
○
○
○
○
○
○
○
─
─
○
─
○

a)

– 64 –JEM1479：2012
TCP
non-superposed
circuitCyclic frame
received

Token
receivedtransmission
FL-netmessagetransmitted

Cyclic frametransmittedTokentransmitted

Node 1Token
t: time
Node 2Token
retention
time

Token
retention
time

Token
retention
time

Token retention time is steady.
TCP superposed transmission
circuitCyclic frame
received

Token
received

Due to the process for superposed transmission
during holding a token, the token retention time
may vary.

FL-netmessagetransmitted

TCP
communica-tion
received

TCP
communica-tiontransmitted

Cyclic frametransmittedTokentransmitted

Token retention
time may vary

Node 1

Token

Token
retention
time

Token
retentiontime

t: time

Node 2Token
retention
time

Token
retention
time

Token
retention
time

TCP general
purposemachineFigure 41 Load Measurement by Token Retention Time– 65 –

SupervisingPC

JEM1479：2012

FL-netnode
Tokenreceived
Token retention
time
Token
transmitted

Request to themessage forstarting
measurement

Start measuring token
retention timeFirst token after receiving atoken retention timemeasuring command

Response to themessage forstarting
measurement

Token
received
Token retention timeTokentransmittedToken
retention time
Measuring time

Number of tokens
transmitted/receiv
ed duringmeasurement oftoken retention
time

Token retention time
to be measured
Tokenreceived
Token retention timeTokentransmittedRequestfor amessagefor ending
Response to
the message
for ending
measurement

End of measurementof token retention time

Token retention time
append themeasurement result tothe end-of-measurement
message

Figure 42 Approximate View of Token Retention Time Measuring Sequence
8.4.4.2

General purpose communication data sender logging function

This measures how many times the node receives the general purpose communication data
frames from each of the source IP addresses. However it does not count the event exceeding
the first 10 events for each source (for measuring ite ms, see Table 14).
This function starts with receiving a measurement start command from the setting tool andcontinues until a measurement ending command is received (see Table 13).
The measurement result shall be appended to the response for the measurement ending
command.
If another start command is received during measurement, the current measurement shall be

JEM1479：2012– 66 –

discarded and new measurement shall be started. If an ending command is received again
after the measurement is ended, the latest measurem ent shall be appended to the response
data. Note that setting tools are not managed for issuance of commands, which means thatthe node can accept an ending command or another start command from other than thesetting tool that has now issued the start com mand for the current measurement session.
In the event that power interruption or resetting of the node occurs during measurement, themeasurement data shall be discarded.
The transaction codes for measurement starting and ending commands shall be shown in
Table 13.
Table 13 Transaction Codes for General Purpose Data Sender Log
Name
Frame for starting measurement for general purpose data senderlog (request)
Frame for ending measurement for general purpose data senderlog (request)
Frame for starting measurement for general purpose data senderlog (response)
Frame for ending measurement for general purpose data senderlog (response)

Transaction code
65 02265 02365 22265 223

Table 14 List of Measuring Items for General Purpose Data Sender Log
Measuring item
Unit
Added by Ver. 3.00
Measuring time for general purposeb)Sec○communication data sender log
IP 1
─
○IP 1 receive counter
Time
○
IP 2
─
○
IP 2 receive counter
Time
○
IP 3
─
○
IP 3 receive counter
Time
○
IP 4
─
○
IP 4 receive counter
Time
○
IP 5
─
○
IP 5 receive counter
Time
○
IP 6
─
○
IP 6 receive counter
Time
○
IP 7
─
○
IP 7 receive counter
Time
○
IP 8
─
○
IP 8 receive counter
Time
○
IP 9
─
○
IP 9 receive counter
Time
○
IP 10
─
○
IP 10 receive counter
Time○
Note 1: Each measuring item consists of a 32-bit member.
Note 2: The sender log measuring time counter and receive counter are reset to 0 when arequest for starting measurement is received, and then start.
Note 3: Layers used for acquisition depend on the vendor.
a)
Note
O: New items since Ver. 3.00
─: Log data items since Ver. 2.00b)Elapse since start of measurement (sec.)a)

An example of operation of the general purpose data sender log function shall be shown in
Figure 43.
If the self node receives general purpose communication data from 11 IP addresses (IP1through IP11) during measurement, the data from addresses up to 10 IP addresses (IP1through IP10) are stored in the log while the data from IP11 is discarded.
The receive counter for an IP address increments by 1 every time when receiving data fromthe IP address (no receive counters for 11th or later IP addresses exist).

– 67 –JEM1479：2012

These receive counters do not support overflow of the count: after it reaches 16#FFFF_FFFF,
it is cleared to 0.
SupervisingPC

FL-net Node
Receiving
general purpose
communication

Request for a
message forstarting
measurement

Receiving
general purpose
communication

IP1
Response to
the message
for starting
measurement

IP2

Not stored in thelog since
measurement has
not started

Start of measurement for
general purpose
communication sender log

Receiving general purpose
communication

First data after
receiving a commandfor starting
measurement for
general purpose
communication senderlog
0Receiving general purpose
communication

IP1

31

Measuring time

IP1
IP3

IP1
IP1 receive counter = 3

IP2
IP4

IP2 receive counter = 1

IP3
IP5

Measuringtime

IP3 receive counter = 1

IP4
IP6

IP4 receive counter = 1

IP5
IP7

IP5 receive counter =1

・
・

IP8
IP10
IP9
Request for a
message forendingmeasurement

IP10 receive counter = 1

IP10
IP11

Data from IP11 is
discarded

Response to the message
for ending measurement
End of measurement for
general purpose
communication sender log

Figure 43 Operation of General Purpose Communication Data Sender Logging Function(Example)

– 68 –JEM1479：2012
8.4.4.3

Result notification

Load measurement results stored in the log data area can b e retrieved by using an existinglog data read message. Load measurement results are stored also in the log area.
Of the load measurement results stored in the log, those returned as response data are
denoted by a) and b) in Table 15. Items a) concern token retention time. Items b) concern
general purpose communication data sender log.
The log data area that the load measuring function uses s hall be shown in Table 15.
Table 15 Log Data Area Used by the Load Measuring Function
Offset (decimal)(octet)Name

Description

Imple
menta
tion

76

Number of the events of receiving cyclic
frame a)Data about frame type

Optional

96

Number of errors in receiving cyclic frame a)

Data about cyclic transmission

Mand
atory

Time when cyclic transmission/reception error is detected

Optional

116
152
180

Detection time for error in receiving cyclic
framea)Detection time for the maximum refresh
cycle a)Detection time for error in receiving message
framea)Time when maximum value during refresh cycle isdetected
Time when the event of failing to transmit/receive
message frame is detected

244

Number of the events of discarding token a)

Token related data

248

Number of the events of reissuing token a)

Token related data

Time when the event of discarding token
was detected last a)
Time when reissuance of token occurred lastTime when the number of the events of discarding token is
detected
Time when the number of the events of reissuing token is
detected

252
256
260
264
268
272

a)

Time when the token retention timeout event
occurred last a)
Number of the events of token retention
timeout a)
Number of the events of token watchdog
timeout a)Time when the token watchdog timeout
event occurred last a)

276

Maximum token retention time a)

280

Minimum token retention time a)284

Detection time for the maximum token
retention time a)

312

Measuring time for token retention time a)

316

Number of tokens while measuring the token
retention time a)

332

Measuring time for general purpose
communication data sender logb)

368

IP 1b)

372

IP 1 receive counter b)

376

IP 2 b)380

IP 2 receive counter b)

384

IP 3 b)

Optional
Optional

Mand
atory
Mand
atory
Optional
Optional

Time when the token retention timeout counter increments

Optional

Token related data

Optional

Token related data

Optional

Time when the token watchdog timeout counterincrements
Maximum token retention time measured during the periodthat starts with a measurement start command and ends
with a measurement end command
Minimum token retention time measured during the periodthat starts with a measurement start command and ends
with a measurement end command
Time when the maximum token retention time is updated
Period for measuring token retention time that starts with ameasurement start command and ends with ameasurement end command
Number of tokens received during measurement of token
retention time
Period for measuring general purpose communication
data sender log that starts with a measurement startcommand and ends with a measurement end command
IP address of General purpose communication data
sender log 1
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 1
IP address of General purpose communication data
sender log 2
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 2
IP address of General purpose communication data
sender log 3

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

– 69 –JEM1479：2012

Table 15 Log Data Area Used by the Load Measuring Function (continued)
Offset (decimal)(octet)Name

388

IP 3 receive counter b)

392

IP 4 b)396

IP 4 receive counter b)

400

IP 5 b)404

IP 5 receive counter b)

408

IP 6 b)412

IP 6 receive counter b)

416

IP 7 b)420

IP 7 receive counter b)

424

IP 8 b)428

IP 8 receive counter b)

432

IP 9 b)436

IP 9 receive counter b)

440

IP 10 b)444

IP 10 receive counter b)

Description
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 3
IP address of General purpose communication data
sender log 4
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 4
IP address of General purpose communication data
sender log 5
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 5
IP address of General purpose communication data
sender log 6
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 6
IP address of General purpose communication data
sender log 7
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 7
IP address of General purpose communication data
sender log 8
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 8
IP address of General purpose communication data
sender log 9
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 9
IP address of General purpose communication data
sender log 10
Number of the events of receiving data from the IP
address of General purpose communication data senderlog 10

Imple
menta
tion
Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Note: The data is stored using Little endian to order octets.
Note a) Measurement items for token retention timeb)

Measurement items for general purpose communication data sender log

8.4.4.4

Behavior when receiving a measurement start command during measurement

If another start command is received during measurement, the current measurement shall bediscarded and new measurement shall be started. If an ending command is received after themeasurement is ended, the latest measurement shall be appended to the response for thecommand. Note that setting tools are not managed for issuance of commands, which meansthat the node can accept an ending command or another start command from other than thesetting tool that has now issued the start command for the current measurement session.
Figure 44 shows how measurement start commands are handled while measurement isalready in operation.

– 70 –JEM1479：2012
AnothersupervisingPC

FL-netnode

Supervising
PC

Request for a message
for starting
measurement

Response to themessage forstarting
measurement

Start load
measurement

ReceptionMeasurement result

ReceptionPreviousmeasurements
are discarded

Request for a
message for starting
measurement

Start load measurement

Response to themessage forstarting
measurement

ReceptionMeasurement result

ReceptionRequest for a message
for starting measurement

Previousmeasurements
are discarded
Response to themessage for starting
measurement

Start load measurement

Reception
ReceptionLoad measuring time

Measurement result
Request for a
message forendingmeasurement

End of load
measurement

Reception
Reception

Response to
the message
for ending
measurement

Figure 44 Handling of Measurement Start Command that Occurs during Measurement

– 71 –
8.4.4.5

JEM1479：2012

Use of Load Measurement Result

Given that the system configuration shown in Figure 45 suffers fluctuation of the refresh
frequency when the PC 2 transmits general purpose communication data to Node 1 at higher
intervals, which causes Node 1 to sometimes disconnect from the system, the trouble can beanalyzed using the load measuring function, as shown in Figure 45.

FL-net Ver.3
Node 1
IP：192.168.250.1

FL-net Ver.3
Node 2
IP：192.168.250.2

HUB

・・・
・・

FL-net Ver.3
Node 100
IP：192.168.250.100

UDP and TCP
general purpose
communication

PC installed with a setting tool

General purpose PC 1

General purpose PC 2

IP：192.168.250.253

IP：192.168.250.200

IP：192.168.250.202

Figure 45 System Configuration for Measuring Token Retention TimeFor communication with Node 1, perform measurement for token retention time and general
purpose communication data sender log to obtain results as shown in Tables 16 and 17.
Based on the result, the trouble can be analyzed as follows.
a)Measurements of token retention time indicate (see Table 16)―

Token retention timeout events have occurred frequently, which suggests that the process cannot
be completed within the token retention time.

―

Based on the fact that the latest token retention timeout event occurred very recently, we can
suppose that the timeout events have occurred frequently.

―

The large difference between the maximum and minimum token retention time is an evidence oflarger network load.

b)Measurements for general purpose communication data sender log indicate (seeTable 17)―

The PC 2 (IP1: 192.168.250.202) initiated communication many times, which suggests thatgeneral purpose communication has occurred very frequently.

The abovementioned findings indicate that the very fr equent general purpose communicationfrom PC 2 to Node 1 has caused Node 1 to undergo large loads.
Possible measures for mitigating this problem include reducing the network load and changing
the relevant settings so that such large loads cannot be conside red as an error.
―

Measure 1: reduce the frequency of communication from PC 2 to Node 1.

―

Measure 2: review the token watchdog time (TW) from a system-wide viewpoint and adjust it
according to the measured load condition.

– 72 –JEM1479：2012

Table 16 Measurements of Token Retention Time for Node 1
Measuring item
Number of the events of discarding token
Time when the event of discarding token
was detected last
Number of the events of reissuing token
Time when reissuance of token occurred
last
Number of the events of token retention
timeout
Time when the token retention timeout
event occurred last
Number of the events of token watchdog
timeout
Time when the token watchdog timeout
event occurred last
Maximum token retention time
Minimum token retention time
Detection time for the maximum token
retention time
Measuring time for token retention time
Number of tokens while measuring thetoken retention time
Detection time for the maximum refresh
cycle
Number of the events of receiving cyclic
frame
Number of errors in receiving cyclic frame
Detection time for error in receiving cyclic
frame
Number of errors in receiving message
frame
Detection time for error in receiving
message frame

Measurement
0 times

Note
Not occurred

0 Sec
0 times

Not occurred

0 Sec
300 times

Token retention timeout eventsoccur very frequently

595 Sec

Not occurred

0 times0 Sec
250 000 µSec
1 000 µSec
30 Sec600 Sec
1 234 567 times

The difference between the
maximum and minimum values
is large
Measured for 10 minutes
Number of tokens during
measurement

80 Sec─

123 400 times

─

0 times

Not occurred

0 Sec
0 times

Not occurred

0 Sec

Table 17 Measurements of General Purpose Communication Data Sender Log for Node 1
Measuring item
Measuring time for general purpose
communication data sender log
IP 1
IP 1 receive counter
IP 2
IP 2 receive counter
IP 3
IP 3 receive counter
IP 4
IP 41 receive counter
IP 5
IP 5 receive counter
IP 6
IP 6 receive counter
IP 7
IP 7 receive counter
IP 8
IP 8 receive counter
IP 9
IP 9 receive counter
IP 10
IP 10 receive counter

Measurement
600 Sec
192.168.250.202
100000 times
192.168.250.200
3 times
192.168.250.253
10 times
0.0.0.0
0 times0.0.0.0
0 times0.0.0.0
0 times0.0.0.0
0 times0.0.0.0
0 times0.0.0.0
0 times0.0.0.0
0 times

Note
Measured for 10 minutes
PC 2 initiated communication veryfrequently
PC 1 initiated communication
infrequently
The setting tool initiated communication
infrequently
─
─
─
─
─
─
─

– 73 –
8.5

JEM1479：2012

System Configuration of Device Level Network Function

8.5.1

System Configuration of Fixed Setting Mode

The system configuration of the fixed setting mode shall be as follows.
a)

Basic Configuration of the Fixed Setting Modeslaves as shown in Figure 46.

Includes one master and N

2)

The master shall have the node number 100 , the self area of the common memory from
16#0100 to 16#01FF. The slaves shall have the node numbers from 1 to 64, the self area ofthe common memory from 16#0000 to 16#00FF. The common memory shall be allocated to
the fixed address by the node number as se lf areas of the master node and slave nodes. The
slaves write input data to their own self areas and read the output data from the master’s self
area corresponding to the slave node number. The input output area allocated to the common
memory shall be fixed to 4 words for inputs and 4 words for output. However, the valid input
and output data shall be the actual number of IO of slaves.
2)

Note
The master node number, which is 100 by default in the fixed setting mode, can bechanged in the range from 65 to 249, and is notified to the slave using the status area so thatthe slaves can check the master number of the self node. Even when the master node number
is changed, the self area of the common memory in the master shall be from 16#0100 to
16#01FF.
Common 1
16#0000

Input only

Input only

Output only

Input and output

Slave 1

Slave 2

Slave 3

Slave 64

Input data

Output data
16#00FF

ﾏｽﾀ
16#0100

Master 100
Master node
#100

Slave node

Node number: 100 (default)
Self area: 16#0100 to 16#01FF

#1

#2

#3

#64

Node number: 1 to 64
Max: 64 nodes
Input: 4 words (fixed)
Output: 4 words (fixed)
Self area: 16#0000 to 16#00FF

Figure 46 - System configuration of the fixed setting modeb)

IO Area Extension Configuration in the Fixed Setting Mode

Slaves have an IO area extension function to define areas over 4 words and settings of thestatus area can specify whether to use or not use the subsequent areas.
This setting allows, as shown in Figure 47, the slave node to use two or more areas in order
to exchange the IO data with the master. Although the IO area can be extended within therange of the slave area, the node in the duplicate area cannot be used.

– 74 –JEM1479：2012

Input
only

Input
only

Output only

Input and
outputSlave 1

Slave 2

Slave 4

Slave 64

Common
16#0000 Input1 data

Output data
16#00FF
16#0100
Master 100
Master node
#100
Node number: 100 (default)
Self area: 16#0100 to 16#01FF

Slave node

#1

#2

#4

#64

Node number: 1 to 64
Max: 64 nodes
Input: 4 words (fixed)
Output: 4 words (fixed)
Self area: 16#0000 to 16#00FF

Figure 47 – IO Area Extension Configuration in the Fixed Setting Mode– 75 –
8.5.2
a)

JEM1479：2012

The System Configuration of the Flexible Setting Mode

Basic Configuration of the Flexible Setting Mode

Consists of one master and N slaves.
As shown in Figure 48, the master shall be arbitrarily able to set the node numbers from 1 to249 and the self area of the common memory from the common memory area ,1, 2. In thesame manner, the slave can arbitrarily set the node numbers from 1 to 249 and the self areaof the common memory from the common memory area ,1, 2. The slaves write input data totheir own self areas and read the output data from the master's self area set by solicitation
frames.
The size of the input output area shall be able to be set in words according to the actual
number of the IOs.
The common memory settings of the slaves controlled by the master are distributed to theslaves using the solicitation frames.

Common 1 or 2
Anyaddress
within thearea

Input only

Input only

Output only

Input and output

Slave 12

Slave 23

Slave 34

Slave 249

Input data

Output data

Master 30
Master node
#30

Slave node

Node numbers from 1 to 249
Optional self area

#12

#23

#34

#249

Node number: 1 to 249
Max: 248 nodes
Input: Any word
Output: Any word
Self area: Any value

Figure 48 - Basic configuration of the flexible setting mode
8.5.3

Multi Master

A multi master is a function to implement two or more configurations including one masternode and several slave nodes on the FL-net network as shown in Figure. 49, and can operate
in both the fixed setting mode and the flexible s etting mode.
a)Multi master in the fixed setting mode

A multi master system can be built by changing the master node number from default setting(100) and allocating the master self areas divided by several master nodes.

– 76 –JEM1479：2012

Since the input output areas of the slaves are fixed, each master allocates a corresponding
slave to their own output area. Note that the area must be continuous.

Common 1
16#0000

Input only

Common 1

Output only

Input and output

Slave 34

Slave 64

Input data

Input data

16#00FF
16#0100

Output data

Output data
16#01FF
Master 101

Slave 12Master150

Master node number: 65 to 249
Slave node number: 1 to 64, max: 64 nodes
Self area: 16#0100 to 16#01FF (configured by Master)Self area size (configured by Master)
Slave nodes to be controlled (configured by Master)

Master node

#101

Slave node

Master nodeSelf area is definedcorresponding to therelevant slaves to becontrolled.
16#012C to 16#012F#12

Self area is defined#150 corresponding to therelevant slaves to becontrolled.
16#0184 to 16#01FF

#34

#64

Slave node numbers from 1 to 64
Maximum of 64 nodes
Fixed to 4 words for input
Fixed to 4 words for output
Self area from 16#0000 to 16#00FF

Figure 49 - The fixed setting mode of the multi masterb)

Multi master in the flexible setting mode

In the flexible setting mode, as shown in Figure 50, two or more master node can be definedin the range from 1 to 249 of the node number.
Each flexible master can arbitrarily set its node number in the range of 1 to 249, and allocate
self memory area in common memory area 1 and 2. In the same manner, each flexible slave
can arbitrarily set its node number in the range of 1 to 249, and allocate self memory area incommon memory area 1 and 2. Each master send the combination of the master and slaves tocorresponding slaves with solicitation frame.

– 77 –
Common 1 or 2
Any address
within thearea

Input only

JEM1479：2012

Common 1 or 2

Output only

Input and output

Slave 46

Slave 201

Input data
Input data

Output data
Output data

Master 30

Slave 12Master 80

Master node number: 1 to 249
Max: 249 nodes (incl. slave nodes)
Self area: Any value (configured by Master)Self area size (configured by Master)
Slave nodes to be controlled (configured by Master)

Master node

Master node

#30

#80

Slave node

#12

#46

#201

Slave node number: 1 to 249
Max: 249 nodes (incl. master nodes)
Input: Any word (configured by Master)
Output: Any word (configured by Master)Self area: Any value (configured by Master)Figure 50 - The flexible setting mode of the multi master– 78 –JEM1479：2012c)

Coexistence of the flexible setting mode and the fixed setting mode

The multi master with a mixture of different modes requires settings for each master and slave
as shown in Table 18.
Table 18 - Coexistence of the flexible setting mode and the fixed setting mode
Flexiblemaster
Flexiblemaster

Flexible slave

Fixed master

X
X
X
X

X

Notes
Single master (opt): Setting needed
Multi master (opt): Setting needed
Slave (fixed): Mapping fixed
Adjustment required to prevent
duplicate mapping
Single master (fix): Setting notnecessary
Based on the setting of Master(fix): Setting needed
Operation mode of Slave (fixed)
needed to be set on Slave (flex)

X
X

X

Fixed
master

X
X

X

X

8.5.4

Fixed slave

X

Coexistence of Nodes of Ver.2 and Ver.3

Both Ver. 3 nodes and Ver. 2 nodes can reside in the same network as follows.
a)Fixed setting mode

As shown in Figure 51, the common memory area not used by the master and slave can beused by other nodes as a shared memory.
Master nodeVer. 2 nodeSelf area:#100 16#0100 to 16#017F

Master nodeSelf area:
Determined in the range
not overlapping with themaster node or slave
node

#70

Control slave node:
1 to 31

Self area:
16#0180 to 16#01FF
Control slave node:
32 to 64

#13
1

Slave node
#1

#2

#3

#4

#64

Figure 51 - The fixed setting modeb)

Flexible setting mode

As shown in Figure 52, the common memory area not used by the master and slave can beused by other nodes as a shared memory.
Master nodein the fixed setting
mode
#10
0

Master nodein the flexible setting
modeVer. 2 nodeSelf area:
16#0100 to 16#01FF
Control slave node:
1 to 64

Self area:
Determined in the area
not overlapping with themaster node or slave
node

#70

#131

Node number:
1 to 249
Self area: Any value

Slave node
#1

#2

#3

#4

#64

#101

#150

Figure 52 - The flexible setting mode

#201

#249

– 79 –
8.5.5

JEM1479：2012

Limitation

This part describes the limitation on the fixed and flexible setting modes.
a)Fixed setting mode

The master node can use input from irrelevant slave nodes, but cannot output to irrelevantslaves as shown in Figure 53. The slave nodes which can be controlled by one master node
shall have continuous node numbers. (Ex. In Figure 52, slave node #10 and #20 cannot be
controlled by master #70 and #131.)
Fixed master node

#100

Slave node

Fixed master node

Relevant area
to becontrolled

#1

#2

#70

#3

#4

Fixed master node

Inputs from
irrelevant slaves
are available.

#10

Relevant area
to be controlled

#131

#20

#62

#63

#64

Figure 53 - The fixed setting modeb)

Flexible setting mode

The master node can, use input from irrelevant slave nodes, but cannot output to irrelevantslaves as shown in Figure 54. The control range here means the input output area of theslave node that master node in the flexible setting mode is con figured as the self master.
Master node in theflexible setting mode
#50

Master node in theflexible setting mode

Flexible master node

Relevant area tobe controlled#70

Inputs from
irrelevant slaves areavailable.

#131

Relevant area tobe controlled

Slave node
#1

#2

#3

#4

#64

#101

#150

Figure 54 - The flexible setting mode

#201

#249

– 80 –JEM1479：2012
8.6

IO Definition

8.6.1

IO Data Allocation in the Common Memory

Slave nodes are categorized to the fixed setting mode and flexible setting mode by the settingof the allocation of IO data and status data to the common memory area 1 and 2.
In the fixed setting mode, the common memory occupied by each node is uniquely determinedwith the node numbers, and in the flexible setting mode, the commo n memory occupied byeach slave is determined by the solicitation frames from the master.
IO data shall be allocated in the common memory as follows.
a)

Allocation in the fixed setting mode

The IO data and the status data are fixedly allocated to the common memory area 1 and 2.
(refer to Figure 55).
A configuration is consists of one fixed master(node number 100) and 64 slave nodes (nodenumber 1 to 64). The IO data is allocated to the common memory area 1 and the status datais allocated to the common memory area 2.
Common memory map

16#0000

Common memory area 1
Slave IO data

16#00FF
16#0100

Master IO data

Transmission area of slaves #1 to #64
in common memory area.
Transmission area of the masterCommon (send) memory of the master

16#01FF

Common memory area 2
16#0000

Status data

Transmission area of slaves #1 to #64
in common memory area.

16#03FF
16#0400

Master status data

Transmission area of the masterCommon (transmission) memory of themaster16#07FF
16#0800

Shared memory

Unused area

16#1FFF

Figure 55 - The common memory allocation in the fixed setting mode

– 81 –
1)

JEM1479：2012

Common Memory Area 1 (IO data)

One slave node shall occupy 4 words of the common memory, and the master node shalloccupy the maximum of 256 words of the common memory.
Common memory area 1 in the fixed setting mode shall be allocated as shown in FIgure 56.
Input data: Data from a slave to the master
Output data: Data from the master to a slave
16#0000 Input data (slave #1)

Send memory of the slave #1

16#0004 Input data (slave #2)
16#0008 Input data (slave #3)

Send memory of the slave #2
Send memory of the slave #3

・・
16#00F8 Input data (slave #63)

Send memory of the slave #63

16#00FC Input data (slave #64)

Send memory of the slave #64

16#0100 Output data (Slave #1)
16#0104 Output data (Slave #2)
16#0108 Output data (Slave #3)
・
16#01F8 Output data (Slave #63)
16#01FC Output data (Slave #64)

Send memory of the master node#100

Figure 56 - The common memory 1 allocation in the fixed setting mode
The continuous IO area per slave node can be only extended by setting a subsequent area
usage flag of the actual configuration slave type in the status area. The subsequent area
usage flag can be individually set for input and output, but slave node numbers ov erlappedwith the extended area cannot be used.
Allocation of the common memory 1 under the fixed setting mode when two or more areoccupied shall be shown in Figure 57.
16#0000 Input data (slave #1)

Send memory of the slave #1

16#0004 Input data (slave #1)
16#0008 Input data (slave #3)

Send memory of the slave #1
Send memory of the slave #3

・・
16#00F8 Input data (slave #63)

Send memory of the slave #63

16#00FC Input data (slave #64)

Send memory of the slave #64

16#0100 Output data (Slave #1)
16#0104 Output data (Slave #1)
16#0108 Output data (Slave #3)
16#010C Output data (Slave #4)
・
16#01F8 Output data (Slave #63)
16#01FC Output data (Slave #64)

Send memory of the masternode #100

Figure 57 - The common memory 1 allocation in the fixed setting mode
2)

The Common Memory Area 2 (Status data)

As status data, one slave node shall occupy 16 words, and the master node shall occupy the
maximum of 1,024 words of the common memory area 2.
The common memory area 2 in the fixed setting mode shal l be allocated as shown in Figure58.

– 82 –JEM1479：2012

16#0000 Input status (slave #1)

Transmission memory of theslave #1

16#0010 Input status (slave #2)

Transmission memory of theslave #2

16#0020 Input status (slave #3)

Transmission memory of theslave #3

・・・
16#03E0 Input status (slave #63)

Transmission memory of theslave #63

16#03F0 Input status (slave #64)

Transmission memory of theslave #64

16#0400 Output status (slave #1)

Transmission memory of themaster node #100

16#0410 Output status (slave #2)
16#0420 Output status (slave #3)
・・・
16#07E0 Output status (slave #63)
16#07F0 Output status (slave #64)

Figure 58 - Common memory area 2 allocation under the fixed setting modeb)

Allocation in the flexible setting mode

In the flexible setting mode, user can freely allocate the IO data and the status data for eachnode in common memory area 1 and 2.
The configuration is consist of the flexible master node (any node number) and the flexible
slave node (any node number), and the IO data and the status data are allocated to thecommon memory area 1 or 2.
Corresponding combination of the master and slaves and allocation of the common memory
occupied by slave nodes shall be set by the solicitation frames.
The area occupied by the master is allocated to continuous areas.
The common memory in the flexible setting mode shall be allocated as shown in Figure 59.
Common memory map
Common memory area 1
16#0000 Any value
16#01FF
Common memory area 2
16#0000 Any value

16#1FFF

Figure 59 - Common memory allocation in the flexible setting mode

– 83 –
1)

JEM1479：2012

Example of the Common Memory Allocation

1.1) In the case the IO area and the status area of the slaves are allocated individuallyin common memory area 1 and 2.
The common memory in the flexible setting mode shal l be allocated as shown in Figure 60.
Master #100
Area 1Master #101

Input data #1
Input data #2
Output data #1
Output data #2
Input data #3
・・
Input data #64
Output data #3

IO data allocated to the area 1

・・
Output data #64

Area 2

Input status #1
Input status #2
Output status #1
Output status #2
Input status #3
・・

Status data allocated to the area 2

Input status #64
Output status #3
・・
Output status #64

Figure 60 - The common memory allocation in the flexible setting mode (pattern 1)

– 84 –JEM1479：2012

1.2) In the case the IO area and the status area of the slaves are allocated together incommon memory area 1 and 2
The common memory allocation in the flexible setting mode shall be as shown in Figure 61.
Master #100
Area 1Master #101

Input data #1
Input status #1
Input data #2
Input status #2
IO data and Status
data allocated to thearea 1

Output data #1
Output status #1
Output data #2
Output status #2

Area 2

Input data #3
Input status #3
・・
Input data #64
Input status #64
Output data #3
Output status #3

IO data and Status
data allocated to thearea 2・・
Output data #64
Output status #64

Figure 61 - The common memory allocation in the flexible setting mode(pattern 2)

– 85 –
2)

JEM1479：2012

Allocation Procedure of the Common Memory

The common memory allocation shall be set to flexible master with IO allocation setting
frames (Figure 62), and shall be distributed from flexible master to flexible slave withsolicitation frames (Figure 63).
For details of the IO allocation and solicitation frames, refer to 10.4 and 10.5.
Common memory

Area 1

Offsetaddress(Word)
16#0000

Data usage

Input data #10

16#0003
16#0004

Input status #10

IO allocation
No.1

16#0013・・
16#0100
16#0103
16#0104

Output data #10

Output status #10

16#0113
Area 216#001416#0015
16#0016

Input data #11

Input status #11

16#0025
・・
16#0200
16#0202
16#0203
16#0212・・

Output data #11

Output status #11

No.2

Setting No. (n-th)

16#0001

Number of control slaves (total)

16#0002

Lock ID

16#0000

Lock timeout setting value

16#0005

Slave node number

16#000A

Input data address

16#0000

Input data size

16#0004

Output data address

16#0100

Output data size

16#0004

Input status address

16#0004

Output status address

16#0104

Reserve

16#0000

Setting No. (n-th)

16#0002

Number of control slaves (total)

16#0002

Lock ID

16#ABCD

Lock timeout setting value

16#0005

Slave node number

16#000B

Input data address

16#8014

Input data size

16#0002

Output data address

16#8200

Output data size

16#0002

Input status address

16#8016

Output status address

16#8203

Reserve

16#0000

Figure 62 - IO allocation values for flexible master– 86 –JEM1479：2012

Data part of the solicitation frame

Setting 1

Setting 2

Offset(octet)0

Items
Slave node number

Settingvalues
16#000A

2

Input data address

16#0000

4

Input data size

16#00046

Output data address

16#0100

8

Output data size

16#0004

10

Input status address

16#000412

Output status address

16#0104

14

Lock ID

16#0069

16

Slave node number

16#000B

18

Input data address

16#8014

20

Input data size

16#000222

Output data address

16#8200

24

Output data size

16#0002

26

Input status address

16#801628

Output status address

16#820330

Lock ID

16#0069

An information set ofslave

The IP address of flexible
master is assumed to be
192.168.100.105

An information set ofslave(For slave #11)

The IP address of flexible
master is assumed to be
192.168.100.105

Figure 63 - Solicitation frames generated from IO allocation setting

– 87 –c)

JEM1479：2012

Relation between the solicitation frames and the common memory in the fixed andthe flexible setting modes

The solicitation frames and the common memory in the fixed setting mode and the flexible
setting mode shall be related as shown in Figure 64.
Fixed setting mode
Master 100
Area 1

Area 2

IO data #1 input
IOIOデータ#2入data #2 input
IO data #3 input：：
IO data #64 input
IO data #1 output
IO data #2 output
IO data #3 output：：
IO data #64 output
Status #1
Status #2
Status #3：：
Status #64
Status #1
Status #2
Status #3：：
Status #64

Flexible setting mode
Master 129

Master 130

Master 131

Master 132

IO data #1
IO data #1
IO data #2
IO data #2
IO data #3：：
IO data #64
IO data #3：：
IO data #64
Status #1
Status #1
Status #2
Status #2
Status #3：：
Status #64
Status #3：：
Status #64
IO data #65
Status #65：：
IO data #128
Status #128
IO data #65
Status #65：：
IO data #128
Status #128

The fixed setting mode does
not need solicitation frames

Solicitation frame#1

Solicitation frame#2

Solicitation frame#3

Solicitation frame#65

Input area address
Input area address
Input area address
Input area address
Input size
Input size
Input size
Input size
Output area address Output area address Output area address Output area address
Output size
Output size
Output size
Output size
Input status address Input status address Input status address Input status address
Output status address Output status address Output status address Output status address

#4

#66

Input area address
Input area address
Input size
Input size
Output area address Output area address
Output size
Output size
Input status address Input status address
Output status address Output status address

：
：

：
：

#64

#128

Input area address
Input area address
Input size
Input size
Output area address Output area address
Output size
Output size
Input status address Input status address
Output status address Output status address

Figure 64 - Relation between solicitation frames and the common memory

– 88 –JEM1479：2012
8.6.2

Status Areas

This part describes the configuration of the status areas for the master and slaves in the fixed
setting mode and the flexible setting mode.
When the subsequent area mentioned later is used, each parameter in the subsequent areas
shall be as follows.
―

Setting values of execution slave type and specified slave type: Valid (required)―

Setting values of the remote control area, the slave status, the simple setting area, the simple
setting confirmation area, the reservation area, and the general-purpose status area: Invalid(ignored)

8.6.2.1

Slave Status Areas in the FixedThis is an area to notify the master of the status of slave (refer to Figure 65).
The address is an address of the common memory area 2.

Address
16#0000
Slave
output

16#0001
16#0002

Slave status

Area 2Size
Write(Word)
1
Slave #1

Actual slave type

1

Usage

Slave #2

Indicates the state transition of a slavewith the state number
Indicates the slave configuration andthe number of IO
Master node number (flexible andfixed)
Slave operation setting confirmation
statusData copied from the simple settingarea specified from the master
Used for the status notified from aslave..
Same as above

Slave #3

Same as above

Slave #63

Same as above

Slave #64

Same as above

Simple setting confirmation 1
area
1
6

16#000A
16#001016#001116#001216#001A
16#0020
16#002116#002216#002A：
16#03E0
16#03E1
16#03E2
16#03EA
16#03F0
16#03F1
16#03F2
16#03FA

General-purpose status
area
Slave status
Actual slave type
Simple setting confirmation
area
General-purpose status
area
Slave status
Actual slave type
Simple setting confirmation
area
General-purpose statusarea

6

Slave status
Actual slave type
Simple setting confirmation
area
General-purpose status
area
Slave status
Actual slave type
Simple setting confirmation
area
General-purpose status
area

1
1
8

1
1
8

Notes

6
1
1
8
6

6
1
1
8
6

Figure 65 - Slave status areas in the fixed setting mode

– 89 –JEM1479：2012

The slave status area in the fixed setting mode shall be as follows.
a)

Slave status Indicates the state transition of a slave with the state number.

0: Not joined, 1: Stopped, 2: Connecting, 3: In operation (during input and output), 4: No
master, 5: Self node removed, 6: Setting errorb)Actual slave typeThe actual configuration of a slave (the number of IOs of aslave) is shown below.

A slave compares the specified slave type notified from the master with the actual slave type.
If they are not matched, the slave status shall be "6: Setting error".
D15 to D8: Output slave, D7 to D0: Input slave
D15/D7: 0: Not used (0), 1: Used
D14/D6: 0: The subsequent area not used, 1: Used
D13 to D8/D5 to D0: Number of points (“16#00: 1” to “16#3F: 64”)
For details, refer to Figure 66. An example of actual slave type shall be as shown in Figure 67.
D15

Output slave

D8

Number of points (16#00: 1 to 16#3F: 64)

Note

D7

Input slave

D0

Number of points (16#00: 1 to 16#3F: 64)

1: Subsequent area used
0: Subsequent area not used

1: Subsequent area used
0: Subsequent area not used

1: Used (with the output number)
0: Not used (with no output number)

1: Used (with the input number)
0: Not used (with no input number)

As for "Subsequent area used", when a slave occupies the area over the maximum of 64
points, the subsequent area can also be used with the slave by setting the "Subsequentarea used". However, only the continuous area can be used without any blank area.
For example, in case of a module with 127 point outputs and 129 point inputs, actual
slave type shown in Figure 67 is set, and the three status areas (16 words x 3= 48 words)
are occupied for 129 point input setting by using the subsequent areas.

Figure 66 - The status of the actual slave type (Slave status in the fixed setting mode)

– 90 –JEM1479：2012

Actual slave type
D15
Slave #n

1

1

1

1

1

1

1

D15
1

Slave #n+1

0

1

1

1

1

1

D15
Slave #n+2

0

0

0

0

0

0

0

D8

D7

1

1

D8

D7

0

1

D8

D7

0

1

D0
1

1

1

1

1

1

1

D0
1

1

1

1

1

1

1

D0
0

0

0

0

0

0

1

Subsequent area for input

Subsequent area for output

Figure 67 - An example of the status of the actual slave type
(Slave status in the fixed setting mode)c)

Simple Setting Confirmation Area

Eight word area for checking whether the simple setting from the master has been reflected,
including the following:
1)

Master node number:

2)

Slave operation setting confirmation status (refer to Figure 68)
D15

Indicates the master node number controlling slaves.

D2 D1 D0

D0: IO output upon removal of the master(hold, clear)
D1: IO output when the remote control flag is OFF(hold, clear)
D2: IO input when the remote control flag is OFF(hold, clear)
The bit on the above (0: clear, 1: hold)

Figure 68 - Slave operation setting confirmation status in the simple setting
confirmation area (Slave status in the fixed setting mode)3)

he contents retrieved in the simple setting area specified from the master shall bereflected.

d)General-purpose status area Is used for the status notified from a slave.

8.6.2.2

Master Status Area in the Fixed Setting Mode

The master status area is to notify the slaves of the status of the master (Refer to Figure 69).
Slaves receive the master’s operating instructions from the master status area.
The address is an address of the common memory area 2.
Since the master status is dynamically changed, it is checked periodically to reflect to slave
operation.

– 91 –JEM1479：2012

Remote control area and slave operating instructions can be dynamically changed, andoperation when other data is dynamically changed shall depend on implementation.
Address

Usage

16#0400
16#0401
16#0402

Remote control area (for #1)
Specified slave type (for #1)
Simple setting area (for #1)

Size(Word)
1
1
1

1

16#040A

16#0410
16#041116#041216#041A
16#0420
16#0421
16#042216#042A

Reserved area (for #1)

6
6

Area 2
Write

Notes

MasterMaster node number instructions (fixed setting
mode only)
Setting ranges are 0, and from 65 to 249a0=100 (default)a) Slave operating instructions
D0: IO output upon removal of the master(hold, clear)
D1: IO output when the remote control flag is OFF(hold, clear)
D2: IO input when the remote control flag is OFF(hold, clear)
The bit on the above (0: clear, 1: hold)Contents can be defined with slave products
Shall be 16#0000 (fixed) in the current
specification and confirmation on the slave side is
not necessarySame as above

Remote control area (for #2)
1
MasterSpecified slave type (for #2)
1
Simple setting area (for #2)
8
Reserved area (for #2)
6
Remote control area (for #3)
1
Master Same as above
Specified slave type (for #3)
1
Simple setting area (for #3)
8
Reserved area (for #3)
6：
16#07E0
Remote control area (for #63)
1
Master Same as above
16#07E1
Specified slave type (for #63)
1
16#07E2
Simple setting area (for #63)
8
16#07EA
Reserved area (for #63)
6
16#07F0
Remote control area (for #64)
1
Master Same as above
16#07F1
Specified slave type (for #64)
1
16#07F2
Simple setting area (for #64)
8
16#07FA
Reserved area (for #64)
6
a)
Note
The master shall set the self node number to the master node number instrution area of thecorresponding slave node. However, the node numbers (areas) of the slave nodes controlled by one
master shall be continuous.

Figure 69 - Master status areas in the fixed setting mode
The master status areas in the fixed setting mode shall be as follows.
a)Remote control area Is an area to set remote control of slaves (Refer to Figure 70).

Slaves start and stop operation based on operating instructions from the master.
Remote stop: Instructs to stop the slave from operating.
Remote operation: Instructs to start the slave operating. Slaves shall start operating w hen thechange of this bit from 0 to 1 is detected during the slave status “1: Stopped”.

– 92 –JEM1479：2012

D15

D0

1: Remote Operation
0: Remote Stop

Figure 70 - The status of the remote control area
(Master status in the fixed setting mode)b)Specified slave type

D15 to D8: Output slave, D7 to D0: Input slave
D15/D7: 0: Not used (0), 1: Used
D14/D6: 0: The subsequent area not used, 1:Used
D13 to D8/D5 to D0: Number of points (16#00: 1 to 16#3F: 64)
For details, refer to Figure 71. An example of specified slave type shall be a s shown in Figure
72.
D15

Output slave

D8

Number of points (16#00: 1 to 16#3F: 64)

D7

Input slave

D0

Number of points (16#00: 1 to 16#3F: 64)

1: Subsequent area used
0: Subsequent area not used

1: Subsequent area used
0: Subsequent area not used

1: Used (with the output number)
0: Not used (with no output
number)

1: Used (with the input number)
0: Not used (with no input
number)

Note As for "Subsequent area used", when a slave occupies the area over the maximum of 64
points, the subsequent area can also be used with the slave by setting "Subsequent areaused". However, only the continuous area can be used without any blank area.
For example, in case of a module with 127 point outputs and 129 point inputs, the specified
slave type shown in Figure 72 is set, and the three status areas (16 words x 3= 48 words)
are occupied for 129 point input setting by using the subsequent areas. (The specified slave
type from the master indicates an expected value of the number of slave IOs. The slave
checks consistency with the expected value, and if it is inconsistent, the slave status shallbe the setting error).
Figure 71 - The status of specified slave type (Master status in the fixed setting mode)

– 93 –JEM1479：2012

Specified slave type
D15
Slave #n

1

1

1

1

1

1

1

0

1

1

1

1

0

0

0

0

0

1

1

D8

D7

0

1

D8

D7

0

1

1

D15
Slave #n+2

D7

1

D15
Slave #n+1

D8

0

0

D0
1

1

1

1

1

1

1

D0
1

1

1

1

1

1

1

D0
0

0

Subsequent area for output

0

0

0

0

1

Subsequent area for input

Figure 72 - An example of the status of specified slave type
(Master status in the fixed setting mode)c)

Simple setting area

Is an 8-word area for setting from the master, including the followings:
1)

Master node number:setting mode.

―

0 specifies the master node number 100 by default.

―

Master node number 65 or more can be set.

2)

Slave operating instructions (refer to Figure 73)
D15

Specifies the master node number to control the slave in the fixed

D2 D1 D0

D0: IO output upon removal of the master(hold, clear)
D1: IO output when the remote control flag is OFF(hold, clear)
D2: IO input when the remote control flag is OFF(hold, clear)
The bit on the above (0: clear, 1: hold)

Figure 73 - The status of slave operating instructions in simple setting area
(Master status in the fixed setting mode)3)

An area instructed from the master and defined for each slave

– 94 –JEM1479：2012
8.6.2.3

Slave Status Areas in the Optional Setting Mode

This is an area to notify the master of the status of slave (refer to Figure 74).
The address is a word address configured with the input status address in the data part ofsolicitation frames from the master.
Area 1 or area 2
Address
Slave
outputUsage

Size(Word)

Write

Notes

16#0000 Slave status

1

Slave #n

Indicates the state transition of a slavewith the status number

16#0001 Actual slave type1

Indicates the slave configuration and
the Number of points

16#0002 Simple setting confirmationarea

1

Master node number (flexible andfixed)

1

Slave operation setting confirmation
status6

Contents taken in the simple settingarea specified from the master16#000A General-purpose statusarea

6

Used to notify of the status from aslave.

16#0010 Slave status

1

16#0011 Actual slave type1

16#0012 Simple setting confirmationarea

8

16#001A General-purpose status
area

6

・
・

Note

・
・
a)

・
・

Slave #n’Same as above

a)

・
・

Same as abovea)

These areas are used when the subsequent areas are used (only when exceeding
64 points).
Figure 74 - Slave status areas in the flexible setting mode

Slave status areas in the flexible setting mode shall be as follows.
a)

Slave status

Indicates the state transition of a slave with the state number.
0: Not joined, 1: Stopped, 2: Connecting, 3: In operation (during input and output), 4: No
master, 5: Self Node removed, 6: Abnormal Settings(when the slave type specified from themaster is inconsistent with the actual slave type)b)

Actual slave typeThe actual configuration of a slave (the number of IOs of a slave) is shown below.
D15 to D8: Output slave, D7 to D0: Input slave
D15/D7:0: Not used (0), 1:Used

D14/D6:0:Subsequent area not used, 1: Used

D13 to D8/D5 to D0: Number of points (16#00: 1 to 16#3F: 64)
For details, refer to Figure 75. An example of actual slave type shall be as shown in Figure 76.

– 95 –

Output slave

D15

JEM1479：2012
Input slave

D7

D8

D0

Number of points (16#00: 1 to 16#3F: 64)

Number of points (16#00: 1 to 16#3F: 64)
1: Subsequent area used
0: Subsequent area not used

1: Subsequent area used
0: Subsequent area not used

1: Used (with the output number)
0: Not used (with no output number)

1: Used (with the input number)
0: Not used (with no input number)

Notes As for “Subsequent area used”, when a slave occupies the area over the maximum of 64
points, the subsequent area can also be used with the slave by setting "Subsequent areaused". However, only the continuous area can be used without any blank area.
For example, in case of a module with 127 point outputs and 129 point inputs, when the
output data size is set to be 8 words and the input data size is set to be 9 words in thesolicitation frame from flexible master, the actual configuration shall be set as follows.
Figure 75 - The status of the actual slave type (Slave status in the flexible setting mode)
Actual slave type
D15
Slave #n

1

1

1

1

1

1

1

D15
Slave #n+1

1

0

1

1

1

1

1

D15
Slave #n+2

0

0

0

0

0

0

0

D8

D7

1

1

D8

D7

0

1

D8

D7

0

1

D0
1

1

1

1

1

1

1

D0
1

1

1

1

1

1

1

D0
0

Subsequent area for output

0

0

0

0

0

1

Subsequent area for input

Figure 76 - An example of the status of the actual slave type(flexible setting mode slave status)
The status area to be used shall be 16 words x 3 = 48 words because the status areas forthree are needed for setting the subsequent area of the input slave, considering maximum
128 points for outputs from the output data size and maximum 144 points for ou tputs from
input data size configured in the solicitation frames.
c)Simple setting confirmation area

Is an 8-word area for checking whether the simple setting from the master has been reflected,
including the followings:
1)

Master node number:

Indicates the master node number controlling slaves.

2)

Slave operation setting confirmation status (refer to Figure 77)

– 96 –JEM1479：2012

D15

D2 D1 D0

D0: IO output upon removal of the master(hold, clear)
D1: IO output when the remote control flag is OFF(hold, clear)
D2: IO input when the remote control flag is OFF(hold, clear)
The bit on the above (0: clear, 1: hold)

Figure 77 - Slave operation setting confirmation status in the simple setting
confirmation area (Slave status in the flexible setting mode)3)

The contents retrieved in the simple setting area specified from the master shall bereflected.

d)General-purpose status area Is used for the status notified from a slave.

8.6.2.4

Master Status Area in the Optional Setting Mode

The master status area is to notify the slave of the status of the master (Refer to Figure 78).
The address is an offset word address from the output status address in the data part of the
IO allocation setting frame (A status area is allocated for each slave).
Since the master status is dynamically changed, it is checked periodically to reflect to slave
operation.
Address
16#0000
16#0001
16#0002

Usage
Remote control area (for #n)
Specified slave type (for #n)
Simple setting area (for #n)

Area 1 or area 2Size(Word)
Write
1Master1
1
1

6

16#001016#001116#001216#001A
・
・

1
1
8
6
・
・

Note

a)

b)

Remote control area (for #n')Specified slave type (for #n')
Simple setting area (for #n')Reserved area (for #n')・・

Master node number instructionsa)Slave operating instructions
D0: IO output upon removal of the master(hold, clear)
D1: IO output when the remote control flag is
OFF (hold, clear)
D2: IO input when the remote control flag is
OFF (hold, clear)
0= clear and 1= hold for the above-mentioned
bit.
Contents can be defined with slave products

6
16#000A Reserved area (for #n)

Notes

MasterShall be 16#0000 (fixed) in the current
specification and confirmation on the slave
side is not necessaryb)Same as above

Same as aboveb)

The master shall set the self node number to the master node number instrution areaof the corresponding slave node.
These areas are used when the subsequent areas are used (only when exceeding 64
points).
Figure 78 - The flexible setting mode

Master status areas

– 97 –JEM1479：2012

The master status areas in the flexible setting mode shall be as follows.
a)Remote control area

An area to set remote control of slaves (Refer to Figure 79).
Slaves start and stop operation based on operating instructions from the master.
Remote stop: Instructs to stop the slave from operating.
Remote operation: Instructs to start the slave operating. Slaves shall start operating when thechange of this bit from 0 to 1 is detected during the slave status “1: Stopped”.
D15

D0

1: Remote Operation
0: Remote Stop

Figure 79- The status of the remote control area
(Master status in the fixed setting mode)b)Specified slave type

Indicates the expected configuration of the slave expected by the master.
D15 to D8: Output slave, D7 to D0: Input slave
D15/D7:0: Not used (0), 1: Used

D14/D6:

0: The subsequent area not used, 1: Used

D13 to D8/D5 to D0: Number of points (16#00: 1 to 16#3F: 64)
For details, refer to Figure 80. An example of specified slave type shall be as shown in Figure81.

– 98 –JEM1479：2012

D15

Output slave

Input slave

D7

D8

D0

Number of points (16#00: 1 to 16#3F: 64)

Number of points (16#00: 1 to 16#3F: 64)
1: Subsequent area used
0: Subsequent area not used

1: Subsequent area used
0: Subsequent area not used

1: Used (with the output number)
0: Not used (with no output number)

1: Used (with the input number)
0: Not used (with no input number)

Notes As for "Subsequent area used", when a slave occupies the area over the maximum of 64
points, the subsequent area can also be used with the slave by setting "Subsequent areaused". However, only the continuous area can be used without any blank area. For
example, in case of a module with 127 point outputs and 129 point inputs, the specified
slave type shown in Figure 81 is set, and the three status areas (16 words x 3= 48 words)
are occupied for 129 point input setting by using the subsequent areas. (The specified
slave type from the master indicates an expected value of the number of slave IOs. The
slave checks consistency with the expected value, and if it is inconsistent, the slave status
shall be the setting error).
Figure 80 - The status of specified slave type
(Master status in the flexible setting mode)

Specified slave type
D15
Slave #n

1

1

1

1

1

1

1

D15
Slave #n+1

1

0

1

1

1

1

1

D15
Slave #n+2

0

0

0

0

0

0

0

D8

D7

1

1

D8

D7

0

1

D8

D7

0

1

D0
1

1

1

1

1

1

D0
1

1

1

1

1

1

1

D0
0

Subsequent area for output

0

0

0

0

0

Subsequent area for input

Figure 81 - An example of the status of specified slave type
(Master status in the flexible setting mode)c)1

Simple setting area

Is an 8-word area for setting from the master, including the followings.
1)

Master node number: Specifies the master node number to control the slave in theflexible setting mode. The number from 1 to 249 can be set.

2)

Slave operating instructions (refer to Figure 82)

1

– 99 –D15

JEM1479：2012

D2 D1 D0

D0: IO output when the master is disengaged(hold, clear)
D1: IO output when the remote control flag is OFF(hold, clear)
D2: IO input when the remote control flag is OFF(hold, clear)
0= clear and 1= hold for the above-mentioned bit

Figure 82 - Simple setting area The status of slave operating instructions(flexible setting mode master status)
3)n area instructed from the master and defined for each slave.

8.7

Timer

8.7.1

Token Watchdog Time (TW)Token Watchdog Time (TW) is the maximum time from a token obtained by a node to thetoken to be issued. The TW that each node has is notified to all nodes as information in theframe header. Each node uses the TW value in the frame as monitoring time from the token
obtained to the token to be issued by the appropriate node.
The value of the token watchdog time shall be from 1 to 255 ms (incremented by 1 ms).
8.7.2

Token Retention Time (THT)Token Retention Time (THT) is a time that a node guarantees the issue of a token. Each node
shall issue a token within this period of time. When internal processing takes longer than thisperiod of time, a token is not issued in order to prevent from having two or more tokens. The
THT value shall not exceed the TW value (incremented by 1 ms)
8.7.3

Allowable Minimum Frame Interval Time (MFT)

Allowable Minimum Frame Interval Time (MFT) is the minimum interva l ensured from the endof a frame to the subsequent frame to be sent.
The MFT is used in the following two cases.
a)Period of time from when a token to the self node is received to when the self nodetransmits a certain frame.

b)Period of time from frame transmission of a self node to the next frame transmission(cyclic division, transmission of a message) (Period of time from the end of the previous
frame to the beginning of the next frame).

The MFT value obtained by each node is notified to all the nodes as header information offrames. Each node calculates the maximum value based on the information, and uses it as an
MFT value. The MFT value shall be from 0 to 5,000 microseconds (incremented by 100
microseconds).
The MFT shall not be applied between a token frame and the previous cyclic frame. The time
between these frames shall be at the minimum.
8.7.4

Allowable Refresh cycle time (RCT)

Allowable Refresh cycle time (RCT) is the 120% value of the time for a token to circulate
around at a single time if a node does not receive a message frame from when the node
obtains the token addressed to the node to when the node obtains the token addressed to thenode next time.
The RCT on the the self node frame shall be "0" in the network startup state. The RCT value– 100 –JEM1479：2012

shall be set to frames after token frames addressed to the self node are received 3 times.
Therefore, a message is not transmitted until the token circulates around 3 times.
Nodes joining in in-ring startup state shall set the RCT value to the frame after the token
frames addressed to the self node are received 3 times. However, if RCT value cannot be
specified, the allowable refresh cycle time of the lastly received cyclic frame is used.
Through the monitoring process above, the RCT is dynamically determined based on thenumber of nodes joining the network. The RCT value shall be incremented by 1 ms.
8.7.5

Refresh Cycle Measurement Time (RMT)

Refresh Cycle Measurement Time (RMT) is a period of time between when a certain node
obtains a token addressed to the node and when it obtains the token addressed to the node
next time. The RMT value shall be incremented by 1 ms.
8.7.6

Joining Token Detection Time (TDT)

Joining Token Detection Time (TDT) is a period of time to monitor whether or not a node is in
the valid linking state when it participates in the network. Except when a token frame or a
trigger frame is received, a node transmits no frames until this time period is exceeded. The
TDT value shall be fixed (3,000 ms).
8.7.7

Participation Request Frame Transmission Waiting Time (PWT)

Participation Request Frame Transmission Waiting Time (PWT) is a period of time after thenode in the network startup state receives or sends a trigger frame until the node sends aparticipation request frame. The participation request frames are transmitte d with the timer
value based on the node number for each node to prevent a overlap of the other newly
participating node.
PWT = n (node number) X 4
n：

8.7.8

Node number

Participation Request Frame Acceptance Time (PAT)

Participation Request Frame Acceptance Time (PAT) is a waiting time after the node in the
network startup state receives or sends a trigger frame until other nodes send a participation
request frame. The PAT value shall be fixed (1,200 ms).
8.7.9

Trigger Frame Transmission Waiting Time (TrWT)Trigger Frame Transmission Waiting Time (TrWT) is a period of time after the TDT is
exceeded until the node transmits a trigger frame.
TrWT = R X 4
R：

8.7.10

Remainder when the node number isdivided by 8

Three Circulation Waiting Time (3CWT)

Three Circulation Waiting Time (3CWT) is a time to monitor the token to circulate around 3
times. The node waits for the token to circulate around 3 times when participating in the
network in the in-ring startup state. The 3CWT value shall be fixed (3,000 ms).
8.7.11

Acknowledge Waiting Time (AWT)

Message acknowledge Waiting Time (AWT) is a waiting time after the node sends 1 to 1
message until an ACK comes back from the destination node. The AWT value shall be fixed(100 ms).

– 101 –8.7.12JEM1479：2012

Solicitation Frame Batch Transmission Frame Interval (SFBTFI)

Solicitation Frame Batch Transmission Frame Interval (SFBTFI) is a time interval between
frames in case flexible master divides a solicitation frame and transmits to flexible slave when
not in the valid linking state.
The SFBTFI value shall be fixed to 5,000 (microseconds), which is the maximum of the MFT.
8.7.13

Solicitation Frame Transmission Waiting Time (SFTWT)

Solicitation Frame Transmission Waiting Time 2 (SFTWT) is a timer used when flexible mastertransmits a solicitation frame in the valid linking state.
Flexible master holding a token shall transmit a solicitation frame and start the timer when not
all of flexible slaves managed by the self node have participated in the network.
When the SFTWT times out and not all of the slaves managed by the self node haveparticipated in the network, flexible master transmits the solicitation frame again and repeats
the transmission process until all the slaves participate in the network..
When the solicitation frames are divided for transfer, the timer shall be started after thetransmission.
The SFTWT value shall be as follows.
SFTWT = SFTWT = (TDT) + (3CWT) + (PWT)= 3 000＋3 000＋1 200= 7,200 (ms) fixed.
9Operation

9.1

Management of Transmission Right

9.1.1

OutlineAccess control to the FL-net network is performed with a token. A node can perform
transmission basically only when it is holding a token.
A node shall be able to perform transmission without a token only when reissuing a token
when a token is lost, or when transmitting a trigger frame when trying to participate in the
network, a participation request frame, and a solicitation frame at the batch transmission.
―

In the FL-net, one token shall go around among nodes participating in the network. A node shallhold the transmission right over the network after receiving this token until it hands over the token
to the next node. In this process, the time to hold a token shall not exceed the token retention time.

―

The frame which can be transmitted when holding the token shall be two or more cyclic frames,
one or less message frame, or one or less solicitation frame.

―

When the transmission right is released, the token frame shall be transmitted.

―

The token is monitored by the timer of each node and shall be automatically reissued when it has
not gone around the network for a certain period of time.

―

A function to unite tokens is provided when there are two or more tokens in the network.

9.1.2

Flow of Token

A token frame includes a node number of destination side (DNA) of the token and a node
number of source side (SNA) of the token. Each node becomes a token holding node when
the node number of destination side in the received token frame matches the self node
number.
The order of the rotation of a token is determined by the node number. Each nodeparticipating in the network circulates the token in ascending order of the node number. The

– 102 –JEM1479：2012

last node with the maximum node number in ascending order of the node numbers passes thetoken to the node with the minimum node number. The flow of the token shall be as shown in
Figure 83.

Token

Node #1(Minimum node number)

Node #2

Node #3(Token holding node)

Note

Node #4(Next token holding node)

Node #5(Maximum node number): FL-net circuit
Node #n: Node participating in the FL-net (node number =n)

Token: Delivery of the token between nodes: Path of the token

Figure 83 - The flow of a token
9.1.3

Reissuing Token

A token is reissued when both the following two monitor times timed out.
a)Monitor with the refresh cycle measurement time

Each node monitors the time after obtaining a token addressed to the self node until it obtains
a next token addressed to the self node (refresh cycle measurement time).
When this time exceeds the allowable refresh cycle time, time is considerd to be out.
b)

Monitor with the token watchdog time

Monitoring with the token watchdog time shall measure the time after a token last flown in the
network.
When this time exceeds "total token watchdog time of each node from a token holding node to
the self node", time is considered to be out.
When a token frame from a node not participating is received, process is performed with thetoken watchdog time of 255 ms. However, when it is a node which removed, the value when
the node participated is used.
The flow of reissuing a token shall be as shown in Figure 84.

– 103 –JEM1479：2012

d)
f)
a)

Token

b)

c)

e)

g)
Node #1

Node #2

Node #3

Node #4

Node #nNote: FL-net circuit

Node #n: Node participating in the FL-net (node number =n)Node #n: Disengaged node

Token

: Delivery of the token between nodes: Path of the token

a)
b)
c)

Transmit a token from the node #1 to the node #2.
Transmit a token from the node #2 to the node #3.
Since the node #3 has removed from the FL-net, a token is reissued from the node #4 to the node#n.
Transmit a token from the node #n to the node #1.
Transmit a token from the node #1 to the node #2.
Since the node #3 has removed, a token is transmitted from the node #2 to the node #4.
Transmit a token from the node #4 to the node #n. After this, repeat d) to g).

d)
e)
f)
g)

Figure 84 - The flow of reissuing a token
9.1.4

Preventing from Having Two or More Tokens

When a node received a token frame addressed to another node when it is holding a t oken,
the node shall give priority to the one with a smaller node number. In other words, when theself node number is smaller than the node number of destination side in the received frame,
the node shall discard the received token and maintain the status in which the self node isholding the token. To the contrary, when the self node number is larger than the node numberof destination side in the received frame, the node shall discard the token of the self node andchange from the status holding the token to the status waiting for the token.
9.2

Joining and Disengaging Node9.2.1

Joining NodeEach node shall monitor the network until the joining token detection time of each times out
when starting.
At this time, when a node does not detect a token frame, it determi nes to be in the network
startup state, and processes a), and when a node detect a token frame, it determines to be in
the in-ring startup state, and processes b).
a)When a token frame is not received (Network startup state)

The flow of the procedure is shown in a) of Figure 85 when a node starts simultaneously withanother node under the network startup state, and shown in b) of Figure 85 when a node
starts alone under the network startup state.
Each node shall prepare for transmitting a trigger frame if a t oken frame is not detected within
the joining token detection time. The trigger frame is transmitted after trigger frametransmission waiting time (TrWT) (refer to b) in Figure 85). Each node does not transmit aJEM1479：2012– 104 –

trigger frame when it received a trigger frame from another node before transmitting a trigger
frame (refer to a) in Figure 85).
A node waits for all the nodes to transmit participation request frames for the participation
request frame acceptance times (1,200ms) after receiving or transmitting a trigger frame,
while detecting the node numbers, overlap of the common memory area, and updating
participating node management information. Overlap is detected for the area of all theidentified nodes.
A participation request frame shall be transmitted aft er participation request frametransmission waiting time (PWT) has passed from receiving or transmitting a trigger frame.
When the participation request frame acceptance time has passed, the node with theminimum node number shall issue a token first.
The node which identified overlap of the node number with the participation request frame ofanother node does not participate in the network, and perform no transmission or reception.
Error information of node number overlap shall be notified to the upper lay er after setting thenode number overlap flag of the status information of the self node. The node which identified
overlap of the address joins the network, sets the top address of the common memory area 1
and 2 and the common memory size to "0", and does not transmit cyclic data. At this time, theaddress overlap detection flag in the status information of the FA link shall be set, and thecommon memory data validity notice flag shall be reset. Overlap of the node numbers andoverlap of the addresses are detected until the self node receives a token.
When no frame is received before the participation request frame acceptance time times out,
these processes are repeated until a participation request frame or a token frames of otherthan the self node is received. When existence of other nodes has not been identified before
the participation request frame acceptance time times out after retransmitting the participation
request frame 3 times, the receiving waiting status flag of the status information of th e self
node shall be set.

– 105 –JEM1479：2012

Trigger frame transmission waiting time (TrWT)

Participation request frame acceptance time(PAT) (1 200 ms)

Joining token
detection time
(TDT)
(3,000 ms)

Participation request frame transmission waiting time
(PWT)
Time
Receive Receive Transmit Receive

Start monitoring nodesa) An example when starting simultaneously with another node

PAT

TDT

TrWT

PWT

PAT

TDT

TrWT

PWT
Time

Transmit

Transmit

Transmit

Transmit

Start monitoring nodesb) An example when the self node alone is starting
Note: Token frame: Participation request frame: Trigger frame

Figure 85 - Joining at the network startup stateb)

When a token frame is received (in-ring startup state)

The process of joining at the in-ring startup state shall be as shown in Figure 86. When anode detects a token frame within the joining token detection time, it shall determine the linkhas already been established. At this time, the node refrains from transmitting theparticipation request frame until the token goes around 3 times after receiving a token frameto the minimum node number. The node detects overlap of the node numbers and the area inthe common memory addresses with the frames receiv ed in this period, a and updates
participating node management information. Overlap is detected for the areas of all theidentified nodes.
In this case, when there is no overlap of a node number, the node shall transmit a
participation request frame and participate in the network after the participation request frametransmission waiting time has passed. A participation request frame is transmitted whether or
not a token is held.
When a node detects a overlap of a node number, it does not transmit a partici pation request
frame and does not participate in the network. The overlap error of a node number shall be
notified to the upper layer after setting the node number overlap flag of the status information

– 106 –JEM1479：2012of the self node.

When a node detects a overlap of the address, it joins the network, sets the top address ofthe common memory area 1 and 2 and the common memory size to "0", and does not transmit
cyclic data. At this time, the address overlap detection flag of the status information of FA link
shall be set, and the common memory data validity notice flag shall be reset.
Detection of overlap of the node number and overlap of the address is performed when not in
the network.
After joining the network with a participation request frame, when a token frame addr essed tothe self node is not received after waiting for 3 laps, a joining process is performed again. In
addition, when a token frame is not received after transmitting a participation request frame
before the three circulation waiting time passes, the jo ining process is performed again.
Token
circulation(1st lap)

Within the joining token
detection time (TDT)(3rd lap)

1→2

Token
circulation(2nd lap)Token
circulation(3rd lap)

Participation request frametransmission waiting time(PWT)

2→3 3→4

Time
Start monitoring nodes
4→1 1→2 2→3 3→4 4→1

Note: Participation request frame: Token frame

Figure 86 - Participating in the in-ring startup state
9.2.2

Node to be Joined

When a node participating in the network received a participation request frame or when thenode received the last cyclic frame from an unidentified node, each node shall update
participating node management information on the corresponding node.
When updating participating node management inform ation, overlap of the area of thecommon memory shall be detected.
9.2.3

Management of Disengagement

Each node checks the node number of source side each time a token frame is received, andwhen a token frame from a certain node is not received 3 times in succes sion, the node shallbe removed.
When a certain node is considered to have removed from the network, the status of the FA
link within participating node management information shall be changed to the status in which
the node removed. In addition, when other nodes removed during token circulation, and only
the self node is left, the process shall shift to the joining sequence of 9.2.1.
9.2.4

Monitoring Token Addressed to the self NodeEach node monitors the token addressed to the self node. In other words, when th e token
addressed to the self node is not received 3 times in succession on condition that the token isnormally going around in the network, the self node shall be considered to have removed.
After this, the removed node shall shift to the joining sequenc e of 9.2.1 again.

– 107 –9.3

Data Communication between Nodes

9.3.1

Types of Data Communication

JEM1479：2012

The FA link supports two types of data transmission.:―

Cyclic transmission which transmits periodic data―

Message transmission which transmits aperiodic data

9.3.2

Cyclic Transmission

Cyclic transmission shall be as follows.
a)OutlineCyclic transmission is a function for each node to notify other nodes of data in its transmission
area allocated to the common memory by using broadcast.
Cyclic transmission is performed each time the node ho lds the token, and all the data on thecommon memory to be transmitted shall be transmitted.
Nodes participating in the network which does not perform cyclic data transmission are also
allowed.
b)

The amount of data and the number of frames

Cyclic transmission shall divide a frame into two or more frames based on the amount of data
to be transmitted. Therefore, the frame structure of cyclic transmission differs depending on
the amounts of data including the area 1 data and the area 2 data.

– 108 –JEM1479：2012
1)

When the transmission data is 1024 octets or less

When the amount of transmission data including the area 1 and the area 2 does not exceed
1024 octets, the data in the area 1 and the area 2 are combined to be transmitted in one
frame (refer to Figure 87).
Common memory

Area 1

Transmission
data

Cyclic frame
FA link header

Area 1 data

Area 2 data
1024 or less octets

Transmission
data
Area 2

Figure 87 - Frame structure when the transmission data is 1024 or less octets

– 109 –2)

JEM1479：2012

When the transmission data is larger than 1024 octets

When the amount of transmission data including the area 1 and the area 2 is larger than1024 octets, the data shall be divided into two or more frames for transmission. At this time,
the first cyclic frame including all the data of the area 1 and all or part of the data of the area
2 not exceeding 1024 octets in total shall be transmitted. The following frames aretransmitted by 1024 octets until all the data in the transmission area is finished, and only thelast frame has the data size of 1024 or less octets. An example of a frame structure whentransmission data is larger than 1024 octets (the frame structure when dividing into threeframes for transmission) shall be as shown in Figure 88.
Common memory

Area 1

Transmit data

First cyclic frame

FA link header

Area 1 data

Area 2 data
1024 octets

Transmit data

Second cyclic frame
FA link header

Area 2 data
1024 octets

Area 2

Last cyclic frame
FA link header

Area 2 data
1024 or less octets

Figure 88 - Frame structure when the transmission data is larger than 1024 octets
The cyclic frames divided into two or more frames are continuously sent while the node isholding the token.
The divided cyclic frame is added with the information on TBN, CBN, and BSIZE. In addition,
each cyclic frame shall be added with the top address and the size of the common memoryarea 1 and area 2.
The top address and the size of the area 1 and the area 2 are the same as those of eachdivided cyclic frames.
Division and assembly of cyclic frame shall be managed by TBN, CBN, and BSIZE.
A receiving node shall consider whether or not the cyclic frame is divided based on theinformation in the TBN in the header. The receiving node stores divided bl ocks in the buffer
one by one. After all the divided cyclic frames are received, they are written in the common
memory based on the initial address and the size of each of the area 1 and the area 2 in the– 110 –JEM1479：2012

common memory. The node shall discard all the recei ved data from a certain transmission
node at that time when all the cyclic frames divided and sent from the node have not been
received.
9.3.3

Message Transmission

Message transmission shall be as follows.
a)OutlineWhen a node received a token, it can transmit a maximum of 1 message frame before
transmitting cyclic frames.
The amount of data which can be transmitted in one transmission shall be 1024 octets or less(excluding the header).
The message transmission function includes peer to peer transmission which sp ecifies adestination node and 1 to n broadcast for all nodes. The 1 to 1 message transmission
specifies the destination's node number as the node number of destination side, and the 1 ton message transmission sets the node number of destination side to " 255" for transmission.
The receiving node shall consider the message is on the 1 to n message transmission when
the node number of destination side of the received message is "255".
The 1 to 1 message transmission has a function to confirm reception, and t he 1 to n message
transmission does not have a function to confirm reception.
Types of message transmission and the receipt confirmation function shall be shown in Table
19.
Table 19 - The list of the types of message transmission
and the receipt confirmation function
Types of message
1 to 1 message
transmission
1 to n message
transmissionb)

Receipt confirmation(ACK response)

Sequence
numbermanagement

Resending of message
framesAvailable

Available

Available

Not available

Not available

Available

Timing of message transmission

A node can transmit a maximum of one message frame when it obtained a token before
transmitting a cyclic frame based on the conditions indicated below.
1)

When the refresh cycle measurement time (RMT) is 90% or less of the allowable re fresh
cycle time (RCT), one message frame can be transmitted.

2)

When RMT is larger than 90 % of RCT and is smaller than RCT, one message frame canbe transmitted on condition that a message was not transmitted last time.

3)

When RMT is equal to RCT or more, a message frame is not transmitted.

c)Receipt Confirmation (ACK response)

The 1 to 1 message transmission has a function to confirm reception. This function shall be
implemented with the ACK response. The receiving node returns an ACK to the transmission
node in order to inform the transmission node of the message frame having been normallydelivered to the receiving node. The ACK shall be transmitted in the frames for cyclic
transmission. The sequence of receipt confirmation with the ACK shall be as shown in F igure89.

– 111 –Transmission
node

Message 1

Receipt confirmation

ACK 1

JEM1479：2012

Receipt confirmation

Message 2

ACK 2

Receiving node
ACK informs the transmission
node that reception is complete.

Figure 89 - The sequence of receipt confirmation with the ACKd)Resending function

The transmission node shall resend a message frame when the status of the received ACK isabnormal after transmitting the 1 to 1 message frame and when the acknowledge waiting time(AWT) has passed and the ACK has not been receiv ed from the destination node after
transmitting the message frame and before receiving a token addressed to the self node 3
times.
Resending is performed 3 times at most, and when the ACK has not been received from thedestination node of the message frame after resending 3 times, failure of message
transmission is informed to the upper layer.
e)Sequence Number Management

In the 1 to 1 message transmission, messages can be identified and managed by adding thesequence numbers to messages. Receiving nodes shall consider whether or not the message
was resent with the sequence number.
The sequence numbers are managed with two numbers: the version of sequence number andthe sequence number.
1)

Management of the sequence number and the version of sequence number intransmission node

Each transmission node shall have one version of the sequence number. The version of thesequence number shall be created by each node by using time information, random numbers
or random data equivalent to it every time the node starts.
After this, each node shall store and transmit the value of the version of sequence number inthe header of a message frame when transmitting the message.
The sequence number is set in the header of a message frame when transmitting a message.
The sequence number is initialized at start up, and is incremented from the initial value "1."The value of the sequence number is incremented from 1, but 16#FFFF_FFFF shall befollowed by 1.
The sequence number shall be incremented when transmission is normally complet ed, inother words, when the ACK is normally received and the transmitted message frame isconsidered to have been normally received by the receiving node, and when the ACK did not
return when the message was transmitted or when resending failed three time s after
resending in case the status of the ACK are abnormal.
2)

Confirmation of the sequence number and the version of sequence number in thereceiving node

The receiving node shall manage the version of sequence number and the sequence number
for each node. Each node shall initialize all of that management information to "0" before
joining the network.
The receiving node shall register the value as the version of sequence number when the

JEM1479：2012– 112 –

version of sequence number in the header of the received message differ s from the versionof sequence number of the corresponding node. At this time, the message frame is discarded
and the error of the version of sequence number is returned as the status of the ACK. Whenthe managed version of the sequence number is the initi al value"0", the version of sequencenumber in the header of the received message is not checked and the message frame shallbecome valid and the value shall be registered as the version of sequence number.
Then, when the sequence number in the header of t he received message is the same as thesequence number information in the corresponding node, the receiving node identifies it as a
resent message, and the received data is considered to have been processed and is
discarded, but when the message is 1 to 1, the status of the ACK shall be transmitted as
normal reception.
When the sequence number in the header of the message differs from one managed by thereceiving node, the message is identified as a new message and the message data is taken
in, and the sequence number shall be registered.
9.3.4

Token and Data

The frames transmitted when the node is holding a token include the following 9 types (refer
to Figure 90).
a)When there is no cyclic data or message data and all the slaves allocated to flexible
master have participated, after transmitting a cyclic frame without slave data, the token
frame shall be transmitted.

b)

When transmitting cyclic data and when all the slaves allocated to flexible master haveparticipated, after transmitting the cyclic frame, the token frame shall be transmitted.

c)

When dividing and transmitting cyclic data and when all the slaves allocated to flexible
master have participated, the cyclic frame is divided for transmission, and after
transmitting the last cyclic frame, the token frame shal l be transmitted.

d)When the alternate transmission order indicates a message and only message data exist,
message frames are transmitted, and after transmitting cyclic frames without data, thetoken frame shall be transmitted.

e)When the alternate transmission order indicates a message and cyclic data and message
data exist, message frames are transmitted, and after transmitting the cyclic frame, thetoken frame shall be transmitted.

f)When the alternate transmission order indicates a message, and divided cyclic data andmessage data exist, message frames are transmitted, then, cyclic data is divided fortransmission and after transmitting the last cyclic frame, the token frame shall betransmitted.

g)When the alternate transmission order indicates a solicitation f rame, and an
unparticipated slave exists, a solicitation frame is transmitted, then, after transmitting acyclic frame without data, the token frame shall be transmitted.

h)When the alternate transmission order indicates a solicitation frame, an unparticipat ed
slave exists, and cyclic data exists, a solicitation frame is transmitted, after transmitting
the cyclic frame, the token frame shall be transmitted.

i)When the alternate transmission order indicates a solicitation frame, an unparticipatedslave exists, and divided cyclic data exists, a solicitation frame is transmitted, then, cyclic
data is divided for transmission, and after transmitting the last cyclic frame, the token
frame shall be transmitted.

– 113 –Cyclic frame (no cyclic data)a)

JEM1479：2012

Token frameb)Cyclic frame

Token framec)Cyclic framed)Message framee)Message frame

Cyclic framef)Message frame

Cyclic frameg)Solicitation frameh)Solicitation frame

Cyclic framei)Solicitation frame

Cyclic frame

Cyclic frame

Token frame

Cyclic frame (no cyclic data)

Token frame

Token frame

Cyclic frame

Cyclic frame (no cyclic data)

Token frame

Token frame

Token frame

Cyclic frame

Token frame

Figure 90 - Token and data
9.4

Device Level Network

9.4.1

Startup Operation

Start up operation shall be as follows.
a)

MasterStart up operation of the master shall be as follows.
1)

Fixed setting mode

Participates in the network with the start up procedure shown in 9.2.
2)

Flexible setting mode

When all the slaves in accordance with the IO definition have not participated in the network,
the solicitation frames are transmitted by dividing when holding a token.
When all other nodes are flexible slaves at start up, the token does not circulate since a link
is not established. Therefore, solicitation frames are periodically batch transferred (when theparticipation request frame acceptance time has passed after participation request frames
were transmitted).
When all the slaves in accordance with the IO definition particip ate in the network,transmission of the solicitation frames shall be suspended, and when a slave is detected tohave been removed, transmission of the solicitation frames shall be resumed.
b)

Slave

Start up operation of a slave shall be as follows.

JEM1479：2012
1)– 114 –

Fixed setting mode

Participates in the network with the start up procedure shown in 9.2.
2)

Flexible setting mode

Start up by waiting for a solicitation frame.
When the IO definition addressed to the self node is detected when receiving the solicitation
frame, the slave shall set the common memory in accordance with the IO definition, andparticipate in the network with the start up procedure shown in 9.2. The master node number
shall be identified in this process.
When a solicitation frame is received from the same mas ter again after completing setting,
only when the contents have been changed, the status for waiting for the joining token
detection time begins after the area is redefined. When a solicitation frame is received from adifferent master, the solicitation frame shall be discarded. The node shall be reset or the
power supply shall be turned on again to reflect the definition from a different master.
9.4.2

Operation while Establishing a Link

Operation while establishing a link shall be as follows.
a)

MasterOperation while establishing a link of the master shall be as follows.
1)

Fixed setting mode

Output to the slave shall be performed with cyclic frame transmission and input shall bereceived with cyclic frames from a slave.
2)

Flexible setting mode

Output to the slave shall be performed with cyclic frame transmission and input shall bereceived with cyclic frames from a slave.
When all the slaves in accordance with the IO definition have not participated in the network,
the solicitation frames shall be transmitted when holdi ng a token while performing cyclic
frame transmission. For conditions of transmitting solicitation frames, refer to 7.7.
When all the slaves participate in the network, the solicitation frames are not transmitted.
When disengagement of slaves is monitored, and there is no participating slave, thesolicitation frames shall be transmitted when holding a token while performing cyclic frametransmission.
Note
Monitoring of slave disengagement is considered from participating nodemanagement information in the master node. Specifically, whether the numbers and thecommon memory area of the node participating in the network are within the expected range
is checked to monitor disengagement.
b)

Slave

Operation while establishing a link of a slave shall be as follows.
1)

Fixed setting mode

The output to the master shall be performed with cyclic frame transmission and the input
shall be received with cyclic frames from a master. When the master has removed, theoutput shall be held or cleared in accordance with the slave op erating instructions.
2)

Flexible setting mode

The output to the master shall be performed with cyclic frame transmission and the input
shall be received with cyclic frames from a master. When the master has removed, theoutput shall be held or cleared in acc ordance with the slave operating instructions.
After the master has removed, the slave waits the solicitation frames. When the master is– 115 –JEM1479：2012

reconnected, the slave checks the contents of the received solicitation frame and participatesin the network under the in-ring startup state.
9.4.3

Operation with the Multi Master

Operation with the multi master shall be as follows.
a)

MasterOperation of the master shall be as follows when the plural masters participate in the network.
1)

Flexible setting mode

The participation of the slave which the self node manages shall be confirmed with thereception the cyclic frames and the master node number of the status areas in cyclic framefrom the slave.
When the master node number is other node number than the self node, the slave shall beconsiderd to be duplicated.
b)

Slave

Operation of the slave shall be as follows when the plural masters participate in the network.
1)

Flexible setting mode

Overlap check of the area of the common memory, allocation, and identification of the masterstation number shall be performed according to the solicitation frame received first.
When different solicitation frames are received from the same master, only when thecontents have been changed, the status for waiting for the joining token detection time
begins after redefinition.
When solicitation frames from a different master have been received, they shall be discarded.
Note
The same master shall be distinguished in SA of the solicitation frame header format.
The solicitation frame header format shall be des cribed in 10.4.
9.4.4

Operation at Disengagement

Disengagement management shall be based on 9.2.
The master node checks a node number of source side each time it receives a token frame,
and when the token frame from the same node is not received 3 times in succession, the node
shall be considered to have been removed.
When the node is considered to have been removed, the status of the FA link within
participating node management information shall be changed to the status in which the node
has removed. When other nodes left during token circulation, and only the self node is left,
the process shall shift to the joining sequence
The node handling IO input and output performs the following operation.
a)

Master node

Operation when the master removes shall be as follows.
1)

Flexible setting mode

When the removed node is a slave managed by the self node, the solicitation frametransmission waiting time (SFTWT) shall be started.
Solicitation frames are transmitted when the SFTWT times out.
b)

Slave node

Operation when the slave node removes shall be as follows.

– 116 –JEM1479：2012
1)

Flexible setting mode

The slave node removes by monitoring a token addressed to the self node, and the process
shall shift to the joining sequence. When connection is restored, an in -progress participating
sequence shall be performed. When a solicitation frame is received, no process shall be
performed.
When it is reset with a power stoppage, etc., the state for waiting for a solicitation frame
starts, a solicitation frame is received, and the in -progress participating sequence shall be
performed.
9.4.5

Link Establishment Operation

Link establishment operation is as follows.
a)Fixed setting mode

The joining sequence of the fixed setting mode is the same as that of Ver.2.00.
The flow of the joining sequence shall be shown in Figur e 91.

Node #1

Node #2a)

Node #3a)MasterSlavec) remove

Node #4a)

Node #n
b)

Slave

Slave

a)
Slave

d) removea)

Establishes a link by simultaneously starting sequence of two or more nodes.

b)

Establish a link of a slave joining in progress and a master joining in progress with an in-progress
participating sequencec)When the master removes, a slave performs cyclic transmission as usual.

d)When the slave removes, the master performs cyclic transmission, and the status of the FA link within
participating node management information is changed to the status in which the node left.
Trigger frametransmission
waiting time
(TrWT)

Participation request frame
acceptance time (PAT) (1,200 ms)
Participation request frametransmission waiting time (PWT)

Joining token
detection time(TDT)
3 000 ms

TDT

Receive Receive
Receive
Transmit
Start monitoring nodes: Token frame: Participation
requestframe

PWT

Start monitoring a node joining inprogress: Triggertransmission
frame

Figure 91 - Joining sequence of the fixed setting mode

Transmit: 1 lap of a token

– 117 –b)

JEM1479：2012

Flexible setting mode (When there is one flexible master)Flexible master shall transmit a solicitation frame to a slave after ending the joining sequence.
Flexible slave shall perform the joining sequence after receiving the solicitation frame fromflexible master. For details of the joining sequence, refer to 9.2. The flow of the joining
sequence shall be as shown in Figure 92.

c)a)Node #1 b)
Master d)

Node #2 d)

Node #3 d)

Node #4

Slave

Slave

Slave

Node #n d)

d)

Slave

: Solicitation framea)Without a tokenb)

The participation request frame acceptance time times out after a participation request frame istransmittedc)Transmit a solicitation framed)All nodes simultaneously establish links with a link participating sequence

Participation request frame
acceptance time (PAT) (1,200 ms)
Participation request frametransmission waiting time (PWT)
Joining token
detection time(TDT)
3 000 ms

Trigger frametransmission
waiting time
(TrWT)TrWT
TDT
SFBTFIPAT
PWT

Transmit a solicitation frame

Start monitoring nodes

Transmit a participation request frame
Transmit a trigger frame: Token frame: Participation
request frame: Triggertransmission
frame: Solicitation frame

Figure 92 - The joining sequence of the flexible setting mode
(when there is one flexible master)c)Flexible setting mode (when there is one flexible master and nodes other thanflexible slave coexist)

Flexible master shall transmit a solicitation frame to a slave after ending the joining sequence.
Flexible slave shall perform the joining sequence after receiving the solicitation frame fromflexible master. Nodes other than flexible slave shall discard solicitation frames. For details of
the joining sequence, refer to 9.2. The flow of the joining sequence shall be as shown in
Figure 93.

– 118 –JEM1479：2012b)

No process

Node #1a)

Master

Node #2

Node #3

c)

Slave

Slave

c)

Node #4

Node #na)
Except flexible slave

c)

Slave

: Solicitation framea)Establish a link with the simultaneous starting sequence of the node #1 and the node #4.

b)Transmit solicitation frames when the node #1 is holding the token.
the SFTWT is up until all the slaves have joined.

c)

A slave establishes a link with an in-progress participating sequence.

Transmit solicitation frames when

TrWT
PAT

TDT

PWT

TDT

Start monitoring nodes

Transmit a solicitation frame
Start monitoring a node joining in progress

PWT: Token frame: Participation
request frame: Triggertransmission frame: Solicitation frame: 1 lap of a token

Figure 93 - The joining sequence of the flexible setting mode
(when there is one flexible master and nodes other than flexible slave coexist)

– 119 –d)

JEM1479：2012

Flexible setting mode (in the case of two or more flexible masters)

Flexible master shall transmit a solicitation frame to a slave after ending the joining sequence.
Flexible slave shall perform the joining sequence after receiving the solicitation frame fromflexible master. Nodes other than flexible slave shall discard solicitation frames. Flexible
master shall discard solicitation frames from other flexible masters. For details of the joining
sequence, refer to 9.2. The flow of the joining sequence shall be as shown in Figure 94.

No process

No process

No process
No processprocess
Node #1a)

Master 1

Node #2

Node #3d)Slave 1c)

No process No process
Node #4d)

Except flexible slave

Node #na)

Master 2d)Slave 2

: Solicitation framea)Establish a link with a simultaneous starting sequence of the node #1, the node #3, and the node #4.

b)Transmit solicitation frames when the node #1 is holding the token.
the SFTWT times out until all the slaves join.

Transmit solicitation frames whenc)Transmit solicitation frames when the node #4 is holding the token.
the SFTWT times out until all the slaves join.

Transmit solicitation frames whend)

A slave establishes a link with an in-progress participating sequence.

Slave 2 TDT
TrWT
PAT

Slave 1 TDT

PWT

TDT

Start monitoring nodes
Slave 2 PWTTransmit
solicitation frame(Master 1)

Transmit solicitation frame (Master 2)
Start monitoring the slave 2

Slave 1 PWTStart monitoring the slave 1: Token frame: Participation
request frame: Triggertransmission frame: Solicitationframe: 1 lap of a token

Figure 94 - The joining sequence of the flexible setting mode
(when there are two or more flexible masters)

– 120 –JEM1479：2012e)Flexible master and flexible slave participating in progress while establishing a link

Flexible master shall transmit solicitation frames to the slave after ending the joining
sequence. Flexible slave shall perform the joining sequence after receiving the solicitation
frame from flexible master.
Nodes other than flexible slave shall discard solicitation frames. For details of the joining
sequence, refer to 9.2. The flow of the joining sequence shall be shown in Figure 95.

No process

No process

No processb)

No process

No process

Node #1a)c)

Master

Node #2 c)

Node #3 c)

Node #4

Slave 1-1

Slave 1-2

Master2

Node #n d)g)Slave 2e)f)g)

: Solicitation framea)Without a tokenb)Transmit solicitation frame when the participation request frame acceptance time times out after
transmitting participation request frames.

c)

The master 1, the slave 1-1, and the slave 1-2 nodes shall simultaneously establish links with a linkparticipating sequence.

d)Connection of the slave 2 starts the status to wait for in-progress participation.

e)

Establish a link with the in-progress participating sequence when the master 2 is connected.

f)Transmit solicitation frames when the master 2 is holding a token.

g)

A slave shall establish a link with an in-progress participating sequence.
TrWT
PAT

PAT

TDT
TDT

TrWT

PWT

Start monitoring the master 1
nodeTransmit a trigger
frame
Master 2 TDT

Master 2 PWTStart monitoring the master 2
node: Token frame: Participation
request frame

PWT

MFT MFT MFT

Transmit a solicitation frame
Transmit a participation request frame
Slave 2 PWT

Slave 2 TDTStart monitoring the slave 2: Triggertransmission frame: Solicitationframe: 1 lap of a token

Figure 95 - Joining sequence of flexible master and flexible slave participating
in progress while establishing a link– 121 –9.4.6

JEM1479：2012

Operation in Abnormal Setting of IO Allocation of any Slave

Abnormalities in the IO allocation of flexible slave include two cases: when flexible masterdetects it due to wrong settings of flexible master with a setting tool etc. and when the slav edetects it due to wrong settings with the solicitation frame from flexible master.
a)

The abnormalities in IO allocation

The abnormalities in IO allocation shall be as follows.
1)

Abnormal slave node number

Flexible master sets the IO allocation response to be "Abnormal slave node number",discards the IO allocation information, and do not transmit a solicitation frame when thesetting value of the slave node number part is not in the range from 1 to 249 when the IO
allocation setting frame is received.
Flexible slave shall discard the IO allocation information about the slave when the slave node
number out of range is detected when solicitation frames are received.
2)

Abnormal address

Flexible master sets the IO allocation response to be "Abnormal slave common mem ory
address", discards the IO allocation information, and do not transmit a solicitation frame
when the common memory address value of flexible slave is not in the range of the common
memory area when then IO allocation setting frame is received. Flexible slave does notparticipate in the network when the common memory address exceeds the range when asolicitation frame is received.
3)

Abnormal size

Flexible master sets the IO allocation response to be "Abnormal slave common memory size",discards the IO allocation information, and do not transmit a solicitation frame when thecommon memory size of flexible slave is not in the range of the common memory area whenthe IO allocation setting frame is received.
Flexible slave does not participate in the network wh en the common memory size exceeds
the range when a solicitation frame is received.
b)

Receiving solicitation frames

When the solicitation frame addressed to the self node is received by a node other thanflexible slave, it shall be discarded.
c)Overlap of solicitation frames

When flexible slave received solicitation frames from two or more masters, the IO allocation
information received first is used.
d)Double definition of a slave

When the solicitation frame of one master has two definitions of the same slave, th e second
IO allocation information is used.
10 FA Link Frame Format
10.1 Header Format
An FA link header has the size from 64 to 96 octets. The configuration of the FA link frame
shall be as shown in Figure 96.

– 122 –JEM1479：2012

64 to 96 octets

1024 or less octets

FA link header

Cyclic/message data

Lower layer header

FA link data
1,500 or less octets

Figure 96 - The configuration of the FA link frame
The basic structure of the FA link header shall be as follows. The FA link header is added tothe beginning of all the frames in the FA link protocol. In addition, the address of the header isa data position flowing in the network. The bit positions are also written in the order to flow in
the network in the same manner.
10.1.1The Basic Structure of the FA Link Header

The basic structure of the FA link header shall be shown in Figure 97, and the base items inTable 20.
031

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32
36
40
44
48
52
56
60

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA
DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL
M_SZ

ULS

M_ADD
M_RLT
reserved
VER
TCD
C_AD1
C_SZ1
C_AD2
C_SZ2
MODE
P_TYPE
PRI

MFT

CBN
LKS

TBN
TW

BSIZE
RCT

M_CTL
0

7 8
16#00

15 16
23 24
31
16#00
16#00

0
1
2
3
24
31
BCT PPT
0 RPL
reserved

Figure 97 - Basic structure of the FA link header

4
0

5
6
0
0
reserved

70

– 123 –JEM1479：2012

Table 20 - The base items of the FA link header
SymbolH_TYPE
TFL

Size (Octet)
4
4

Items
Header type
Octet length including the header and data

SNA
DNA
V_SEQ
SEQ

1
1
4
4

BCT
PPT
RPL
ULS

1 bit
1 bit
1 bit
2

M_SZ
M_ADD
MFT
M_RLT

2
4
1
1

Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Existence of ACK data
Upper layer status(RUN/STOP/ALARM/WARNING/NORMAL)
Message data size in virtual address space
Offset address of the virtual address space
Allowable minimum frame interval time
Message result (Normal, Abnormal)

TCD
VER
C_AD1
C_SZ1
C_AD2
C_SZ2
MODE

2
2
2
2
2
2
2

P_TYPE
PRI
CBN
TBN
BSIZE
LKS
TW
RCT

1
1
1
1
2
1
1
2

Transaction code
Program version
Common area 1 datatop address
Common memory area 1 data size
Common area 2 datatop address
Common memory area 2 data size
FA link protocol version (major version, minor
version), token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)
Link status (FA link status)
Token watchdog time
Allowable refresh cycle time

Setting value
FACN: FL-net
Octet lengths shall be stored in the
2 octets of 16-31, and 0-15 shall be
16#0000.
─
─
─
─
─
─
─
─
─
─
─
Response message
0: Normal, 1: Abnormal, 2: Not
implemented─- Fixed to 16#0000
─
─
─
─
─
- Fixed to 16#80- Fixed to 16#00
─
─
─
─
─
─

– 124 –JEM1479：2012

The basic structure of the FA link header shall be as follows.
a)

ULS

The data of ULS indicates the upper layer status and includes 1 bit of RUN/STOP, Reserved,
WARNING, ALARM, and a 12-bit code (refer to Figure 98).
The upper layer status is defined with 16 bits.
0

1

2

3

4

5

6

7

8

9 10 11 12 13 14

150
U_ERR_CODE
Defined in the upper layer.

Reserved
WARNING
0: No error
1: Error

ALARM
0: No error
1: Error

RUN/STOP
0：STOP
1：RUN

Note The definition of U_ERR_CODE (upper layer error code) is determined by the vendor. Refer

to 7.3.6.
Figure 98 - Data of ULSb)LKS

The data of LKS indicates the status of the network FA link (refer to Figure 99). The status of
the link is defined with 8 bits.
0

1

2

3

0

0

0

0

4

5

6

7

reserved
Upper layer operation signal error
0: No error
1: Error

Common memory data valid notification
0: Common memory data invalid
1: Common memory data valid

Common memory (address size)
Setting complete
0: Common memory data setting not complete
1: Common memory data setting complete

Address overlap detection
0: No error
1: Error

Note Refer to 7.3.6.

Figure 99 - Data of LKS

– 125 –c)

JEM1479：2012

TCD

The list of TCD shall be shown in Table 21.
Table 21 – List of TDC
Transaction codes

Frames1

0 to 9 999(Reserved)

2

10 000 to 59 999

Transparent message frame

3

60 000 to 64 999(Reserved)

4

65 000Token frame

565 001

Cyclic frame

665 002

Participation request frame

7

65 003

Byte block read frame (request)

8

65 004

Byte block write frame (request)

965 005

Word block read frame (request)

10

65 006

Word block write frame (request)

11

65 007

Network parameter read frame (request)

12

65 008

Network parameter write frame (request)

13

65 009Stop command frame (request)

14

65 010Operation command frame (request)

15

65 011

Profile read frame (request)

16

65 012

Trigger frame

17

65 013Log data read frame (request)

18

65 014

Log data clear frame (request)

19

65 015

Message return frame (request)

20

65 016

Vendor specific message frame (request)

21

65 017

Solicitation frame (broadcast)

22

65 018

IO allocation setting frame (request)

23

65 019IO allocation read frame (request)

24

65 020Start frame of token retention time measurement (request)

25

65 021

End frame of token retention time measurement (request)

26

65 022Start frame of measurement in general purpose communication
data sender log (request)

27

65 023

End frame of measurement in general purpose communication
data sender log (request)

28

65 024

Configuration parameter setting frame (request)

29

65 025

Participating node management information parameter readframe (request)

30

65 026

Read frame of self node management information parameter(request)

31

65 027

Self node setting information parameter read frame (request)

32

65 028Node reset frame (request)

33

65 029 to 65 202(Reserved) (for future extension)34

65 203

Byte block read frame (response)35

65 204

Byte block write frame (response)36

65 205

Word block read frame (response)37

65 206

Word block write frame (response)38

65 207

Network parameter read frame (response)39

65 208

Network parameter write frame (response)

– 126 –JEM1479：2012

Table 21 – List of TDC (continued)
Transaction codesd)

Frames40

65 209Stop command frame (response)41

65 210Operation command frame (response)42

65 211

Profile read frame (response)43

65 212(Reserved)

44

65 213Log data read frame (response)45

65 214

Log data clear frame (response)46

65 215

Message return frame (response)47

65 216

Vendor specific message frame (response)48

65 217(Reserved)49

65 218

IO allocation setting frame (response)50

65 219IO allocation read frame (response)51

65 220Start frame of token retention time measurement (response)52

65 221

End frame of token retention time measurement (response)53

65 222Start frame of measurement in general purpose communication
data sender log (response)54

65 223

End frame of measurement in general purpose communication
data sender log (response)55

65 224

Configuration parameter setting frame (response)56

65 225

Read frame of participating node management information
parameter (response)57

65 226

Read frame of self node management information parameter(response)58

65 227

Self node setting information parameter read frame (response)59

65 228Node reset frame (response)60

65 229 to 65 399(Reserved) (for future extension)

61

65 400 to 65 535(Reserved)

TFL

The data of the TFL indicates the octet length including the header and the data part before
dividing each frame.
Participation request frame: Indicates the octet length of the header 16#0000_0060(96)Trigger frame: Indicates the octet length of the header 16#0000_0060(96)Token frame: Indicates the octet length of the header 16#0000_0040(64)Message frame: Indicates the octet length including the header and data part
Cyclic frame: Indicates the octet length including the header and the data part before being
divided [(the size of the area 1 + the size of the area 2) x 2].
TFL includes the data length of ACK.
e)

M_RLT

M_RLT at a response frame shall be as follows.
1)

16#00: Normal response2)

16#01: Abnormal response

Indicates that the parameter of the message has a certain error although the requested
message is implemented. At this time, an error code shall be set to the data part. This code
can be arbitrarily defined by a vendor.

– 127 –3)

JEM1479：2012

16#02: Unimplemented response

Indicates the processing function for the requested message is not implemented. At this time,
the size of the data part shall be 0.
f)

BSIZE

BSIZE indicates the data size including the header of each frame. BSIZE shall include thedata length of an ACK. When it is not divided, the value of TFL and BSIZE shall be the same(as is the case with an ACK).
g)

SNA

SNA shall set the node number of the source side in all the frames.
h)DNADNA of each frame shall set the following values:
Token frame: The node number of the destination to which to pass a token
Cyclic frame: The node number of the destination to which to pass a token
Participation request frame and trigger frame: 16#FF
1 to 1 message: Node number of destination side
1 to n message: 16#FF
i)

MODE

The data of MODE indicates the FA link protocol version (the major version and the minor
version), and the status of the token mode (refer to Figure 100).
0

1

2

3

0

0

0

0

4

5

6

7

8

9 10 11 12 13 14 15
0

0

0

1
Reserved
Minor version
0 to 15: Minor version

Major version
0：Ver.1.00
2：Ver.2.00
3：Ver.3.00
Token mode
1: Fixed

Figure 100 - Data of MODE

– 128 –JEM1479：2012
10.1.2

Token Header

The format of the token header shall be shown in Figure 101 and the items of the token
header shall be shown in Table 22.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SEQ(Not used)
M_CTL

36
40
44
48
52
56
60

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

ULS
MFT

M_SZ(Not used)
M_ADD(Not used)reserved
M_RLT(Not used)

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

TCD
C_AD1
C_AD2
MODE
CBN
TBN
LKS
TW

VER
C_SZ1
C_SZ2
P_TYPE
PRI
BSIZE
RCT

M_CTL
0

7 8

15 16
23 24
31
16#00
16#00
16#00

0
1
2
3
24
31 RPLBCT PPT0
reserved
Not used

Figure 101 - The format of the token header

4
0

5
6
0
0
reserved
Not used70

– 129 –JEM1479：2012

Table 22 - The items of a token header
Symbols

Size (Octet)

H_TYPE

4

Header type

Items

FACN: FL-net

Setting values

TFL

4

Octet length including the header and data

Fixed to 16#0000_0040

SNA

1

Node number of source side

─

DNA

1

Node number of destination side

─

V_SEQ

4

Version of sequence number

─

ULS

2

Upper layer status(RUN/STOP/ALARM/WARNING/NORMAL)

─

MFT

1

Allowable minimum frame interval time

TCD

2Transaction code

Fixed to 16#FDE8VER

2Program version

Fixed to 16#0000

C_AD1

2

Common area 1 datatop address

─

C_SZ1

2

Common memory area 1 data size

─

C_AD2

2

Common area 2 datatop address

─

C_SZ2

2

Common memory area 2 data size

─

MODE

2

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

P_TYPE1

Protocol type

Fixed to 16#80

PRI

1

Message priority

Fixed to 16#00

CBN

1

Current fragment block number

Fixed to 16#01

TBN

1

Total fragment block number

Fixed to 16#01

BSIZE

2

Current block size (octet)

Fixed to 16#0040

LKS

1

Link status (FA link status)

─

TW

1

Token watchdog time

─

RCT

2

Allowable refresh cycle time──– 130 –JEM1479：2012
10.1.3Cyclic Header

When there is an ACK to transmit, RPL flag shall be set and the ACK data to be mentioned
later shall be added between the header and the cyclic data.
The format of a cyclic header shall be shown in Figure 102, and the items of the cyclic header
shall be shown in Table 23.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

SEQ(Not used)
M_CTL
ULS
M_SZ(Not used)
M_ADD(Not used)
MFT

36

VER
C_SZ1
C_SZ2
P_TYPE
PRI

TCD
C_AD1
C_AD2
MODE

40
44
48
52
56
60

CBN
LKS

reserved

M_RLT(Not used)

TBN
TW

BSIZE
RCT

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

M_CTL
0

7 8
16#00

0
1
24
BCT PPT

15 16
23 24
31
16#00
16#00

2
3
31 RPL04
0reserved
Not Used5600reserved

70Figure 102 - The format of a cyclic header

Table 23 - The items of a cyclic header
Symbols

Size (Octet)

Items

Setting values

H_TYPE

4

Header type

FACN: FL-net

TFL

4

Octet length including the header and data

Octet lengths shall be stored in the 2octets of 16 to 31, and 0 to 15 shall be
16#0000.

SNA

1

Node number of source side

─

DNA

1

Node number of destination side

─

V_SEQ

4

Version of sequence number

RPL

1 bit

Existence of ACK data

ULS

2Upper layer status(RUN/STOP/ALARM/WARNING/NORMAL)

MFT

1Allowable minimum frame interval time

TCD

2Transaction code

Fixed to 16#FDE9VER

2Program version

Fixed to 16#0000

C_AD1

2

Common area 1 datatop address

─

C_SZ1

2

Common memory area 1 data size

─

C_AD2

2

Common area 2 datatop address

─

C_SZ2

2

Common memory area 2 data size

─

MODE

2

FA link protocol version (major version, minor
version), token mode──When there is ACK data: 1──

– 131 –JEM1479：2012

Table 23 - The items of a cyclic header (Continued)
Symbols

Size (Octet)

P_TYPE1

Protocol type

Fixed to 16#80

PRI

1

Message priority

Fixed to 16#00

CBN

1

Current fragment block number

─

TBN

1

Total fragment block number

─

BSIZE

2

Current block size (octet)

─

LKS

1

Link status (FA link status)

─

TW

1

Token watchdog time

─

RCT

2

Allowable refresh cycle time─

10.1.4

Items

Setting values

Message Header

The message header shall be as follows.
a)

In the case of a message that uses the virtual address space

The virtual address space is used in the byte block read/write service and in the word block
read/write service among the services of the message. The format of the message header
using the virtual address space shall be shown in Figure 103 and the items of the message
header using the virtual address space shall be shown in Table 24.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SEQ
M_CTL

VER
TCD
C_AD1(Not used)
C_SZ1(Not used)
C_AD2(Not used)
C_SZ2(Not used)
MODE
P_TYPE
PRI
CBN
TBN
BSIZE
RCT(Not used)
LKS
TW
(Not
used)
(Not
used)
60
40
44
48
52
56

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

ULS(Not used)

MFT
36 (Not used)

M_SZ
M_ADD
reserved
M_RLT

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

M_CTL
0

7 8
16#00

0
1
24
BCT PPT

15 16
23 24
31
16#00
16#00

2
3
31
0 RPL

reserved

4
0

5
0

6
0

7
0

reserved
Not used

Figure 103 - The format of the message header that uses the virtual address space

– 132 –JEM1479：2012

Table 24 - The items of the message header that uses the virtual address space
Symbols

Size (Octet)

H_TYPE

4

Header type

Items

FACN: FL-net

Setting values

TFL

4

Octet length including the header and data

Octet lengths shall be stored in the 2octets of 16 to 31, and 0 to 15 shall be
16#0000.

SNA

1

Node number of source side

─

DNA

1

Node number of destination side

─

V_SEQ

4

Version of sequence number

─

SEQ

4

Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.

─

BCT

1 bit

Broadcast transmission

1 at 1 to n transmission

PPT

1 bit

Peer to peer transmission

1 at 1 to 1 transmission

M_SZ

2

Message data size in virtual address space

M_ADD

4

Offset address of the virtual address space

M_RLT

1

Message result (Normal, Abnormal)

Response message
0: Normal, 1: Abnormal, 2: Not
implemented

TCD

2Transaction code

The header type of the FL-net

VER

2

Program version

Fixed to 16#0000

MODE

2

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

P_TYPE1

Protocol type

Fixed to 16#80

PRI

1

Message priority

Fixed to 16#00

CBN

1

Current fragment block number

Fixed to 16#01

TBN

1

Total fragment block number

Fixed to 16#01

BSIZE

2

Current block size (octet)

─
─

─

─

– 133 –b)

JEM1479：2012

In the case of a message which does not use the virtual address space

The format of a message header which does not use the virtual address space shall be shownin Figure 104 and the items of a message header which does not use the virtual address
space shall be shown in Table 25.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA
DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS(Not used)
M_SZ(Not used)
M_ADD(Not used)reserved
M_RLT
MFT
36 (Not used)
VER
40
TCD
C_AD1(Notused)
C_SZ1(Notused)
44
C_SZ2(Not used)
48 C_AD2(Not used)
MODE
P_TYPE
52
PRI

M_CTL
0

56

CBN
TBN
BSIZE
RCT(Not used)
LKS
TW
60 (Not used) (Not used)

7 8
16#00

0
1
24
BCT PPT

15 16
23 24
31
16#00
16#00

2
3
31
0 RPL

reserved

4
0

5
0

6
0

7
0

reserved

Not used

Figure 104 - The format of a message header
which does not use the virtual address space
Table 25 - The items of a message header which does not use the virtual address space
Symbols

Size (Octet)

H_TYPE

4

Header type

Items

FACN: FL-net

Setting values

TFL

4

Octet length including the header and data

Octet lengths shall be stored in the 2octets of 16 to 31, and 0 to 15 shallbe 16#0000.

SNA

1

Node number of source side

─

DNA

1

Node number of destination side

─

V_SEQ

4

Version of sequence number

─

SEQ

4

Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.

─

BCT

1bit

Broadcast transmission

1 at 1 to n transmission

PPT

1bit

Peer to peer transmission

1 at 1 to 1 transmission

M_RLT

1

Message result (Normal, Abnormal)

Response message
0: Normal, 1: Abnormal, 2: Not
implemented

TCD

2Transaction code

The header type of the FL-net

VER

2

Program version

Fixed to 16#0000

MODE

2

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

P_TYPE1

Protocol type

Fixed to 16#80

PRI

1

Message priority

Fixed to 16#00

CBN

1

Current fragment block number

Fixed to 16#01

TBN

1

Total fragment block number

Fixed to 16#01

BSIZE

2

Current block size (octet)──

– 134 –JEM1479：2012c)

In the case of a vendor specific message

The format of a vendor specific message header shall be shown in Figure 105 and the itemsof a vendor specific message shall be shown in Table 26.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SEQ
M_CTL

ULS(Not used)
M_SZ(Not used)
M_ADD(Not used)
MFT
reserved
M_RLT
(Not
used)
36
VER
TCD
40
C_AD1(Notused)
C_SZ1(Notused)
44
C_AD2(Notused)
C_SZ2(Not
used)
48
MODE
P_TYPE
PRI
52
CBN
TBN
BSIZE
LKS
TW
RCT(Not used)
60 (Not used) (Not used)
64
VDN
68
72
76
SCODE
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA
DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0 RPL
31

reserved

4
0

5
6
0
0
reserved(Not used)

70

Figure 105 - The format of a vendor specific message header
Table 26 - The items of a vendor specific message header
Symbols
H_TYPE
TFL

Size (Octet)
4
4

SNA
DNA
V_SEQ
SEQ

1
1
4
4

BCT
PPT
M_RLT

1bit
1bit
1

TCD
VER
MODE

2
2
2

P_TYPE
PRI
CBN
TBN
BSIZE
VDN
SCODE

1
1
1
1
2
10
6

Items
Header type
Octet length including the header and data

Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

Transaction code
Program version
FA link protocol version (major version, minor
version), token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)
Vendor nameSubcodeSetting values
FACN: FL-net
Octet lengths shall be stored in the 2octets of 16 to 31, and 0 to 15 shallbe 16#0000.
────

1 at 1 to n transmission
1 at 1 to 1 transmission
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
The header type of the FL-net
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
──
Code managed by a vendor

– 135 –10.1.5

JEM1479：2012

Participation Request Frame Header and Trigger Frame Header

The format of a participation request frame header and a trigger frame header shall be shownin Figure 106 and the items of the participation request frame header and the trigger frame
header shall be shown in Table 27.
0
0
4
8
12
16
20
24
28
32
36
40
44
48
52

31
H_TYPE
TFL
SA
DA
V_SEQ
SEQ(Not used)
M_CTL(Not used)
ULS(Not used)
M_SZ(Not used)
M_ADD(Not used)reserved
M_RLT
MFT(Not used)

SA
0

7 8
16#00

15 16
23 24
31
16#01
16#00
SNA

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

VER
TCD
C_SZ1
C_AD1
C_SZ2
C_AD2
P_TYPE
MODE
PRI
CBN
TBN
BSIZE
56 (Not used) (Not used)
LKS
RCT
TW
(Not used)(Not used)
60
64
NDN
68
72
76
VDN
80
MSN
84
88
reserved
92

Figure 106 - The format of a participation request frame header
and a trigger frame header

– 136 –JEM1479：2012

Table 27 - The items of a participation request frame header and a trigger frame header
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
MFT
TCD
VER
C_AD1
C_SZ1
C_AD2
C_SZ2
MODE

Size (Octet)
4
4
1
1
4
1
2
2
2
2
2
2
2

P_TYPE
PRI
BSIZE
TW
NDN

1
1
2
1
10

VDN
MSN

10
10

Items
Header type
Octet length of a header
Node number of source side
Node number of destination side
Version of sequence number
Allowable minimum frame interval time
Transaction code
Program version
Common area 1 datatop address
Common memory area 1 data size
Common area 2 datatop address
Common memory area 2 data size
FA link protocol version (major version, minor
version), token mode
Protocol typeMessage priority
Current block size (octet)
Token watchdog time
Node information: Node name of node
information
Node information: Vendor name
Node information: Manufacturer model nameof node information

Setting values
FACN: FL-net
Fixed to 16#0000_0060
────The header type of the FL-net
Fixed to 16#0000
─
─
─
─
─
Fixed to 16#80
Fixed to 16#00
Fixed to 16#0060
────

10.2 ACK Data
The ACK data shall be as follows.
a)

Basic specification

ACK by message transmission is transmitted when performing cyclic transmission.
The ACK data which is a collection of ACK is added between the cyclic header and the cyclic
data in cyclic transmission.
When the cyclic data is divided for transmission, the ACK data is attached to the last one ofthe divided frames for transmission. The location of the ACK data during transmission shall be
as shown in Figure 107.
Without ACK data
Cyclic header

Cyclic data

With ACK data
Cyclic header

ACK data

Cyclic data

Figure 107 - The location of ACK data during transmission
The size of ACK data shall be of variable length and from 20 to 132 octets. The number of
ACKs which can be transmitted in one cyclic transmission is up to 8.
b)

ACK data

The format of ACK data shall be shown in Figure 108 and the ACK dat a items shall be shownin Table 28.

– 137 –

0
0
4
8

7 8

15

JEM1479：2012

16

23

24

31

A_VER

A_NUM

reserved

reserved

R_STS1

R_TCD1

16#00

16#01

R_NA1

16#00

R_VSEQ1

12

R_SEQ11620
24

reserved

R_STS2

16#00

16#01

R_TCD2
16#00

R_NA2

R_VSEQ2

28

R_SEQ232
3640

reserved

R_STS3

16#00

16#01

R_TCD3
16#00

R_NA3

R_VSEQ3

44

R_SEQ3

48

116
120

reserved

R_STS8

16#00

16#01

R_TCD8
16#00

R_NA8

R_VSEQ8124

R_SEQ8128

Note This figure assumes there are 8 ACKs. ACK data shall change its size by 16 octets.

Figure 108 - The format of ACK data

Table 28 - ACK data items
Symbols

Size (Octet)

Items

Setting values

A_VER

1

The version of ACK data

Fixed to 16#00

A_NUM

1

The number of ACKs (maximum of 8)

─

R_STSx1

Returns the status flag, an error, etc. of ACK─

R_TCDx2

TCD of the message corresponding to ACK to betransmitted

R_NAx

1

The node number of destination side of ACK─

R_VSEQx

4

The version of sequence number received

─

R_SEQx4

The sequence number received

─Received TCD

The meaning of the value of R_STSx shall be as follows.
―

16#01 indicates that a response node normally received the message.

―

16#02 indicates that the receive buffer for the messages of the response node is full.

―

16#03 indicates that initialization of the message reception process of the response node has notbeen finished.

―

16#05 indicates that the response node detected an error in the version of sequence number.

―

16#06 indicates that the response node detected an abnormal format.

– 138 –JEM1479：2012―

16#10 indicates that there is no ACK from the request node and that the request node detected a
reception timeout.

―

16#14 indicates that the request node detected the sequence number error of ACK.

―

16#15 indicates that the request node detected an error in the version of sequence number of
ACK.

Notes R_STSx values of 16#10,16#14 and 16#15 shall be detected at a request node, andnot used in the ACK data.
10.3 User Data
10.3.1

Cyclic Data

The format of a cyclic frame at cyclic transmission shall be as shown in Figure 109. In frames
at cyclic transmission, data shall be written and transmitted in the order of the area 1 and thearea 2. When there is ACK data, it shall be inserted after the cyclic header.
When the cyclic data is larger than 1024 octets, it shall be divided into two or more frames fortransmission. The first one of the divided frames is written with the data in the area 1 and thearea 2, and the second one and the followings are written wit h the data of the area 2.
Without ACK data
Cyclic header

Area 1

Area 2

ACK data

Area 1

With ACK data
Cyclic header

Area 1Figure 109 - The format of a cyclic frame
10.3.2Message Data

The format of the message frame for message transmission shall be as shown in Figure 110.

Message header

Message data

Figure 110 - The format of a message frame

– 139 –JEM1479：2012

Message data shall be as follows.
a)

Byte block readThe data part of the byte block read shall be shown in Table 29.
Table 29 - The data part of the byte block read
Items
RequestNormal response(M_RLT＝0)

Contents of data partNot available
7
Offset +00

Read data
Any size at the maximum of 1024 octets is acceptable.

+1+2

Abnormal response(M_RLT＝1)

Offset +0

7

+1
+2

Unimplemented response(M_RLT＝2)b)0

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is acceptable.

Not available

Byte block write

The data part of the byte block write shall be shown in Table 30.
Table 30 - The data part of byte block write
Items
RequestContents of data part
0

7
Offset +0

Read data
Any size at the maximum of 1024 octets is acceptable.

+1+2

Normal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Not available+1+2

Unimplemented response(M_RLT＝2)0

7
Offset +0

Not available

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is acceptable.

– 140 –JEM1479：2012c)

Word block readThe data part of word block write shall be shown in Table 31.
Table 31 - The data part of word block read
Items
RequestNormal response(M_RLT＝0)

Contents of data partNot available
15
+1
+2

Abnormal response(M_RLT＝1)

Offset +0+1+2

Unimplemented response(M_RLT＝2)d)0Offset +0

Read data
Any size at the maximum of 1024 octets is
acceptable.
150Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Not available

Word block write

The data part of word block write shall be shown in Table 32.
Table 32 - The data part of word block write
Items

Contents of data part

Request15
Offset +0+1+2

Normal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Not available
15
Offset +0+1+2

Unimplemented response(M_RLT＝2)0

Read data
Any size at the maximum of 1024 octets is
acceptable.

Not available

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

0

– 141 –e)

JEM1479：2012

Network parameter readThe data part of network parameter read shall be shown in Table 33.
Table 33 - The data part of network parameter read
Items
RequestNormal response(M_RLT＝0)

Contents of data partNot available
0ffset

+0 15

+4
+5

Vendor name+9
+10

Manufacturer model name of node information

+14
+15
+16
+17
+18
+19
+20
+21
+22
+23
+24
+25
+26
+27

Abnormal response(M_RLT＝1)

8 7
Node name of node information0

Initial address of the area 1
Size of the area 1
Initial address of the area 2
Size of the area 2
Spare
Token monitoring timeout time
Spare
Allowable minimum frame interval time
Spare
Status of the link
Spare
Protocol type
Upper layer status
Allowable refresh cycle time setting value
Refresh cycle measurement value (current value)
Refresh cycle measurement value (maximum value)
Refresh cycle measurement value (minimum)
15

Offset +0+1+2

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

0

– 142 –JEM1479：2012f)

Network parameter write

The data part of the network parameter write shall be shown in Table 34.
Table 34 - The data part of the network parameter write
Items

Contents of data part

RequestOffset

+0
+1
+2
+3
+4
+5

15

8

7

0

0
Setting parameters flag
Initial address of the area 1
Size of the area 1
Initial address of the area 2
Size of the area 2
Node name of node information+9

Only settings of the address and the size are written when the setting parameters flagis 16#01.
Only settings of the node name are written when the setting parameters flag is 16#02.
Both settings of the address and settings of the node name are written when the setting
parameters flag is 16#03.
Normal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Not available
15
Offset +0+1+2

Unimplemented response(M_RLT＝2)g)

0

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Not available

Stop command

The data part of the stop command service shall be shown in Table 35.
Table 35 - The data part of the stop command service
Items
RequestNormal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Contents of data partNot available
Not available
15
Offset +0+1+2

Unimplemented response(M_RLT＝2)

Not available

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

0

– 143 –h)

JEM1479：2012

Operation command

The data part of the operation command service shall be shown in Table 36.
Table 36 - The data part of the operation command service
Items
RequestNormal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Contents of data partNot available
Not available

Offset +0+1+2

Unimplemented response(M_RLT＝2)

i)

15

0

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Not available

Profile readThe data part of the profile read shall be shown in Table 37.
Table 37 - The data part of the profile read
Items
RequestNormal response(M_RLT＝0)

Contents of data partNot available
Offset +0
+1

15

0

Read data
Data is outside the scope of this stipulation.

+2

Abnormal response(M_RLT＝1)

+1
+2

j)

0

15
Offset +0

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Transparent message

The data part of transparent message service shall be shown in Table 38.
Table 38 - The data part of the transparent message service
Items

Contents of data part

RequestOffset +0
+1
+2

15

Data of transparent message service
Any size at the maximum of 1024 octets is
acceptable.

0

– 144 –JEM1479：2012k)

Log data readThe data part of the log data read shall be shown in Table 39.
Table 39 - The data part of the log data read
Items
RequestNormal response(M_RLT＝0)

Contents of data partNot available
Offset +0

Abnormal response(M_RLT＝1)

0

Read data+1

For data, refer to Appendix B.

+2

The size is 512 octets.

Offset +0
+1
+2

l)

15

0

15

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Log data clear

The data part of the log data clear shall be shown in Table 40.
Table 40 - The data part of the log data clear
Items
RequestNormal response(M_RLT＝0)
Abnormal response(M_RLT＝1)

Contents of data partNot available
Not available
1
Offset +0 5 Error code
+1
+2

0

Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

m) Message return
The data part of the message return service shall be shown in Table 41.
Table 41 - The data part of the message return service
Items

Contents of data part

RequestOffset +0+1+2

Normal response(M_RLT＝0)15

15
Offset +0
+1
+2

0

Data
Users can use arbitrary data.
Any size at the maximum of 1024 octets is
acceptable.

Data
Data is the same as the request.
Any size at the maximum of 1024 octets is
acceptable.

0

– 145 –n)

JEM1479：2012

Vendor specific message

The data part of a vendor specific message shall be shown in Table 42.
Table 42 - The data part of the vendor specific message
Items

Contents of data part

RequestOffset +0+1+2

Normal response(M_RLT＝0)

+2

0

Data
Users can use arbitrary data.
Any size at the maximum of 1024 octets is
acceptable.
15

Offset +0+1+2

Unimplemented response(M_RLT＝2)0

Data
Users can use arbitrary data.
Any size at the maximum of 1024 octets is
acceptable.
15

Offset +0+1

Abnormal response(M_RLT＝1)

15

0

Error code
Error codes shall be defined by venders.
Any size at the maximum of 1024 octets is
acceptable.

Not available

Note When a vendor specific message is not implemented, and when a request for a vendor name not supported
is received, an unimplemented response shall be used.

– 146 –JEM1479：2012
10.4 Solicitation frame
10.4.1

Solicitation Frame Header

The solicitation frame header shall be as follows.
a)

Header structure

The header structure of a solicitation frame shall be as shown in Figure 111.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SEQ(Not used)
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD (Not used)reserved
MFT
M_RLT
(Not
used)
(Not
used)
36
VER
TCD
40
44 C_AD1 (Not used) C_SZ1 (Not used)
48 C_AD2 (Not used) C_SZ2 (Not used)
MODE
P_TYPE
PRI
52
CBN
TBN
BSIZE
RCT (Not used)
LKS
TW
60 (Not used) (Not used)
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA
DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
16#FF
M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
78
11 12 14 15
16#00
16#03
16#00
16#00 1reserved
reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 111 - The header structure of the solicitation frame

– 147 –b)

JEM1479：2012

Details of header items

Details of the header items of a solicitation frame shall be shown in Table 43.
Table 43 - Details of header items
Symbols

Size(Octet)
4
4
1
1
4
1 bit
1 bit
2
2
2
1
1
1
1
2

H_TYPE
TFL
SNA
DNA
V_SEQ
BCT
PPT
TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

10.4.2

Items
Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Broadcast transmission
Peer to peer transmission
Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 1 088
─
255
─
1
0
65 017

Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

The Data Part Format of the Solicitation Frame

Solicitation frames shall be transmitted from the master to a target slave and define thecommon memory allocation in the flexible setting mode. As shown in Figure 112, the data partof the solicitation frame shall set the slave node number, fixed settings and flexible settings
identification flags, IO data area, and the status areas (the solicitation frames only include
request data, and no response).
The data size of a solicitation frame is 8 words per node.
One transmission shall be up to 64 nodes (1024 octets) according to the defined transmission
frame size.
When more than 64 nodes are included, solicitation data shall be transmitted with a nu mber ofsolicitation frames (maximum of 4).

Offset(Decimal) (octet)

0
4
8
12
16
to
28
29
to
44
・
・

0
Slave node number
Input data size
Output data size
Output status address

15 16
Input data address
Output data address
Input status address
Lock ID31
One set of slave
information
One set of slave
information
One set of slave
information

Note Data is stored in a little-endian octet order.

Figure 112 - The data part format of the solicitation frame

– 148 –JEM1479：2012a)

Details of the slave node number part

It is an area to specify the node number of a slave. The most significant bit specifies whether
it is fixed mode or flexible mode. Details of the slave node number part shall be as shown in
Figure 113.
D0

D15
Node number (1 to 249)
0 = fixed setting mode (not used)
1 = flexible setting mode

Figure 113 - Details of the slave node number partb)

Details of the address part

It is an area to specify the word address of the common memory of a slave. The mostsignificant bit specifies the area 1 or the area 2. Details of the address part shall be as shownin Figure 114.
D0

D15
The offset address area 1 (0 to 16#1FF), the area 2 (0 to 16#1FFF) in the area
0 = area 1
1 = area 2

Figure 114 - Details of the address partc)

Details of the data size part

Details of the data size part shall be as shown in Figure 115.
D0

D15
The data size area (0 to 16#200), the area 2 (0 to 16#2000)

Figure 115 - Details of the data size part
It is an area to specify the word size of the common memory of a slave.
Note
The input status size and output status size are fixed to 16 words and shall not be set.
When extra status data area is required, it shall be allocated in the IO area.
d)

Details of the Lock ID part

Details of the Lock ID part shall be as shown in Figure 116.
D0

D15
Lock ID (1 to 249) (decimal)

Figure 116 - Details of the Lock ID part
The last 1 octetof the IP address of the master is allocated.
Example: Address: 192.168.0.1
Address: 192.168.0.100

Lock ID: 1
Lock ID: 100

– 149 –JEM1479：2012

10.5 IO Allocation Setting Frame
10.5.1The Header Format of the IO Allocation Setting Frame

The frame header format of the IO allocation shall be as follows.
a)

Header structure

The header structure of the IO allocation setting frame shall be as shown in Figure 117.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD
M_RLT
MFT
reserved
(Not
used)
36
VER
TCD
40
C_SZ1 (Not used)
44 C_AD1 (Not used)
C_SZ2 (Not used)
48 C_AD2 (Not used)
MODE
P_TYPE
PRI
52
CBN
TBN
TW
LKS
60 (Not used) (Not used)
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
78
11 12 14 15
16#00
16#03
16#00
16#00 1reserved
reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 117 - The header structure of the IO allocation setting frame– 150 –JEM1479：2012b)

Details of header items

Details of the header items shall be shown in Table 44.
Table 44 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 88 (decimal)
1 to 254 (decimal)
1 to 254 (decimal)
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response
0: Normal, 1: Abnormal, 2: Not
implemented
65 018，65 218(decimal)
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

– 151 –10.5.2JEM1479：2012

The Format of the Data Part of the IO Allocation Setting Frame

The format of the data part of the IO allocation setting frame shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 118.
RequestOffset(Decimal) (octet)

0
4
8
12
16
20

Note 1
Note 2
Note 3Note 4Note 5Note 60
15
Setting No. (n-th)
Lock ID
Slave node number
Input data size
Output data size
Output status address

16
31
Number of control slaves (total)
Lock timeout setting value
Input data address
Output data address
Input status address
ReserveSlave
information

Data is stored in a little-endian octet order.
IO allocation from the setting tool to flexible master shall be set node by node and when there are
two or more slave nodes, the settings shall be repeated for the number of nodes.
The number of control slaves: the total number of slaves managed by the master.
Setting No.: Indicates the position in sequence of the setting information over the number of control
slaves.
Lock ID: In case there are two or more information on the slave to be set up, when the first setting No.
is sent, any ID added to the response data from the command server of flexible master of the
responder shall be added and set from the second time. When there are two or more setting tools
which access the same master, this ID is used for exclusion control of IO allocation from other setting
tools.
Lock timeout setting value: Set when the setting No. = 1.
The node regards this value as lock time timeout period of IO allocation.
The setting ranges shall be from 1 to 65,535 (seconds).
― The setting No. indicates the position in sequence of the setting in the (total) number of thecontrol slaves.
― When the setting No. = 1, the master shall start a new setting and discard the old one.
― When the same setting is received, the latest shall be overwritten.
― It is consider to be the end of setting when the number of the control slave and the setting No.
are the same.
― When all are to be deleted, the number of the control slaves and the setting No. shall be set to0.

Note 7 When the setting No. = 16#FFFF and the number of control slaves = 16#FFFF, it functions as acommand to cancel the lock of IO allocation.

Figure 118 - The data part upon receipt (receipt of request from a partner)
1)

Details of the slave node number part

Details of the slave node number part shall be as shown in Figure 119.
D0

D15
Node number (1 to 249) (decimal )0 = fixed setting mode (not used)
1 = flexible setting mode

Figure 119 - Details of the slave node number part
It is an area to specify the node number of a slave. The most significant bit specifies whether
it is fixed or flexible.

– 152 –JEM1479：2012
2)

Details of the address part

Details of the address part shall be as shown in Figure 120.
D0

D15
The offset address area 1 (0 to 16#1FF), the area 2 (0 to 16#1FFF) in the area
0 = area 1
1 = area 2

Figure 120 - Details of the address part
It is an area to specify the word address of the common memory of a slave. The mostsignificant bit specifies the areas 1 and 2.
3)

Details of the input and output data size part

Details of the input and output data size part shall be as shown in Figure 121.
D0

D15
The data size area 1 (0 to 16#200), the area 2 (0 to 16#2000)

Figure 121 - Details of the input and output data size part
It is an area to specify the word size of the common memory of a slave.
Note

The input status size and output status size are fixed to 16 words and shall not be set.

When extra status data area is required, it shall be allocated in the IO area.
b)

The data part upon response

The data part upon response shall be as shown in Figure 122.
Response

Offset(Decimal) (octet)
040Result (M_RLT)
Lock ID (response)

15 16
Information
Reserve

31

Result :=0 Normal:=1 Continue:=2 Abnormal
Information: Result = 2 the factor of the abnormal condition
1 = Abnormal slave node number
2 = Abnormal slave common memory address
3 = Abnormal slave common memory size
4 = Exclusive control locked
5 = Exclusive lock time timed out
Lock ID: Any IDs returned from the command server.
This ID shall be added to the second and the following
requested data part.

Note When the Result = "0 normal" and "1 Continue", the message result of the header (M_RLT) = 0: normal.
When the result = "2 Abnormal", the message result of the header (M_RLT) = 1: abnormal.

Figure 122 - The data part when transmitting a response(response to a request received from the partner)

– 153 –JEM1479：2012

10.6 IO Allocation and Read Frame
10.6.1The Header Format of the IO Allocation and Read Frame

The header format of the IO allocation read frame shall be as follows.
a)

Header structure

The IO allocation shall be read from the master node.
Since the size is for one node, the setting No. shall be set upon request. The header structureof the IO allocation read frame shall be as shown in Figure 123.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD (Not used)reserved
M_RLT
MFT
(Not
used)
36
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
C_AD2
(Not
used)
C_SZ2
(Not used)
48
MODE
P_TYPE
PRI
52
CBN
TBN
LKS
TW
(Not
used)
(Not
used)
60
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
78
11 12 14 15
16#00
16#03
16#00
16#00 1reserved
reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 123 - The header structure of the IO allocation read frame– 154 –JEM1479：2012b)

Details of header items

Details of the header items shall be shown in Table 45.
Table 45 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

10.6.2

Items

Setting values“FACN”
64 to 84 (decimal)
1 to 254 (decimal)
1 to 254 (decimal)
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 019，65 219(decimal)
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

The Format of the IO Allocation and Read Frame Data Part

The format of the IO allocation read frame data part shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 124.
RequestOffset(Decimal) (octet)
0

0

15
16
Setting No. m (1 to 248) (decimal )Figure 124 - The data part upon request31

– 155 –b)

JEM1479：2012

The data part upon response

The data part upon response shall be as shown in Figure 125.
Response

Note 1
Note 2
Note 3

Offset(Decimal) (octet)
0
4
8
12
16

0
15
Setting No.
Slave node number
Input data size
Output data size
Output status address

16
31
Number of control slaves
Input data address
Output data address
Input status address
Reserve

Slave information
when the setting
No. = mData is stored in a little-endian octet order.
The setting No. indicates the setting No. upon IO allocation.
When the setting No. of requested data is in abnormal range (other than 1 to 248), the message
result of the header (M_RLT) = 1 (abnormal).
When there is no slave information, the number of control slaves and the setting No. of response
data shall be 0, and the message result of the header (M_RLT) = 0 (normal).
When the request of No. which is not set is received, the number of control slaves and the setting No.
shall be 0, and the message result of the header (M_RLT) = 0 (normal).

Note 4Note 5Figure 125 - The data part upon response

1)

Details of the slave node number part

Details of the slave node number part shall be as shown in Figure 126.

D0

D15
Node number (1 to 249) (decimal )0= fixed setting mode (not used)
1= flexible setting mode

Figure 126 - Details of the slave node number part
It is an area to specify the node number of a slave. The most significant bit specifies whether
it is fixed or flexible.

2)

Details of the address part

Details of the address part shall be as shown in Figure 127.
D0

D15
The offset address area 1 (0 to 16#1FF), the area 2 (0 to 16#1FFF) in the area
0= area 1
1= area 2

Figure 127 - Details of the address part
It is an area to specify the word address of the common memory of a slave. The mostsignificant bit specifies the areas 1 and 2.

– 156 –JEM1479：2012
3)

Details of the input and output data size part

Details of the input and output data size part shall be as shown in Figure 128.
D0

D15
The data size area 1 (0 to 16#200), the area 2 (0 to 16#2000)

Figure 128 - Details of the input and output data size part
It is an area to specify the word size of the common memory of a slave.
Note The input status size and output status size are fixed to 16 words and shall not be set.
When extra status data area is required, it shall be allocated in the IO area.
10.7 Token Retention Time Measuring Flame
10.7.1The Header Format of the Token Retention Time Measuring Flame

The header format of the token retention time measuring flame shall be as follows.
a)

Header structure

The header structure of the token retention time measuring flame shall be as shown in Figure
129.

0

H_TYPE

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

4

TFL
SA
DA
V_SEQ

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

0

31

8
12
16
20
24
28
32

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD(Not used)reserved
M_RLT
MFT
36 (Not used)
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
C_SZ2 (Not used)
48 C_AD2 (Not used)
MODE
P_TYPE
PRI
52
56

CBN

TBN

LKS
TW
60 (Not used) (Not used)

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
16#00
reserved

78
16#00

11 12
14 15
16#03
16#00 1reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 129 - The header structure of the token retention time measuring flame– 157 –b)

JEM1479：2012

Details of the header items

Details of the header items of the token retention time measuring flame shall be shown in
Table 46.
Table 46 - Details of the header items
Symbols
H_TYPE
TFL
SA
DA
V_SEQ
SEQ

Size
(Octet)
4
4
4
4
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD

2Transaction code

VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
1
1
1
1
2

Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
────

01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 020，65 021，65 220，65 221(decimal)Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

JEM1479：2012
10.7.2– 158 –The Format of the Data Part of the Token Retention Time Measuring Flame

The response data item added as a response to a token retention time measurement
terminating request shall be shown in Table 47.
Table 47 - Token retention time measurement Response data
Offset(Decimal) (octet)
00Number of the events of discarding token
4Time when the event of discarding token was detected last8
Number of the events of reissuing token
12Time when reissuance of token occurred last16
The number of the token retention timeouts
20
Time when the token retention timeout event occurred last24
The number of the token watchdog timeouts
28
Time when the token watchdog timeout event occurred last32
Maximum token retention time
36
Minimum token retention time
40
The time when the maximum token retention time was detected
44
Measuring time for token retention time48
The number of tokens while measuring the token retention time
52
Detection time for the maximum refresh cycle
56
Number of the events of receiving cyclic frame
60
Number of errors in receiving cyclic frame
64
Detection time for error in receiving cyclic frame
68
Number of errors in receiving message frame
72
Detection time for error in receiving message frame
Note
Data is stored in a little-endian octet order.

31

– 159 –JEM1479：2012

10.8 The Message Frame of General Purpose Communication Data Sender Log
10.8.1The Header Format of the Message Frame of the General Purpose
Communication Data Sender Log

The header format of the message frame of the general purpose communication data sender log shallbe as follows.
a)

Header structure

The Header structure of the message frame of the general purpose communication data
sender log shall be as shown in Figure 130.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD(Not used)reserved
M_RLT
MFT
36 (Not used)
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
48 C_AD2 (Not used) C_SZ2 (Not used)
MODE
P_TYPE
PRI
52
TBN
TW
LKS
60 (Not used) (Not used)
56

CBN

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
16#00
reserved

78
16#00

11 12
14 15
16#03
16#00 1reserved
Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 130 - The header structure of the message frame of the general purpose
communication data sender log

– 160 –JEM1479：2012b)

Details of header items

Details of the header items of the message frame of the general purpose communication data
sender log shall be shown in Table 48.
Table 48 - Details of the header items
Symbols
H_TYPE
TFL
SA
DA
V_SEQ
SEQ

Size
(Octet)
4
4
4
4
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
────

01
0: Normal, 1: Abnormal, 2: Not
implemented
65 022，65 023，65 222，65 223
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

– 161 –10.8.2JEM1479：2012

The Format of the Message Frame Data Part of the General Purpose
Communication Data Sender Log

The response data item added as a response to the general purpose communication data
sender log measurement terminating request shall be shown in Table 49.
Table 49 - The response data for the general purpose communication data sender log
measurement
Offset(Decimal) (octet)
0031
Measuring time for general purpose communication data
sender log
4
IP 1
8
IP 1 receive counter
12
IP 2
16
IP 2 receive counter
20
IP 3
24
IP 3 receive counter
28
IP 4
32
IP 4 receive counter
36
IP 5
40
IP 5 receive counter
44
IP 6
48
IP 6 receive counter
52
IP 7
56
IP 7 receive counter
60
IP 8
64
IP 8 receive counter
68
IP 9
72
IP 9 receive counter
76
IP 10
80
IP 10 receive counter
Note Data is stored in a little-endian octet order.

– 162 –JEM1479：2012

10.9 Configuration Parameter Setting Frame
This frame is to set configuration parameter of the node selected by the user, such as theaddress and the size of the common memory area 1 and 2, the node name, the token
watchdog time, and the allowable minimum frame interval time.
Since some modules do not need to set the common memory addresses such as a fixed
setting module, the users shall select the setting items.
When the configuration parameter except the node name is changed, the re-joining operation
to the network shall be performed.
10.9.1The Header Format of the Configuration Parameter Setting Frame

The header format of the configuration parameter setting frame shall be as follows.
a)

Header structure

The header structure of the configuration parameter setting frame shall be as shown in Figure
131.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD(Not used)reserved
M_RLT
MFT
36 (Not used)
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
C_SZ2 (Not used)
48 C_AD2 (Not used)
MODE
P_TYPE
PRI
52
CBN
TBN
TW
LKS
60 (Not used) (Not used)
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
16#00
reserved

78
16#00

11 12
14 15
16#03
16#00 1reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token
mode
Fixed to 1

Figure 131 - The header structure of the configuration parameter setting frame– 163 –b)

JEM1479：2012

Details of header items

Details of the header items of the configuration parameter setting frame shall be shown in
Table 50.
Table 50 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 92 (decimal)
1 to 254 (decimal)
1 to 254 (decimal)
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 024，65 224 (decimal)
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

– 164 –JEM1479：2012
10.9.2The Format of the Data Part of the Configuration Parameter Setting Frame

The parameter shall be configured in a setting request as shown in Figure 132, and theconfigured contents shall be returned as the response data to confirm the setting.
Each parameter of the setting item can be selected to be updated or not updated with theupdate flag.
The format of the data part of the configuration parameter setting frame shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 132.
Offset(Decimal)(octet)
0
4
8
12
16
20
24

Request0
7 8
15
Update flag
Node name
Node name
Node name
Address of the common memory 1
Address of the common memory 2
Token watchdog
Reservetime

16
Reserve

23

24

31

Reserve
Size of the common memory 1
Size of the common memory 2
Allowable minimum
Reserveframe interval time

Update flag

0

1

2

3

4

15
16#00
Update flag of the address of the common memories
1 and 2, and the size.
Node name update flag
Token watchdog time update flag

Allowable minimum frame interval time update flag
0: No Update
1: With Update

Figure 132 - The data part upon requestb)

The data part upon response

The data part upon response shall be as shown in Figure 133.
Response

Note

Offset(Decimal)(octet)
0
4
8
12
16
20

0
7 8
15
Node name
Node name
Node name
Address of the common memory 1
Address of the common memory 2
Token watchdog
Reserve
time

16

23

24

Reserve
Size of the common memory 1
Size of the common memory 2
Allowable minimum
Reserveframe interval time

Data is stored in a little-endian octet order.
Figure 133 - The data part upon response31

– 165 –JEM1479：2012

Details of the data part shall be described in Figure 134.
Items
Address of the common memory 1
Size of the common memory 1
Address of the common memory 2
Size of the common memory 2
Node name

Setting range
16#0000 to 16#01FF
16#0000 to 16#0200
16#0000 to 16#1FFF
16#0000 to 16#2000
Maximum of 10 characters(Rests are filled with Null)
1 to 255 (decimal)
0 to 50 (decimal)

Parameter unit
Word
Word
Word
Word
ASCII characters

Notes

Token watchdog timemSec (1/1 000 seconds) (Seconds)
Allowable minimum frame interval
100 µSecex. 50＝5 000 µSec
time
(1/1 000 000 seconds)
Note When the parameter outside the setting range is requested, the message result of the header (M_RLT) =1:
Abnormal.

Figure 134 - Details of the data part10.10 Participating Node Management Information Parameter Read Frame
Participating node management information parameter read reads the status information(participating node management information parameter) of each node participating in the
network.
10.10.1 The Header Format of the Participating Node Management Information
Parameter Read Frame
The header format of the participating node management information parameter read frame
shall be as follows.

– 166 –JEM1479：2012a)

Header structure

The header structure of the participating node management information parameter read frame
shall be as shown in Figure 135.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD (Not used)reserved
M_RLT
MFT
(Not
used)
36
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
C_AD2
(Not
used)
C_SZ2
(Not used)
48
MODE
P_TYPE
PRI
52
CBN
TBN
TW
LKS
(Not
used)
(Not
used)
60
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
78
11 12
14 15
16#00
16#03
16#00
16#00 1reserved
reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 135 - The header structure of the participating node management information
parameter read frame– 167 –b)

JEM1479：2012

Details of header items

Details of the header items of the participating node management information parameter readframe shall be shown in Table 51.
Table 51 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 84 (decimal)
1 to 254 (decimal)
1 to 254 (decimal)
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 025，65 225 (decimal)
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

10.10.2 The Format of the Data Part of the Participating Node Management Information
Parameter Read Frame
The format of the data part of the participating node management information parameter readframe shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 136.
RequestOffset(Decimal)(octet)
00Node number

15 16Reserve

Figure 136 - The data part upon request31

– 168 –JEM1479：2012b)

The data part upon response

The data part upon response shall be as shown in Figure 137.
Response

Offset(Decimal)(octet)

0

15

16

31

0

Node number

Upper layer status

4

Common memory area 1 top
address

Common memory area 1 data size

8

Common memory area 2 top
address

Common memory area 2 data size

12

Allowable refresh cycle time

Token watchdog time

16

Allowable minimum frame intervaltime

FA link status

Note Data is stored in a little-endian octet order.

Figure 137 - Data part upon response
Details of the participating node management information parameter shall be as follows.
1)

Node number (2 octets): 1 to 254

2)Upper layer status (2 octets): Operating information, error information, etc.

3)

Common memory area 1 top address (2 octets): Word address (16#0000 to 16#01FF)

4)

Common memory area 1 data size (2 octets): Size (16#0000 to 16#0200)

5)

Common memory area 2 top address (2 octets): Word address (16#0000 to 16#1FFF)

6)

Common memory area 2 data size (2 octets): Size (16#0000 to 16#2000)

7)

Allowable refresh cycle time (2 octets): 0 to 65,535: by 1 ms

8)

Token watchdog time (2 octets): 1 to 255: by 1 ms

9)Allowable minimum frame interval time (2 octets): 0 to 50: by 100 s10) State of FA link (2 octets): participation and disengagement information, etc. (refer toFigure 138)
Note
When requested data is received with parameters other than the node number from 1
to 254, the message result of the header (M_RLT) = 1: Abnormal.

One
node

– 169 –Status of the FA
link 17 18 19 20 21 22 23 24
16
0

0

0

JEM1479：2012

31
・・・

0
Reserved
Participation anddisengagement of the self node
0: Disengagement
1: Participation
Detection of invalid
communication
0: Communication valid
1: Communication invalid
Upper layer operation signal
error
0: No error
1: Error
Common memory data valid
notification
0: Invalid
1: Valid
Completion of the common
memory setting
0: Not completed
1: Completed
Address duplication detection
0: No error
1: ErrorFigure 138 - Details of the FA link status10.11 Read frame of self node management information parameter
10.11.1 Outline
Self node management information parameter read reads data about settings and operation of
the self node which was set by the upper layer of the FA link layer or the network parameter
write service when starting the node.

– 170 –JEM1479：2012

10.11.2 The header format of the self node management information parameter readframe
The header format of the read frame of self node management information parameter shall be
as follows.
a)

Header structure

The header structure of the read frame of self node management information parameter shallbe as shown in Figure 139.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD (Not used)reserved
M_RLT
MFT
36 (Not used)
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
48 C_AD2 (Not used) C_SZ2 (Not used)
MODE
P_TYPE
PRI
52
CBN
TBN
LKS
TW
(Not
used)
(Not
used)
60
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
16#00
reserved

78
16#00

11 12
16#03

14 15

16#00 1reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 139 - The header structure of the read frame of self node management
information parameter– 171 –b)

JEM1479：2012

Details of header items

Details of the header item of the read frame of self node management information parametershall be shown in Table 52.
Table 52 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 128 (decimal)
1 to 254 (decimal)
1 to 254 (decimal)
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 026，65 226 (decimal)
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

– 172 –JEM1479：2012

10.11.3 The Format of the Data Part of the read frame of self node management
information parameter
The format of the data part of the read frame of self node management information parametershall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 140.
RequestNot available

Figure 140 - The data part upon requestb)

Data part upon response

The data part upon response shall be as shown in Figure 141.
Response

Offset(Decimal)(octet)
0
4
8
12
16
20
24
28
32
36
40
44
48
52
56
60

0
15
Node number
Common memory area 1 top address
Common memory area 2 top address
Upper layer status
Allowable minimum frame interval time
Vendor code
Vendor code
Vendor code
Manufacturer model name
Manufacturer model name
Manufacturer model name
Node name
Node name
Node nameProtocol type
Status of the self node

16
31
Reserve
Common memory area 1 data size
Common memory area 2 data size
Token watchdog time
Reserve

Reserve

Reserve

Reserve
Status of the FA link
Identification of the self node class

Note Data is stored in a little-endian octet order.

Figure 141 - The data part upon response
Details of the self node management information parameters shall be as follows.
1)

Node number (2 octets): 1 to 254

2)

Common memory area 1 top address (2 octets): Word address (16#0000 to 16#01FF)

3)

Common memory area 1 data size (2 octets): Size (16#0000 to 16#0200)

4)

Common memory area 2 top address (2 octets): Word address (16#0000 to 16#1FFF)

5)

Common memory area 2 data size (2 octets): Size (16#0000 to 16#2000)

6)

Upper layer status (2 octets): Operating information, error information, etc. (refer toFigure 142)

7)

Token watchdog time (2 octets): 1 to 255: by 1 ms

8)

Allowable minimum frame interval time (2 octets): 0 to 50: by 100 s

9)Vendor code (10 octets): the name of the vendor (ASCII characters)10) Manufacturer model name (10 octets): the Manufacturer model name of the node(ASCII
characters)

– 173 –JEM1479：201211) Node name of node information (10 octets): the name of the node set by the user (ASCII
characters)
12) Protocol type (2 octets): fixed to 16#0080
13) Status of the FA link (2 octets): participation, disengagement, etc. (refer to Figure 143)
14) Status of the self node (2 octets): overlap detection etc. of the node numbers (refer toFigure 144)15) Identification of the self node class (2 octets): Indicates the node class of the s elf node
(refer to Table 53)

Table 53 - Table of Node class Identification Values
Node class nameVer.2.00
Ver.2.00

Ver.2.00

Ver.3.00

Controller + flexible master
Flexible master
Fixed master
Flexible slave
Fixed slave

Value
1
2

Note
Since Ver.2.00 node does not support thecommand server, it does not return a
response.
For details, refer to the product category ofClause 5.

3
4
5
6
7

Upper layer status0

11 12 13 14 15

・・・

0
U_ERR_CODE
Arbitrarily set by users
Reserved
WARNING
0: No error
1: Error

ALARM
0: No error
1: Error

RUN/STOP
0：STOP
1：RUN

Figure 142 - Details of the upper layer status

– 174 –JEM1479：2012
Status of the FA link
16 17 18 19 20 21 22 23 24
0

0

0

31
・・・

0
Reserved
Participation anddisengagement of the self node
0: Disengagement
1: Participation
Detection of invalid
communication
0: Communication valid
1: Communication invalid
Upper layer operation
signal error
0: No error
1: Error
Common memory data valid
notification
0: Invalid
1: Valid
Completion of the common
memory setting
0: Not completed
1: Completed
Address duplication detection
0: No error
1: ErrorFigure 143 - Details of the FA link status

– 175 –0

Status of the self node
1 2 3 4 5 6

0

0

0

7

8
0

JEM1479：2012

15
・・・

0
Reserved
Token watchdog time error
0: No error
1: Error

Common memory range error
0: No error
1: Error

Frame waiting state
0: With other nodes
1: Without other nodes

Overlap of self node number
0: No error
1: ErrorCompletion of self node settings
0: Not completed
1: CompletedFigure 144 - Details of the self node status

– 176 –JEM1479：2012

10.12 Read Frame of Self node Configuration Information Parameter
Read node setting information of the node selected by the user.
Values set up by configuration parameter setting can be directly read, which is not the nod e
information flowing in the FL-net network. It is used to confirm parameters set in the node.
10.12.1 The Header Format of the Read Frame of Self node Configuration Information
Parameter
The header format of the self node setting information parameter read frame shall be as
follows.
a)

Header structure

The header structure of the self node setting information parameter read frame shall be as
shown in Figure 145.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD (Not used)reserved
M_RLT
MFT
(Not
used)
36
VER
TCD
40
C_AD1
(Not
used)
C_SZ1
(Not used)
44
C_AD2
(Not
used)
C_SZ2
(Not used)
48
MODE
P_TYPE
PRI
52
CBN
TBN
LKS
TW
60 (Not used) (Not used)
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA

BSIZE
RCT
(Not used)

M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
78
11 12 14 15
16#00
16#03
16#00
16#00 1reserved
reserved

Minor version
Fixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 145 - The header structure of the self node setting information parameter readframe

– 177 –b)

JEM1479：2012

Details of header items

Details of the header items of the self node setting information parameter read frame shall beshown in Table 54.
Table 54 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 to 88 (decimal)
1 to 254
1 to 254
Fixed to 16#0000_0000
16#0000_0001 to 16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 027，65 227
Fixed to 16#0000
Refer to Figure 100.
Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

10.12.2 The Format of the Data Part of the Read Frame of Self node Configuration
Information ParameterIn response to a request, a response shall be returned with setting information added to thedata part. The format of the data part of the self node setting information parameter readframe shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 146.
RequestNot available

Figure 146 - The data part upon request

– 178 –JEM1479：2012b)

Data part upon response

The data part upon response shall be as shown in Figure 147.
Response

Offset(Decimal)(octet)
0
4
8
12
16
20

0
15 16
31
Address of the common memory 1
Size of the common memory 1
Address of the common memory 2
Size of the common memory 2
Token watchdog time
Allowable minimum frame interval time
Node name
Node name
Node nameReserve

Note Data is stored in a little-endian octet order.

Figure 147 - The data part upon response

– 179 –JEM1479：2012

10.13 Node Reset Frame
A node reset frame is used when a node is reset not by physically shutting power off but by
remotely performing it.
Reset operation is performed by resetting the FA link layer and the operation is notified toapplication when performed.
10.13.1 The Header Format of the Node Reset Frame
The header format of the node reset frame shall be as follows.
a)

Header structure

The header structure of the node reset frame shall be as shown in Figure 148.
0

31

0

H_TYPE

4

TFL
SA
DA
V_SEQ

8
12
16
20
24
28
32

SEQ
M_CTL

ULS (Not used)
M_SZ (Not used)
M_ADD(Not used)reserved
M_RLT
MFT
36 (Not used)
VER
TCD
40
C_AD1
(Not
used)
C_SZ1(Notused)
44
48 C_AD2 (Not used) C_SZ2 (Not used)
MODE
P_TYPE
PRI
52
CBN
TBN
BSIZE
RCT
(Not used)
LKS
TW
(Not
used)
(Not
used)
60
56

SA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
SNA
DA
0
7 8
15 16
23 24
31
16#00
16#01
16#00
DNA
M_CTL
0

7 8
16#00

0
1
BCT PPT
24

15 16
23 24
31
16#00
16#00

2
3
0
31 RPL

reserved

4
0

5
6
0
0
reserved
Not used

7
0

MODE
0

34
16#00
reserved

78
16#00

11 12
16#03

14 15

16#00 1reserved

Minor
versionFixed to 0
Major version
Fixed to 3
as Ver.3.00.
Token mode
Fixed to 1

Figure 148 - The header structure of the node reset frame

– 180 –JEM1479：2012b)

Details of header items

Details of the header items of the node reset frame shall be shown in Table 55.
Table 55 - Details of the header items
Symbols
H_TYPE
TFL
SNA
DNA
V_SEQ
SEQ

Size
(Octet)
4
4
1
1
4
4

Items

BCT
PPT
M_RLT

1 bit
1 bit
1

Header type
Octet length including header and data
Node number of source side
Node number of destination side
Version of sequence number
Sequence number (16#FFFF_FFFF) isfollowed by (16#0000_0001).
Sequence number 0 shall not be used.
Broadcast transmission
Peer to peer transmission
Message result (Normal, Abnormal)

TCD
VER
MODE
P_TYPE
PRI
CBN
TBN
BSIZE

2
2
2
1
1
1
1
2

Transaction code
Program version
FA link protocol, token mode
Protocol typeMessage priority
Current fragment block number
Total fragment block number
Current block size (octet)

Setting values“FACN”
64 (decimal)
1 to 254
1 to 254
Fixed to 16#0000_0000
16#0000_0001～16#FFFF_FFFF01
Response message
0: Normal, 1: Abnormal, 2: Not
implemented
65 028，65 228
Fixed to 16#0000
─Fixed to 16#80
Fixed to 16#00
Fixed to 16#01
Fixed to 16#01
Fixed to 16#0000

– 181 –JEM1479：2012

10.13.2 The Format of the Data Part of the Node Reset Frame
The format of the data part of the node reset frame shall be as follows.
a)

The data part upon request

The data part upon request shall be as shown in Figure 149.
RequestNot available

Figure 149 - The data part upon requestb)

Data part upon response

The data part upon response shall be as shown in Figure 150.
Response

Not available

Figure 150 - The data part upon response
Note
Operation when receiving a node reset frame When a node received a node reset
frame, it resets the self node after returning a response (refer to Figure 151).

Setting tool
Monitor tool
(Personal computer)

The setting tool side
resets the port which
has been used.

Node
Node reset
frames (Request)

Node reset frame(Response)

Reset the node

Notify the applicationthat the node was reset

Figure 151 - The receiving sequence of the node reset frame

JEM1479：2012– 182 –

Appendix A(Reference)
The State Transition Diagram of the FA Link Protocol
A.1 The State Transition of The Overall Protocol
A.1.1 State Definition
The state definition shall be as follows.
a)

Initialization request waiting state

The status for waiting for the upper layer to set initialization information required forparticipation to the network, such as a self node num ber.
b)Joining token detection time waiting state

The status for judging whether or not the network link is established.
If a token frame is received even once within this period of time, the network shall beconsidered to be in the valid linking state.
c)

Trigger frame transmission waiting time waiting state

The state for waiting for transmitting a trigger frame when a node starts.
d)Participation request frame acceptance time waiting state

The status for establishing network information with a participation requ est frame in theparticipation request acceptance time synchronized with a trigger when newly joining.
e)Three circulation waiting state

The status for collecting network information with the last cyclic frames when joining inprogress.
f)Participation request frame transmission waiting state

The status for waiting for transmission of a participation request frame after collection of
network information is completed when joining in progress.
g)

Token waiting state

The status for not holding a token while participa ting in the network. The node waits for atoken addressed to the self node to be received, and monitors other nodes. Existence ofslaves is checked while it is a master.
h)Token retention state

The status after receiving the token frame addressed to the self node before transmitting atoken frame addressed to the next node. A solicitation frame shall be transmitted when there
are not enough slaves while it is a master. In addition, Existence of slaves is checked.
Note
When it is in the joining token detection time waiting state and it is not in the valid
linking state, the trigger frame transmission waiting time waiting state shall shift to theparticipation request frame acceptance time waiting state. This trigger frame transmission
waiting time waiting state or the participation request frame acceptance time waiting stateshall be called a "network startup state". The valid linking state is identified and the threecirculation waiting state shall shift to the participation request frame transmission waiting s tate.
This three circulation waiting state or the participation request frame transmission waiting
state shall be called an "in-ring startup state".
i)

Waiting for receiving a solicitation frame state

The status for waiting for receiving a solicitation frame when the slave in the flexible setting
mode starts in the device level network function.

– 183 –j)

JEM1479：2012

Solicitation frame batch transmission state

The status for transmitting a solicitation frame when the self node is participating to the
network while in the network startup state.
k)Transmitting a solicitation frame state

The status in the valid linking state for transmitting a solicitation frame by solicitation frametransmission waiting time being timed out in the token retention status. It shifts to this statuswhen there are not enough slaves while it is a master.

– 184 –JEM1479：2012
A.1.2 State Transition Diagram

A.1.2.1 The State Transition Diagram of the Overall Protocol (slave)
The state transition diagram (slave) of the overall FA link protocol shall be as shown in Figure
A.1.

Start

a)
Wait for initialization
request*Initialization request
When it is a slave inthe flexible setting
mode

Initialization request
When it is not a slavein the flexible setting
modei)Wait for receiving
solicitation frame
Receive solicitation frameb)Wait for joining token
detection time

- 3CWT timeout- Receive solicitation
frame from the same
master

Detect token
TDT timeout

Detect node
numberduplication

Receive trigger framec)Wait for trigger frametransmission waiting time

- PAT timeout andthe self node only
- Detect token

Detect tokene)Wait for three circulations- TrWT timeout- Receive trigger
frame

f)
Wait for participation request
frame transmissiond)Wait for participation request
frame acceptance time
Detectnode
numberduplication

Receivesolicitation
frame fromthe samemasterThree circulations

PWT timeout

Detect node
numberduplication- PAT timeout and(self node ≠ smallest node number)- Detect token addressed to anothernode- PAT timeout and (selfnode = smallest node
number)- Detect token addressedto the self node

- Detect token addressed tothe self node
- TW timeout and (nextnode = self node)- RMT timeout and (nextnode = self node)- Self node did not receive 3 times
in succession- Only TW timeout and self node
- Only RMT timeout and self node
- Receive solicitation frame fromthe same masterg)
Wait for tokenh)Token retention- Issue token- THT timeout- Receive token addressedto another node

Note* Shift to "a) Wait for initialization request" when the initialization request event is generated.

Figure A.1 - The state transition diagram of the overall protocol (Slave)

– 185 –JEM1479：2012

A.1.2.2 The State Transition Diagram of the Overall Protocol (master and Ver.2.00 no de)
The state transition diagram of the overall FA link protocol (master and Ver.2.00) shall be as
shown in Figure A.2.

Start

a)
Wait for initialization
request*j)
Batch transmit
solicitation frame

Transmission
completed

When it is an flexible setting
mode master

Initialization requestb)
Wait for joining token
detection time

When it is not an flexible
setting mode master

Detect token

3CWT timeout
Detect token

TDT timeoutc)
Wait for trigger frametransmission waiting
time

PAT
timeout
and theself node
only

Detect tokend)Wait for participation
request frame
acceptance time

Transmission
completedh)Token retention
SFTWT timeout

Three circulations- PAT timeout and (selfnode ≠ smallest node
number)- Detect token addressedto another nodef)Wait for participation
request frametransmission- PAT timeout and(self node ≠ smallest node number)- Detect token addressed to the selfnodek)Transmit asolicitation frame

Detectnode
numberduplicatione)
Wait for threecirculations- TrWT timeout- Receive trigger
frame

Detect node number
duplication

Note*

Receive trigger
frame

Detect node
numberduplication

PWT timeout- Detect token addressed to the self
node
- TW timeout and (next node = selfnode)
- RMT timeout and(next node = self node)g)
Wait for token- Issue token- THT timeout- Receive token addressed to another node

- Self node did not receive 3
times in succession- Only TW timeout and self node
- Only RMT timeout and self
node

Shift to "a) Wait for initialization request" when an initialization request event is generated.

Figure A.2 - The state transition diagram of the overall protocol(master and Ver.2.00 node)– 186 –JEM1479：2012
A.1.3 State Transition TableThe state transition table of the overall protocol shall be shown in Table A.2. How to interpretthe state transition table shall be shown in Table A.1.
Table A.1 - How to interpret the state transition table
State

Event
Event name
State nameContents of process(State number)
Destination of shift
Note Destination of shift is indicated by "=> (State
number)".

– 187 –JEM1479：2012

Table A.2 - FA link status transition table
State

Event
Reception of participation
request frame
No process

No process

When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Start joining token detection Tm

=> a)

=> a)

No process

When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Start joining token detection Tm=> b)- Stop joining token Tm- Start participating transmission Tm- Start participating acceptance Tm=> d)

No process- Stop trigger Tm- Start participating transmission Tm- Start participating acceptance Tm

When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Start joining token detection Tm

=> c)

=> d)

When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)

Node number overlap=> d)confirmation is abnormal => a)Other cases => d)- Update participating TBL
No process- Confirm address overlap- Confirm node number overlap
Node number overlap=> e)confirmation is abnormal => a)Other cases => e)- Update participating TBL
No process- Confirm address overlap- Confirm node number overlap

Initialization request from the upper layer
Wait forinitialization fromthe upper layera)Detect joining
tokenb)
Wait for trigger
frame
transmission
waiting timec)Wait forparticipation
request frame
acceptance timed)Start joining token detection Tm

Wait for threecirculations

Start joining token detection Tme)When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Wait forparticipation
request frametransmissionf)Start joining token detection Tm

Wait for tokeng)When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Start joining token detection Tm
When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Token retention
No processh)=> h)Wait for receiving Start joining token detection Tm
solicitation framei)When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)Batch transmit
1) When it is not an flexible setting slave
solicitation frame
Start joining token detection Tm
2) When it is an flexible setting slave
No processj)
When 1) => b)
When 2) => i)
Transmit a
Start joining token detection Tm
solicitation framek)When it is not an flexible setting slave => b)
When it is an flexible setting slave => i)

Reception of trigger- Update participating TBL
No process- Confirm address overlap- Confirm node number overlap

Node number overlap=> f)confirmation is abnormal => a)Other cases => f)Update participating TBL
No process
=> g)
=> g)
Update participating TBL=> h)
No process

No process=> h)
No process

=> i)

=> i)

No process

No process

=> j)

=> j)

No process

No process

=> k)

=> k)

– 188 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State
Reception of token addressed to anothernode
No process

Wait forinitialization fromthe upper layera)=> a)
Detect joining
Start three circulation waiting Tm
token
b)
=> e)
Wait for trigger Start three circulation waiting Tm
frame
transmission
waiting timec)=> e)
Wait for
1) after transmitting participation request
participation
framesrequest frame
Start token watchdog Tm
acceptance time 2) before transmitting participation request
framesStart joining token Tmd)Wait for threecirculationse)

Wait forparticipation
request frametransmissionf)Wait for tokeng)Token retentionh)When 1) => g)When 2) => b)
Confirm node number overlap

Event
Reception of token addressed
Reception of cyclic frameto the self node
(TBN≠CBN)No process
No process=> a)Start three circulation waiting
Tm=> e)Start three circulation waiting
Tm

=> a)
No process=> e)1) after transmitting
participation request frames- Start token watchdog Tm- Start solicitation frametransmission waiting Tm2) before transmitting
participation request frames
Start joining token Tm
When 1) => h)When 2) => b)
Confirm node number overlap=> c)
No process=> b)
No process=> d)
No process

three circulations of the smallest node token three circulations of the
=> e)
=> f)
smallest node token => f)
node number overlap confirmation isnode number overlap
abnormal => a)confirmation is abnormal => a)before three circulations of the smallest node before three circulations of thetoken => e)smallest node token => e)Confirm node number overlap
Confirm node number overlap No process

Node number overlap confirmation isNode number overlap=> f)abnormal => a)confirmation is abnormal => a)Node number overlap confirmation is normal Node number overlap=> f)confirmation is normal => f)- Start token watchdog Tm- Start token retention Tm
Cyclic process- Watch another node leaving from the- Start allowable minimum
network
frame interval Tm- Watch a token addressed to the self node - Start refresh cycle- Start solicitation frame transmission waiting measurement Tm
Tm- Start solicitation frametransmission waiting Tm
Self node did not receive 3 times in
=> h)
=> g)
succession => b)
Other cases => g)1) Self node number > node number ofNo process
No process
recept token- Discard self node token- Stop token retention Tm
2) Self node number < node number ofrecept token- Ignore recept token
When 1) => g)
=> h)
=> h)
When 2) => h)No process
No process
No process

Wait forreceiving
solicitation framei)=> i)Batch transmit
No processsolicitation framej)=> j)Transmit a
No processsolicitation frame
k)
=> k)

=> i)
No process=> i)
No process=> j)
No process=> j)
No process

=> k)

=> k)

– 189 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State

Wait forinitialization fromthe upper layera)Detect joining
tokenb)
Wait for trigger
frame
transmission
waiting timec)Wait forparticipation
request frame
acceptance time
d)

Event
Reception of message frame

Reception of cyclic frame(TBN=CBN)No process

No process=> a)
No process=> a)
No process=> b)
No process=> b)
No process

─

=> c)
No process

Node number overlap confirmation isabnormal => a)Other cases => d)- Update participating TBL- Confirm address overlap- Confirm node number overlap
Node number overlap confirmation isabnormal => a)Other cases => e)- Update participating TBL- Confirm address overlap- Confirm node number overlap=> d)Node number overlap confirmation isabnormal => a)Other cases => f)
Wait for token- Update participating TBL
g)- Cyclic process=> g)
Token retention No processh)=> h)Wait for receiving No processsolicitation framei)=> i)Batch transmit
No processsolicitation framej)=> j)Transmit a
No processsolicitation frame
k)
=> k)

=> f)

e)

Wait forparticipation
request frametransmissionf)Start trigger Tm
=> c)
─

=> c)
- Update participating TBL- Confirm address overlap- Confirm node number overlap

Wait for threecirculations

Joining token detection timeout

─No process

=> e)

─

No process─Message process─=> g)
No process=> h)
No process

─
─

=> i)
No process─=> j)
No process─=> k)– 190 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State
Token watchdog timeout

Event
Refresh cycle timeout

participating transmission timeout

─

─

─

─

─

─

─

─

─

Wait forinitialization fromthe upper layera)Detect joining
tokenb)
Wait for trigger
frame
transmission
waiting timec)Wait forparticipation
request frame
acceptance timed)Wait for threecirculationse)
Wait forparticipation
request frametransmissionf)Wait for tokeng)Token retentionh)Wait forreceiving
solicitation framei)Batch transmit
solicitation framej)Transmit asolicitation framek)Transmit participation request
frame
─

─
=> d)

─

─

1) next node = self nodeStart token retention Tm
2) Only the self node in the network
Start joining token detection Tm───- Transmit participation request
frame- Start token watchdog Tm- Start solicitation frametransmission waiting Tm=> g)1) next node = self nodeStart token retention Tm
2) Only the self node in the
network
Start joining token detection
Tm
When 1) => h)When 2) => b)

─

─

─

─

─

─

─

─

─

─

─

─

─

When 1) => h)When 2) => b)

– 191 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State

Event
Participation request acceptancetimeout(PAT timeout)

Three circulation waiting timeout

─

─

─

─

─

─

─

Confirm the smallest node
number a)1) self node = smallset nodeStart token retention Tm2) self node ≠smallest nodeStart token watchdog Tm
Start solicitation frametransmission waiting Tm3) the self node alone and it is
not a flexible setting masterStart joining token detectionTm4) the self node alone and it is a
flexible setting masterStart solicitation frametransmission waiting Tm
When 1) => h)When 2) => g)When 3) => b)
When 4) => j)

─

─

─

Transmission of trigger timeout
Wait forinitialization from─
the upper layera)Detect joining
token
─
b)
Wait for trigger - Transmit trigger
frame- Start participating transmission Tm
transmission- Start participating acceptance Tm
waiting timec)=> d)Wait forparticipation
request frame
acceptance timed)Wait for threecirculationse)
Wait forparticipation
request frametransmissionf)Wait for tokeng)Token retentionh)Wait forreceiving
solicitation framei)Batch transmit
solicitation framej)Transmit asolicitation framek)Start joining token detection Tm
=> b)

─

─

─

─

─

─

─

─

─

─

─

─

─

─

─

─

─

─

– 192 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State
Minimum frame interval timeout

Wait forinitialization from─
the upper layera)Detect joining
token
─
b)
Wait for trigger
frame
transmission
─waiting timec)Wait forparticipation
request frame─acceptance timed)Wait for threecirculations
─e)
Wait forparticipation
request frame─transmissionf)Wait for token
─g)Token retention 1) Last transmission data
- Transmit token frame to next node
- Stop token retention Tm
2) Not last transmission data
- Transmit a frame- Start minimum frame interval Tmh)When 1) => g)When 2) => h)Wait forreceiving─
solicitation framei)Batch transmit
solicitation frame─j)Transmit asolicitation frame
k)

─

Event
Token retention timeout

Solicitation frame batch
transmission frame interval timeout(SFBTFI)

─

─

─

─

─

─

─

─

─

─

─

─

─

─

Start token watchdog Tm

─
=> g)

─

─

─

Batch transmit solicitation framec)(continued from divided
transmission with batch
transmission)
=> j)

─

─

– 193 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
State

Wait forinitializationfrom the upper
layera)Detect joining
tokenb)
Wait for trigger
frame
transmission
waiting timec)Wait forparticipation
request frame
acceptance timed)Wait for threecirculationse)
Wait forparticipation
request frametransmissionf)Wait for token

Event
Solicitation frame transmission waiting time Reception of solicitation frames Transmission of solicitation frame
timeout (SFTWT)
completed
No process
─

─

─
=> a)
Reallocate area when it is aslaveb)
=> b)

─

─

─

─

─

─

─

Reallocate area when it is aslaveb)=> b)Reallocate area when it is aslaveb)───g)Token retention When the self node is an flexible setting
masterd)-Check slaves-Transmit divided solicitation frameh)=> k)Wait forreceiving
solicitation
─
frame
i)
Batch transmit
solicitation
frame

─
=> b)
Reallocate area when it is aslaveb)
=> b)

─

─

─

IO registration
Master node status area set
─
=> b)

─

─

─

─

j)
Transmit asolicitation
frame
k)

─

1) Transmission of all solicitation
frames completedc)
No process
2) Transmission of all solicitation
frames is not completedc)
Start solicitation frame batch
transmission frame interval Tm
When 1) => b)
When 2) => j)Start solicitation frametransmission waiting Tm=> h)– 194 –JEM1479：2012

Table A.2 - FA link status transition table (Continued)
Notes"No process" exists as a status, but no process shall be performed. "-" does not exist as a status,
and no process shall be performed.
a)
Note- When the self node equal the smallest node, start the token retention Tm(THT) and shift to h).
- When the self node different the smallest node, start the token watchdog Tm(TW) and shift to g).
- When the self node alone and it is not a flexible setting master, start the joining token detection
Tm(TDT) and shift to b).
- When the self node alone and it is a flexible setting master, start solicitation frame batch
transmission frame interval(SFBTFI) and shift to j).
b)
When it is a slave node, it shifts when receiving the solicitation frame from its master (the same
master) or when the Lock ID of the solicitation frame matches.
When it is not the self master and the solicitation frame whose Lock ID does not match is received,
no process is performed.
c)
When the solicitation frame batch transmission is in progress and divided transmission of frames isin progress, the next divided frame shall be transmitted.
When a divided frame is the last divided frame, shift to b) after transmission.
d)
As for the condition to shift to the solicitation frame transmission state k), when the slave is notestablished and the refresh measurement time (RMT) is not more than 90% of the allowable refresh
cycle time (RCT) while holding a token, it shifts to k) alternately with message transmission and one
solicitation frame shall be transmitted. When RMT is larger than 90% of RCT and smaller than RCT,it shifts to k) on condition that the message or the solicitation frame was not transmitted last time,and one solicitation frame shall be transmitted. When RMT is not less than RCT, it does not shift tok), and the solicitation frame shall not be transmitted.

A.2 The State Transition of Message Transmission
A.2.1 State Definition
The state definition shall be as follows.
a)Message transmission request waiting state

The status for waiting for a request to send a message from the upper layer.
b)

Message transmission waiting state

The status after receiving a message transmission request from the upper layer and before it
obtains a token.
c)

ACK reception waiting state

The status after message is transmitted before the message acknowledge waiting time (AWT)times out

– 195 –JEM1479：2012

A.2.2 State Transition Diagram
The state transition diagram of message transmission shall be as shown in Figure A.3.

a)Wait for a
messagetransmission
requestMessage transmission request
Refer to Table
A.3 for details.
b)Wait formessagetransmission

Transmit 1 to nmessageTransmit 1 to 1 message
ResendRefer to Table
A.3 for details.
c)Wait for ACK
reception

Resending > 3 times

Receive ACK addressed to the self node

Figure A.3 - The state transition of message transmission

– 196 –JEM1479：2012
A.2.3 State Transition TableThe state transition table when transmitting a message shall be shown in Table A.3.
Table A.3 - The state transition table when transmitting a message
State

Wait for message
transmission requestfrom the upper layera)Wait for a message
transmission waiting
timeb)

Wait for ACK
receptionc)

Event
Messagetransmission
request fromthe upper
layer

Receive ACK
addressed tothe self node

AWT timeout

Obtain token

Messagetransmission
request=> b)

No process

No process

No process

=> a)

=> a)

=> a)

No process

No process

=> b)

=> b)

1) When Xa)- Transmit message- Start the waiting for ACK receptiontimer2) No process when Yb)
When 1) and 1 to n => a)When 1) and 1 to 1 => c)
When 2) =>b)

- Confirm thestate- Notify theupper layerofcompletion

1) No process shall be
performed when not having
three circulations
2) No process shall be
performed when there arethree or more circulations andthe number of resending isless than 3 times
3) Abnormality is notified to theupper layer when there arethree or more circulations andthe number of resending is 3
times or more=> a)Note a)b)

When 1) => c)
When 2) => b)
When 3) => a)

X: When any one of the following conditions is satisfied.
1) RMT≦RCT×0.9
2) RCT × 0.9 < RMT < RCT and no message was transmitted last time
Y: When any one of the following conditions is satisfied.
1) RMT≧RCT2) RCT × 0.9 < RMT < RCT and a message was transmitted last time1) No process shall be performed when
it is less than ACK waiting time2) No process shall be performed whenthe ACK waiting time timed out, there
are 3 or more circulations, and thenumber of resending is less than 3times.
3) No process shall be performed whenthe ACK waiting time timed out andthere are less than 3 circulations
4) Abnormality is notified to the upper
layer when ACK waiting time timed
out, there are 3 or more circulations,and the number of resending is 3 ormore times
When 1) => c)
When 2) => b)
When 3) => c)
When 4) => a)– 197 –JEM1479：2012

A.3 State Transition of Message Reception
A.3.1 State Definition
The state definition shall be as follows.
a)

Initial setting from the upper layer waiting state

The state for waiting for an initial setting from the upper layer.
b)

Message reception waiting state

The state after setting the initial setting from the upper layer and before receiving a message
addressed to the self node.
c)

ACK transmission waiting state

The state after receiving a message and before obtaining a token to transmit ACK.
A.3.2

State Transition Diagram

The state transition diagram of message reception shall be as shown in Figure A.4.

a)Wait for initial
setting

Initial setting fromthe upper layer
Receive 1 to n messageb)
Wait formessage
reception

Transmit ACK

Receive 1 to 1 message

Initial setting fromthe upper layer notcompleted
Receive 1 to 1 messagec)Wait for ACK
transmission

Figure A.4 - The state transition of message reception

– 198 –JEM1479：2012
A.3.3 State Transition TableThe state transition table when receiving a message shall be shown in Table A.4.
Table A.4 - The state transition table when receiving a message
State

Wait for initial settingfrom the upper layera)Wait for message
receptionb)

Wait for ACK
transmissionc)

Initial setting from theupper layer
Clear message buffer
=> b)

Event
Receive a message addressed to the self
nodeDiscard message
Request ACK (3)=> c)Sequence number confirmation (= new)
1 to 1 message
1) When the message reception buffer isfull- Request ACK (02)- Discard message2) When the format is abnormal- Request ACK (06)- Discard message
3) Version of sequence number
confirmation- Request ACK (05)
- Discard message4) Other than the above- Request ACK (01)- Notify to the upper layer.
- 1 to n message5) When the message reception buffer is
full- Discard message6) When the format is abnormal- Discard message
7) Version of sequence number
confirmation- Discard message8) Other than the above- Notify to the upper layer.
- Sequence number confirmation (= thesame message as the last time)9) 1 to 1 message- Request ACK (01)- Discard message10) 1 to n message- Discard message
1) to 4), 9) => c)5) to 8), 10) => b)

Obtain token
No process=> a)
No process=> b)
Transmit ACK
Initial setting not completed=> a)Initial setting completed =>b)

– 199 –JEM1479：2012

Appendix B(Reference)
Log data

Log data include required items and optional. Optional items can be freely decided by vendors, but
items to be implemented shall be published. The contents of the log include the followings.
a)Transmission and reception related items―

The total number of transmission at the socket part―

The total number of errors of transmission at the socket part―

The total number of reception at the socket part―

The total number of reception errors at the socket partb)

Lower layer related items―

The number of transmission timeout―

The number of discarded frames―

The number of receiving CRC error frames―

The number of receiving abnormal size framesc)Cyclic transmission related items―

Number of errors in receiving cyclic framed)Message transmission related items―

The number of times message transmission resending was over―Number of errors in receiving message frame―

The number of resending messagese)

ACK related items―

The number of ACK errorsf)Token related items―

The number of detection of duplicated token―

Number of the events of discarding token―

Number of the events of reissuing tokeng)State related items―

The number of frame waiting state―

The number of joining―

The number of self node disconnection―

The number of self node disconnection by skipped token

JEM1479：2012―– 200 –The number of recognizing disconnection of other nodes

Log information and a location shall be shown in Table B.1.
Each data is 4-octet data. Offset is indicated by 4 octets.

– 201 –JEM1479：2012

Table B.1 - Log information and location
Offset

Name

0

The total number of transmission at thesocket part
The total number of errors of transmission
at the socket part
The number of Ethernet transmission
errorsTransmission and reception related data

ImplementationRequiredTransmission and reception related data

RequiredTransmission and reception related data

Optional

12

─

─

16

─

20

─

Transmission and reception related data
(Reserved)
Transmission and reception related data
(Reserved)
Transmission and reception related data
(Reserved)
Transmission and reception related data

4
8

24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
88
92
96
100
104
108
112
116
120
124
128
132
136
140
144
148
152

Description

The total number of reception at thesocket part
The total number of reception errors at the Transmission and reception related data
socket part
The number of Ethernet reception errors
Transmission and reception related data
Transmission and reception related data─(Reserved)
Transmission and reception related data─(Reserved)
Transmission and reception related data─(Reserved)
The number of token transmission
Frame type related data
The number of cyclic frame transmission
Frame type related data
The number of 1 to 1 message
Frame type related datatransmission
The number of 1 to n message
Frame type related datatransmission
─Frame type related data (Reserved)
─
Frame type related data (Reserved)
The number of times tokens were
Frame type related data
received
Number of the events of receiving cyclic
Frame type related data
frame
The number of times 1 to 1 messages
Frame type related data
were received
The number of times 1 to n message were Frame type related data
received─
Frame type related data (Reserved)
─
Frame type related data (Reserved)
Number of errors in receiving cyclic frame Cyclic transmission related data
The number of time of cyclic address size Cyclic transmission related data
errorsThe number of cyclic CBN errors
Cyclic transmission related data
The number of cyclic TBN errors
Cyclic transmission related data
The number of cyclic BSIZE errors
Cyclic transmission related data
Detection time for error in receiving cyclic Time when a cyclic transmission receiving errora)frame
was detected─
Cyclic transmission related data (Reserved)
─
Cyclic transmission related data (Reserved)
─
Cyclic transmission related data (Reserved)
─
Cyclic transmission related data (Reserved)
─
Cyclic transmission related data (Reserved)
─
Cyclic transmission related data (Reserved)
The number of resending messages
Message transmission related data
The number of times message
Message transmission related datatransmission resending was overDetection time for the maximum refreshTime when the largest value was detected whilea)cycle
measuring the refresh cycle──Required
Required
Optional───Optional
Optional
Optional
Optional──

Optional
Optional
Optional
Optional──

Required
Optional
Optional
Optional
Optional
Optional
─
─
─
─
─
─

Required
Required
Optional

– 202 –JEM1479：2012

Table B.1 - Log information and location (Continued)
Offset

Name

156
160
164
168

─
─
─

172
176
180
184
188
192
196
200
204
208
212
216
220
224
228
232
236
240

Description

Number of errors in receiving messagea)frame
The number of message sequencenumber errors
The number of recognizing resent
message sequence numbers
Detection time for error in receivingb)message frame──The number of ACK errors
The number of ACK version of sequencenumber errors
The number of ACK sequence number
errorsThe number of ACK node number errors
The number of ACK TCD errors
─
─
─
─
─
─
─

276

The number of detection of duplicatedtoken
Number of the events of discarding token
Number of the events of reissuing token
Time when the event of discarding tokena)was detected lastTime when reissuance of token occurreda)lastTime when the token retention timeouta)event occurred last
Number of the events of token retention
timeout
Number of the events of token watchdog
timeout
Time when the token watchdog timeouta)event occurred lasta)Maximum token retention time

280

Minimum token retention time

284
288

Detection time for the maximum tokena)retention time
Total operation time292

The number of frame waiting state296

The number of joining

300

The number of self node disconnection

304

The number of self node disconnection byskipped token

244
248
252
256
260
264
268
272

a)

Implementation───Message transmission related data (Reserved)
Message transmission related data (Reserved)
Message transmission related data (Reserved)
Message transmission related data

Required

Message transmission related data

Optional

Message transmission related data

Optional

The time when a message transmission andreception error was detected
Message transmission related data (Reserved)
Message transmission related data (Reserved)
ACK related data
ACK related data

Optional

Required
Optional

ACK related data

Optional

ACK related data
ACK related data
ACK related data (Reserved)
ACK related data (Reserved)
ACK related data (Reserved)
ACK related data (Reserved)
ACK related data (Reserved)
ACK related data (Reserved)
ACK related data (Reserved)
Token related data

Optional
Optional

─
─

─
─
─
─
─
─
─

RequiredToken related data
Token related data
The time when the number of times tokens werediscarded was detected
The time when the number of times tokens werereissued was detected
The time when the number of token retention
timeout was counted up
Token related data

Required
Required
Optional

Token related data

Optional

The time when the number of token watchdog
timeout was counted up
The maximum token retention time measured after
receiving a token retention time measurement startand before it received the stop
Minimum token retention time measured after
receiving a token retention time measurement startand before it received the stop
The time when the maximum token retention time
was updated
Operation state of node, date on joining anddisengagement
Operation state of node, date on joining anddisengagement
Operation state of node, date on joining anddisengagement
Operation state of node, date on joining anddisengagement
Operation state of node, date on joining anddisengagement

Optional

Optional
Optional
Optional

Optional

Optional

Optional
Optional
Required
Required
Required
Required– 203 –JEM1479：2012

Table B.1 - Log information and location (Continued)
OffsetName

Description

308

The number of recognizing disconnectionof other nodesa)Measuring time for token retention time

Operation state of node, date on joining anddisengagement
The time from when the token retention timemeasurement started to when it was terminated
The number of tokens received during token
retention time measurement(Reserved)(Reserved)(Reserved)
The time from when the general purpose
communication data sender log measurement
started to when it was terminatedParticipation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
Participation confirmation node related data
The IP address of the general purpose
communication data sender log 1
The number of reception from the IP of the general
purpose communication data sender log 1
The IP address of the general purpose
communication data sender log 2
The number of reception from the IP of the general
purpose communication data sender log 2
The IP address of the general purpose
communication data sender log 3
The number of reception from the IP of the general
purpose communication data sender log 3
The IP address of the general purpose
communication data sender log 4
The number of reception from the IP of the general
purpose communication data sender log 4
The IP address of the general purpose
communication data sender log 5
The number of reception from the IP of the general
purpose communication data sender log 5
The IP address of the general purpose
communication data sender log 6
The number of reception from the IP of the general
purpose communication data sender log 6
The IP address of the general purpose
communication data sender log 7
The number of reception from the IP of the general
purpose communication data sender log 7
The IP address of the general purpose
communication data sender log 8
The number of reception from the IP of the general
purpose communication data sender log 8
The IP address of the general purpose
communication data sender log 9
The number of reception from the IP of the general
purpose communication data sender log 9
The IP address of the general purpose
communication data sender log 10
The number of reception from the IP of the general
purpose communication data sender log 10

312
316
320
324
328
332

Number of tokens while measuring thea)token retention time───Measuring time for general purposeb)communication data sender log

336
340
344
348
352
356
360
364
368

List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
List of participation confirmation node
b)
IP 1

372

IP 1 receive counter

376

IP 2

380

IP 2 receive counter

384

IP 3

388

IP 3 receive counter

392

IP 4

396

IP 4 receive counter

400

IP 5

404

IP 5 receive counter

408

IP 6

412

IP 6 receive counter

416

IP 7

420

IP 7 receive counter

424

IP 8

428

IP 8 receive counter

432

IP 9

436

IP 9 receive counter

440

IP 10

444

IP 10 receive counter

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

b)

ImplementationRequired
Optional
Optional───Optional

Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional

– 204 –JEM1479：2012

Table B.1 - Log information and location (Continued)
Offset

Name

448

─

Description

Vendor definition possible area related data
(Reserved)
452
Vendor definition possible area related data─(Reserved)
456
Vendor definition possible area related data─(Reserved)
460
Vendor definition possible area related data─(Reserved)
464
Vendor definition possible area related data─(Reserved)
468
Vendor definition possible area related data─(Reserved)
472
Vendor definition possible area related data─(Reserved)
476
Vendor definition possible area related data─(Reserved)
480
Vendor definition possible area related data─(Reserved)
484
Vendor definition possible area related data─(Reserved)
488
Vendor definition possible area related data─(Reserved)
492
Vendor definition possible area related data─(Reserved)
496
Vendor definition possible area related data─(Reserved)
500
Vendor definition possible area related data─(Reserved)
504
Vendor definition possible area related data─(Reserved)
508
Vendor definition possible area related data─(Reserved)a)Notes Response data for token retention time measurementb)Response data for general purpose communication data sender log measurement

Implementation
─
─
─
─
─
─
─
─
─
─
─
─
─
─
─
─

– 205 –JEM1479：2012

Appendix C(Reference)Port Number List
Table C.1 - Port number list
Functoins
Receive token framesReceive cyclic framesReceive message framesReceive trigger framesReceive participation request framesReceive solicitation frames
Transmit FA link protocol
Device level network
Transmit solicitation frames
General purpose command server
Receive general purpose command
Transmit general purpose command
FA link protocol

Protocol types
UDP

Port numbers
55 000UDP
UDP

55 00155 002UDP
UDP
TCP/UDPTCP/UDP55 00355 00355 00455 004