When an HMI, a data-collection program or host software reads and writes PLC values over the MC protocol (SLMP), you can test the communication part before the PLC arrives. PortDock PLC Simulator is a free Windows program that makes the PC answer MC protocol requests like a PLC's Ethernet port. This guide connects your program and the simulator on one PC through 127.0.0.1, and lists where people usually get stuck at first.
1. Set up the simulator
| Setting | Choose |
|---|---|
| Transport | TCP server (several clients, up to 64) or UDP — whichever your program uses |
| Frame | 3E (subheader 5000) or 4E (5400 + serial number) — same as your program |
| Data code | Binary or ASCII — same as your program |
| Bind address | 127.0.0.1 (default) — only programs on this PC can connect |
| Port | 5000 by default. That is just this program's default; the manuals do not fix a port (it is set on the PLC side) |
Pick device D at the top, enter values in D100–D102 and press «Start» (F4). Values can be entered before starting; changes while it runs apply from the next request.
2. Set up your program
- Connect to 127.0.0.1, port 5000 (whatever you set in the simulator).
- Use the same frame (3E/4E) and data code (binary/ASCII) as the simulator. If they differ, the simulator does not answer.
- Station fields: network No. 00, PC No. FF, request destination module I/O No. 03FF, station No. 00 — the connected station itself. By default the simulator answers requests for any station and echoes the request's station fields in the reply header.
- The monitoring timer is in 0.25 s units (0010 = 4 s). The simulator reads it but answers immediately.
3. First request — read 3 words from D100
50 00 00 FF FF 03 00 0C 00 10 00 01 04 00 00 64 00 00 A8 03 00
This is a 3E binary batch read (0401). «Reading an MC protocol 3E binary frame» explains each field. If the simulator holds 0x1995, 0x1202 and 0x1130 in D100–D102, the reply is:
D0 00 00 FF FF 03 00 08 00 00 00 95 19 02 12 30 11
After end code 00 00 (completed) come the values, low byte first. The same request in ASCII is «500000FF03FF000018001004010000D*0001000003». The simulator's traffic log decodes it as «0401 Read (words) D100 ×3» and «End 0000 OK · 6 bytes».
- No program yet? Send the bytes above as HEX with the client in PortDock TCP and watch the reply.
- To see whether the bytes your program sends are right, paste them into the web tool «MC Protocol (SLMP) Frame Decoder». It decodes the header and command data and shows which end code the simulator would return.
Common mistakes
| Symptom | Check |
|---|---|
| Cannot connect | Is the simulator started, and is the port the same? 127.0.0.1 accepts connections from this PC only. For an HMI on another PC, turn on «Allow other PCs to connect (0.0.0.0)» and allow the program in Windows Firewall |
| «Port already in use» | Another program (or another PortDock window) is using that port |
| Requests arrive (RX) but no reply | An EV «IGNORED» line means 3E/4E or binary/ASCII differ. Also make sure fault injection «Do not respond» is off |
| TCP and UDP mixed up | If your program sends UDP, the simulator's transport must be UDP too |
| End code C057 | The header's request data length is wrong. It counts the bytes (characters in ASCII) from the monitoring timer to the end |
| End code C059 | A command or subcommand the simulator does not implement (it has 0401, 1401, 0403, 1402, 0619, and from 0.6.0 also 0406/1406 blocks, 0801/0802 monitor, 1001–1006 remote operation and 0101 Read Type Name) |
| End code C056 | A number beyond the device size (points). Increase «Size (points)» in the simulator |
| End code C05F | «Own station requests only» is on and the station fields are not 00, FF, 03FF, 00 |
| 32-bit or float values look wrong | The lower-numbered word holds the low part (D200 low, D201 high). The default order in the simulator's «Cell settings» is CDAB |
| X/Y values land in the wrong place | X, Y, B, W and ZR are numbered in hex (X10 is the 17th from X0) — see the device numbering guide |
Test the error handling too
- «Response delay (ms)»: replies late, to exercise your timeout. With «Max delay» each request gets a random delay in that range.
- «Do not respond»: the request is processed (writes are applied) but no reply is sent — for timeout and retry handling.
- «Reply with end code»: replies with the end code you pick. Writes are not applied then.
- Targets can be narrowed by command, device, every Nth request or probability. Fault injection always starts off.
What a simulator cannot tell you
PortDock PLC Simulator follows only the message formats in the public manuals and has not been compared with real hardware. No ladder program runs, and error codes, timing, connection limits and per-model device ranges may differ. Use it to get the communication side ready, and do the final test on the real PLC. Never run it on a plant network with the same IP and port as a real PLC — it would answer in its place.
This guide is based on Mitsubishi Electric's public manuals (SLMP and MC protocol); it is not affiliated with Mitsubishi Electric.
Sources
- SLMP Reference Manual SH(NA)-080956ENG — chapter 4 message format (header, length, end code, error information), 5.2 device codes and 0401/1401/0403/1402, 5.9 loopback
- MELSEC Communication Protocol Reference Manual SH-080008 — chapter 5 Ethernet messages (3E and 4E frames)
- MELSEC iQ-R Ethernet User's Manual (Application) SH-081257ENG — 3.5 List of Error Codes — meanings of C050–C061
Published 2026-10-29