Reading the 3E frame byte by byte (binary / ASCII)

A 3E frame request has three parts: where it goes (the destination), how many bytes follow (the length), and what you want done (the command and its data). This article walks through a binary message from start to finish, using the manual’s example of reading M100–M131 in word units.

What a request contains

A binary 3E frame request is laid out in this order. The values are for accessing the PLC you are connected to.

Field	Bytes	Value	On the wire
Subheader	2	3E request	50 00
Network No.	1	Own station	00
PC No. (destination station)	1	Own station	FF
Destination module I/O No.	2	03FF (own CPU)	FF 03
Destination module station No.	1	No multidrop	00
Request data length	2	Bytes from the monitoring timer to the end	e.g. 0C 00
Monitoring timer	2	In units of 250 ms	e.g. 10 00 (4 s)
Command	2	0401 for batch read	01 04
Subcommand	2	0000 for word units	00 00
Request data	varies	Defined per command

The four destination fields (network No. through destination module station No.) are always 00 FF FF 03 00 when you access your own station. Some cases differ — the second CPU of a multi-CPU system uses I/O No. 03E1, for instance — but these values are enough to start.

The monitoring timer is how long the PLC may take to finish. 0000 means wait indefinitely. For access to your own station the manual recommends 0001–0028 (0.25–10 s).

Reading an actual message

In the manual’s example, the 32 points M100–M131 are read in word units as 2 words. The request is these 21 bytes:

50 00 Subheader 3E request

Destination

00 Network No. own station

FF PC No. own station

FF 03 I/O No. 03FF

00 Station No.

0C 00 Request data length = 12 bytes

10 00 Monitoring timer 16 × 250 ms = 4 s

What to do

01 04 Command 0401 batch read

00 00 Subcommand word units

Request data

64 00 00 Head device 100

90 Device code M

02 00 Points 2 words

The tail, 64 00 00 90 02 00, is the batch read command’s own data:

• 64 00 00: the head device number — 100 in hex is 64, written in 3 bytes
• 90: the device code; M is 90
• 02 00: the number of points, 2 words

The request data length 0C 00 is 12 bytes: timer (2) + command (2) + subcommand (2) + request data (6) = 12.

Binary puts the low byte first

The byte order is where most people trip. In binary, any value of two or more bytes is sent low byte first (little endian).

• Command 0401 is sent as 01 04
• I/O No. 03FF is sent as FF 03
• Device number 100 (000064 in hex) is sent as 64 00 00

Decimal-numbered devices such as D and M are converted to hex before sending.

The response

The PLC answers like this:

D0 00 Subheader 3E response

Destination (echoed)

00 Network No. own station

FF PC No. own station

FF 03 I/O No. 03FF

00 Station No.

06 00 Response data length = 6 bytes

00 00 End code normal completion

Data read

34 12 M100〜M115 1234H

02 00 M116〜M131 0002H

The response subheader is D0 00, and the four destination fields echo the request.

The response data length 06 00 counts from the end code to the end: end code (2) + data (4) = 6.

An end code of 00 00 means normal completion. Anything else is an error; how to read it is covered in the error code article.

The data 34 12 02 00 is also low byte first per word, so M100–M115 is 1234 and M116–M131 is 0002.

The ASCII variant

Sent in ASCII code, the same read turns every field into hex text, written most significant digit first.

5000 Subheader

Destination

00 Network No.

FF PC No.

03FF I/O No.

00 Station No.

0018 Request data length = 24 chars

0010 Monitoring timer

What to do

0401 Command

0000 Subcommand

Request data

M* Device code

000100 Head device stays decimal

0002 Points

D000 Subheader

Destination

00 Network No.

FF PC No.

03FF I/O No.

00 Station No.

000C Response data length = 12 chars

0000 End code

Data read

1234 M100〜M115

0002 M116〜M131

Three things change:

1. The order flips: the command is simply the text 0401
2. The width doubles: 1-byte fields take 2 characters, 2-byte fields take 4
3. Devices are written differently: the device code is its 2-character symbol such as M*, and the device number takes 6 digits such as 000100. Unlike binary, decimal devices like M and D stay in decimal

The request data length also counts characters: timer (4) + everything after it (20) = 24, so 0018.

ASCII is easier to read by eye, but carries about twice as much data as binary.

Device codes and subcommands

The device code identifies the kind of device. The common ones:

Device	Code	Device	Code
X (input)	9C	D (data register)	A8
Y (output)	9D	W (link register)	B4
M (internal relay)	90	R (file register)	AF
L (latch relay)	92	ZR (file register)	B0
B (link relay)	A0	TN (timer current value)	C2
SM (special relay)	91	SD (special register)	A9

For MELSEC iQ-R you can also use subcommands 0002 (word units) and 0003 (bit units). In that form the device number takes 4 bytes and the device code 2 bytes (A8 00 for D). The Q / L subcommands 0000 / 0001 still work on iQ-R for compatibility, but devices added in iQ-R, such as long timers, can only be specified with 0002 / 0003.

There is a limit per request

A batch read (0401) can read up to 960 points in word units. In bit units the limit is 7168 points in binary and 3584 in ASCII. To read more, split the request.

A 4E frame just adds a serial number

A 4E frame is a 3E frame whose subheader grows to 6 bytes.

54 00 Subheader 4E request

34 12 Serial No. 1234H (any)

00 00 Fixed

… the rest is the same as 3E

The serial number you put in a request comes back unchanged in its response, so you can match responses to requests when several are outstanding. The response subheader is D4 00.

The next article covers what to do when the end code is not zero — that is, when an error comes back.

• Reading MC protocol error codes