An HMI that lists an S7-300/400 Ethernet driver talks to an S7-1200 with no separate driver and no gateway. Configure that driver to the PLC address, make the data blocks standard, allow external access, then verify one read and one write. Modbus TCP is the fallback, because it reconfigures both ends and remaps every tag.
An HMI whose driver list shows no S7-1200 entry still talks to one. Use the panel's S7-300/400 Ethernet driver: the S7-1200 answers those S7 requests over Ethernet, through one switch, with no gateway and no added hardware. The panel software's help system covers the configuration under topic CM209, from the driver fields to the tag address syntax. Modbus TCP also works, and the S7-1200 can serve it from its own program, but it costs a PLC program change and a full remap of every tag on both ends. Treat it as the fallback and test the S7 driver first.
What the S7-300/400 Ethernet driver does
The panel is the client. It sends S7 read and write requests over TCP, and the S7-1200 is the server that answers them. The requests ride TCP port 102. The driver decides how each request is formed and how panel tags map to PLC addresses, so the driver choice and the tag syntax move together. It is the same job as matching an HMI driver to a PLC Ethernet interface on one switch, with one wrinkle: the driver name says 300/400 while the controller is a 1200.
That mismatch is safe. The S7-1200 answers the classic S7 request format, and integration write-ups for third-party panels on the S7-1200 document this same driver, with standard data block addressing and a workaround for timer and counter values. The serial S7-200 entries in the same list are not a route to a 1200 on Ethernet.
Two settings on the PLC side gate the exchange, and both ship closed:
- External PUT/GET access. Out of the box the CPU refuses S7 reads and writes from another device. The engineering project turns that access on in the CPU's protection settings, then you download. The controller vendor's S7 communication guide documents the setting.
- Block access type. Data blocks default to optimized access, which this classic S7 path cannot read. Each block the panel touches needs standard access, then a download.
On recent controller firmware the CPU can also require protected engineering and HMI sessions; a panel on this classic driver needs the standard session type left available.
What you need
- The panel project and its software, with the S7-300/400 Ethernet driver in the driver list.
- The S7-1200's engineering project, and whoever owns it: two of the changes live in the PLC, not the panel.
- One Ethernet switch, with cabling for panel, PLC and the engineering computer.
- An address plan that puts panel and PLC on one subnet.
- Two known values, one to read and one to write.
- Help topic CM209 open beside the project.
Set up the connection
- Plan the addresses. Put the panel and the PLC on one subnet and write the numbers down; the example below uses 192.168.10.40 and 192.168.10.5.
- Open the panel project's PLC communication settings and select the S7-300/400 Ethernet driver.
- Enter the S7-1200's address as the destination. Fill the remaining fields the driver asks for from CM209, which lists them for this connection.
- In the PLC project, allow PUT/GET communication in the CPU's protection settings and download.
- Open each data block the panel touches, set its access to standard, and download.
- For timer and counter values the panel displays, copy each value into a word in a data block and point the tag at that word.
- Walk every tag in the project: address and data type valid under this driver, per the CM209 address syntax.
- Download the panel project and run the read test, then the write test.
Example: one panel, one S7-1200, one switch
A packaging line panel at 192.168.10.40, mask 255.255.255.0, with the S7-1200 at 192.168.10.5:
- 192.168.10.40 AND 255.255.255.0 = 192.168.10.0
- 192.168.10.5 AND 255.255.255.0 = 192.168.10.0
Same network on both ends, so one switch carries the panel, the PLC and the engineering computer, and no router is in the path. Give the ping 4 replies and about 10 seconds; anything slower than 10 ms round trip on a 3-node network points at a duplex or cable fault before it points at the driver.
From the engineering computer, test TCP port 102 at 192.168.10.5. It answers within about 2 seconds, so the path accepts S7 connections.
Read test: force the integer at DB12.DBW0, data block 12 word 0, to 3742. The panel shows 3742 within its update cycle of 1 second. Force 3743 and the panel follows. Both values sit inside a 16-bit signed integer, whose top is 32767. A shift counter that will pass 32767 needs a 32-bit double integer, or the read turns negative above the limit.
Write test: send 500 to a spare word nothing else uses, DB30.DBW2. At the PLC, DB30.DBW2 reads 500. Back at the panel, the object shows 500. That single pass proves the path, the access setting, the block, the tag and the type.
How to check it worked
A read passes when the displayed value follows a change you force at the PLC. A number that never moves points at the tag, not the cable. A write passes when the PLC holds the value you sent and the panel reads it back the same way.
One good value does not clear the project. Exercise at least one tag on every screen and each alarm, because they hold different addresses and types; on a project with 60 tags, plan 30 minutes for the walk-through.
Write your test values to spare words only, never to an output that can move the machine.
If the first test fails
Work the path in order before changing protocols:
| What you see | First check |
|---|---|
| No link light at either end | Cable or switch port. Swap both before touching software. |
| Ping passes, the driver test fails | Test TCP port 102 at the PLC address, confirm the driver selection and PUT/GET access, then follow an HMI protocol test that fails while ping passes through its recovery steps. |
| The port test to 102 passes, the panel still shows offline | Run the checks for a red offline link indicator when the TCP port test passes before replacing hardware. |
| Connection up, some tags error or read zero | Block access or address syntax. Confirm the block is standard, not optimized, and the address matches the CM209 syntax. |
| Reads correct, writes refused | The tag's write property in the project, then the CPU's protection settings. HMI write errors while PLC reads still work often start at a protection or key state, so clear that first. |
When Modbus TCP is the better choice
The S7-1200 serves Modbus TCP from its own program through the vendor's Modbus instructions, so the answer on hardware is yes: none is needed. The price is engineering time on both ends. The PLC program must expose each value at a register address, the panel project moves to a Modbus TCP master driver, and every tag is remapped with its data type translated, a 32-bit value spread across two registers being the usual trap. Before you trust the numbers, put the mapping through the same checks you would use to test a Modbus TCP gateway before you trust the data.
Pick Modbus TCP when the panel is serial-only with no S7 Ethernet driver, when the data blocks cannot be rebuilt as standard, or when the site already standardizes on Modbus. Otherwise the S7-300/400 driver reaches the same data with no PLC program changes beyond the access settings.
Recommendation: configure the S7-300/400 Ethernet driver to the S7-1200's address, enable PUT/GET access, set the read blocks to standard access, and verify one read and one write before the panel goes back to operators. Move to Modbus TCP only when the panel has no S7 Ethernet driver or the blocks cannot be rebuilt; then budget the remap of every tag on both ends.
Questions
Is there a separate S7-1200 driver for the panel?
No, and none is needed. Driver lists of that generation carry serial and Ethernet entries for the S7-200 and the S7-300/400 and nothing marked 1200. The S7-300/400 Ethernet entry is the documented path, because the S7-1200 answers those same S7 requests. Configure it per help topic CM209.
Can the S7-1200 speak Modbus TCP without extra hardware?
Yes. The controller runs Modbus TCP from its program through the vendor's Modbus instructions, so there is no gateway to buy. You pay in engineering time: each value must be exposed at a register address in the PLC program, the panel project moves to a Modbus TCP master driver, and every tag is remapped and retested.
The panel shows numbers that do not match the PLC. What is wrong?
The connection is working; the mapping is not. Compare one known value at both ends, then check the tag's data type and offset. A 32-bit value read as two 16-bit words, or a word started one byte off, shifts every number on the screen. Fix the tag and leave the connection as it is.
Does the S7-1200 set aside a connection for the panel?
Yes. The vendor's controller comparison notes state that the system automatically reserves connections for basic communication such as a programming device or an HMI, so a single panel needs no connection resource configured. If several panels and controllers share one PLC, check the CPU's connection count in its documentation before adding more.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.