An OPC server that lacks native Siemens S7 protocol support cannot access data blocks merely because the controllers are reachable over Ethernet. Configure a Modbus TCP server interface in each PLC, map the required DB variables into a defined Modbus data map, and connect arOPC as the Modbus client. Use an integrated PN interface when the exact CPU supports the required implementation; otherwise select a compatible communication processor and account for the required software license.
Symptom interpretation
The initial symptom is a reachable S7-300 or S7-400 network node with no usable DB read or write path from arOPC. Ethernet reachability proves only that IP packets can reach an interface. It does not prove that the OPC server and PLC share an application protocol.
Three observations separate the likely cases:
| Observation | Meaning | Next action |
|---|---|---|
| The PLC responds to network diagnostics, but arOPC cannot create Siemens DB tags | The physical and network layers work, but arOPC has no native Siemens protocol driver | Add a protocol that both endpoints implement, such as Modbus TCP |
| Remote I/O communicates with the PLC over Profibus | Profibus is the PLC-to-I/O path, not an automatic OPC access path | Leave the I/O architecture intact and create a separate northbound Modbus TCP connection |
| A direct Siemens connection over Ethernet or MPI is proposed | The transport exists, but arOPC does not implement that direct Siemens exchange | Use the PLC as a protocol gateway through program logic or a supported library |
Reading is not fundamentally different from writing at the connection layer. Both operations require a functioning Modbus server in the PLC, a documented register map, compatible data types, and permission for the relevant data area. Writing adds application-level validation because an incorrect external value can change machine behavior.
Protocol boundary
The term protocol boundary here means the point where Siemens DB semantics must be translated into Modbus objects. A DB address is meaningful to the Siemens CPU and engineering software, while a Modbus client operates on coils, discrete inputs, input registers, and holding registers. arOPC cannot place a native DB reference into a Modbus request and expect the PLC to interpret it.
The PLC-side implementation therefore performs two jobs. It exposes a Modbus TCP server, historically called a Modbus slave, and it transfers values between Modbus-accessible storage and the application DBs. arOPC acts as the Modbus client, while Simple-Scada acts as the OPC client above arOPC.
This architecture also explains why attaching a PLC to Ethernet is insufficient. Ethernet supplies the link layer, IP supplies routing, and TCP supplies a reliable byte stream. The application endpoints must still agree on Modbus TCP rather than a Siemens-native protocol.
Connection architecture
| Layer | Role | Required configuration | Failure indication |
|---|---|---|---|
| Simple-Scada | OPC client and operator interface | OPC tag name, access direction, engineering conversion, and command logic | The command is not submitted or the displayed value is interpreted incorrectly |
| arOPC | OPC server and Modbus TCP client | PLC endpoint, unit selection where applicable, register address, command, type, and read/write access | Connection errors, Modbus exception responses, or bad tag quality |
| S7-300 or S7-400 | Modbus TCP server and data translator | Compatible communication interface, licensed or third-party library, connection resources, and DB/register mapping | No server response, rejected requests, or unchanged DB data |
| PLC application | Owner of machine data | Range checks, command acceptance, status feedback, and controlled transfer to process variables | The register changes but the controlled variable does not, or a command is rejected |
The Profibus peripheral network does not need to become part of the OPC route. The PLC can continue exchanging process I/O over Profibus while serving selected values over Modbus TCP on Ethernet. This separation prevents a supervisory client from depending on the fieldbus topology.
Controller capability and implementation selection
Start with the complete CPU marking and Siemens order number in the form 6ES7-xxx. The family name alone does not decide whether the installed CPU has an integrated PN interface, whether that interface can run the selected Modbus library, or whether a separate communication processor is required.
- Record the CPU order number, installed communication processors, and available Ethernet interfaces from the hardware configuration.
- Determine whether the integrated PN interface can host the selected Modbus TCP server implementation.
- If the CPU lacks a usable onboard path, evaluate a compatible external processor. The identified S7-300 route uses a
CP 343; an S7-400 route may use aCP 443. - Check CPU, communication processor, and library compatibility in the relevant product documentation. Also check the connection resources and memory required by the library.
- Account for licensing before commissioning. The Siemens implementation identified for this application requires a software license.
A third-party CMC Modbus library is another implementation route for S7-300/S7-400(H). It provides Modbus RTU, Modbus TCP, and Modbus RTU over TCP operation through CP 343, CP 443, or an integrated PN interface without a hardware dongle. Evaluate its CPU coverage, engineering workflow, license terms, maintainability, and support lifecycle against the plant requirements.
Do not purchase a communication processor before checking the exact CPU. An external module adds hardware, configuration, connection resources, and another failure point; it is unnecessary when the installed CPU and selected library can use the integrated interface.
DB-to-register data model
Build the data map before configuring OPC tags. Each exposed variable needs one authoritative definition covering its PLC source, Modbus object, register offset, width, access direction, representation, and validity rule.
| Map field | Engineering decision | Verification source |
|---|---|---|
| PLC source or destination | Select the DB variable owned by the control program | PLC symbol table and DB declaration |
| Modbus object | Use a writable holding-register area for writable numeric data; use a read-only object where writes are prohibited | PLC library interface and arOPC tag command |
| Register address | Define the transmitted offset and document whether the human-readable map starts at zero or one | Packet log and register-map convention |
| Width | Reserve every register occupied by the value | PLC type size and arOPC type size |
| Byte and word order | Specify the order used for multi-byte and multi-register values | Known test pattern read from both endpoints |
| Access | Classify the point as read-only, write-only, or read/write | Process design and PLC command logic |
| Validity | Define range, state, interlock, and command-acceptance rules | PLC application specification |
Keep externally writable command data separate from internal process state. A sound design writes incoming values to a staging area, checks the range and operating state, then transfers an accepted command to the control variable. Publish an acceptance or status value for SCADA readback. This prevents a communications client from bypassing PLC interlocks.
Address and data-type discipline
Modbus address notation is a recurring source of valid connections with invalid data. Some device documents number the first register as 1, while the protocol request carries a zero-based offset. When the published map starts at 1 and arOPC expects the transmitted offset, enter the documented register number minus 1.
An ILLEGAL DATA ADDRESS (2) response means the server received the request but rejected the addressed range. Check the starting address, object type, command, and complete request length. A starting register can be valid while the request still fails because the selected data type extends beyond the implemented range.
Use command 3 for a holding-register read and command 4 for an input-register read when those objects match the PLC map. Changing between the commands cannot repair an offset or length error. Test one tag at a time so that block optimization does not hide which range caused the exception.
Match type width rather than relying on similar type names. The reported arOPC type named ShortInt occupies two bytes; the installation description also used the label SmallInt. Treat the label as ambiguous until the tag editor shows the actual width, then match that width and signedness to the PLC declaration.
A two-byte mismatch often appears at a numerical boundary or when the next byte is overwritten. Multi-register values add a word-order decision. Prove the representation with known positive, negative, and non-symmetric hexadecimal patterns rather than accepting a single value such as 0 or 1.
Configuration procedure
- Inventory the PLC. Record the full CPU order number, Ethernet interface, communication processor, existing connection use, and the DB variables required now and for future writes.
-
Select the PLC-side implementation. Choose the integrated PN interface or the compatible
CP 343/CP 443path. Install and license the selected library according to its product documentation. - Create the Modbus server data areas. Allocate non-overlapping objects for readable status, commands, and command feedback. Define address origin, width, signedness, byte order, word order, and access direction in one controlled register map.
- Add transfer logic. Copy approved DB status values into the server map. For writes, receive data in a staging area, validate it, apply it to the application DB, and publish the accepted value or rejection status.
- Configure the network endpoint. Assign arOPC to the PLC interface hosting the Modbus server. Verify that the PLC is the server/slave and arOPC is the client/master; two masters or two clients cannot establish the required request-response exchange.
- Create one arOPC read tag. Enter the mapped object, transmitted address, command, and matching type. Start with a value that can be changed safely from PLC logic.
-
Resolve address origin. If the tag returns
ILLEGAL DATA ADDRESS (2), compare the request offset with the map. Where the map begins at 1, test the documented address minus 1. - Add the remaining read tags. Introduce them in small groups and inspect the request log after each group. This exposes overlaps and requests that cross an implemented range.
- Add controlled writes. Begin with a staging value that has no direct process consequence. Confirm the OPC tag access setting, PLC validation, application transfer, and readback before enabling operational commands.
- Archive the baseline. Save the PLC project, register map, arOPC configuration, license record, and acceptance readings together. Protect arOPC configuration editing with its password mechanism and protect the configuration file against replacement through operating-system permissions.
Functional verification
- Check 1: Network session. Expect arOPC to report an established device connection without repeated reconnects.
- Check 2: Single-register read. Force or generate a safe known value in the mapped PLC data area. Expect the arOPC tag to show the same value with good quality.
- Check 3: Address origin. Compare the request offset in the expanded packet log with the controlled register map. Expect a one-based published register to appear as an offset reduced by one when that convention applies.
- Check 4: Type representation. Test values that reveal sign, byte, and word ordering. Expect identical numerical interpretation in the PLC, arOPC, and SCADA.
- Check 5: Write path. Submit a safe command from SCADA. Expect the PLC staging location to receive it, the validation logic to accept or reject it deterministically, and the feedback tag to report the result.
- Check 6: Restart behavior. Restart the communications applications in the approved sequence. Expect reconnection without manual tag edits, stale commands, or unintended application writes.
The value displayed in arOPC after a SCADA write is normally the value read back from the PLC, not a visible copy of the pending SCADA request. The sequence is SCADA submission, OPC-to-PLC write, PLC processing, and OPC readback. Locate delays by timestamping those four boundaries rather than treating the displayed tag as proof that SCADA has or has not sent the command.
Recurring implementation pitfalls
| Pitfall | Mechanism | Corrective action |
|---|---|---|
| Treating Ethernet as the application protocol | IP reachability exists without a common PLC protocol | Run a Modbus TCP server in the PLC and configure arOPC as its client |
| Expecting direct DB addressing through Modbus | Modbus requests contain object offsets, not Siemens DB references | Maintain an explicit DB-to-register transfer map |
| Assuming all S7-300/S7-400 CPUs have the same capability | Interfaces and compatible library paths vary by installed hardware | Decide from the complete 6ES7-xxx order number |
| Adding a communication processor automatically | The integrated PN interface may already provide the required route | Check CPU and library compatibility before selecting hardware |
| Mixing one-based references with zero-based offsets | The request targets the next register or an invalid range | Document the convention and subtract 1 where required |
| Choosing a type by name alone | The OPC width, signedness, or register count differs from the PLC declaration | Compare byte width and test boundary values |
| Writing related registers as independent commands | The PLC can observe a partially updated multi-register value | Use one contiguous multi-register transaction or a PLC-side staging handshake |
| Blaming SCADA from the OPC display | The display represents PLC readback after the write cycle | Use expanded logs and PLC monitoring to timestamp each boundary |
arOPC can combine three sequential tag writes issued from one Simple-Scada script into one Modbus packet. That behavior is useful when a device or PLC interface requires a contiguous three-register write with function 0x10. Confirm the resulting packet in the expanded log, keep the registers contiguous, and use PLC-side staging when the application requires atomic acceptance.
If a device responds but returns ILLEGAL DATA ADDRESS (2), reduce the configuration to one tag. Verify address, type width, and command before adding optimization or grouped requests. If the single request matches the documented map and still fails, capture the expanded packet log and compare the implemented PLC range with the library configuration.
Final acceptance checks
- Check 7: Read coverage. Exercise the lowest and highest configured addresses. Expect valid responses without requests crossing outside the mapped areas.
- Check 8: Write rejection. Submit a value outside the permitted process range. Expect the PLC to reject it, retain the controlled value, and publish a rejection indication.
- Check 9: Multi-register consistency. Write a non-symmetric multi-register test pattern. Expect one coherent value at the PLC with the documented byte and word order.
- Check 10: Role recovery. Interrupt and restore the Ethernet path. Expect arOPC to reconnect as client and the PLC to resume serving requests without replaying a stale command.
- Check 11: End-to-end readback. Issue one approved command from Simple-Scada, observe its acceptance in PLC logic, and read the resulting status through arOPC. Expect the SCADA indication, OPC tag, mapped Modbus object, and application DB value to agree.
Frequently asked questions
How do I connect arOPC to an S7-300 or S7-400?
Configure a Modbus TCP server in the PLC, map the required DB values to Modbus objects, and configure arOPC as the Modbus client. arOPC does not provide the direct native Siemens DB path described here.
How do I know whether I need a CP 343 or CP 443?
Read the complete CPU order number in the form 6ES7-xxx and check whether its integrated PN interface can run the selected Modbus TCP implementation. Use a compatible CP 343 or CP 443 path only when the onboard interface cannot provide it.
How do I fix ILLEGAL DATA ADDRESS (2) in arOPC?
Poll one tag and verify its object, command, start offset, and complete data width. If the published register numbering begins at 1 but arOPC expects a zero-based offset, enter the documented address minus 1.
How do I write several Modbus registers as one command?
Place contiguous tags in one Simple-Scada script and issue their writes sequentially; arOPC can form one packet for the three-register case described, using 0x10. Confirm the packet in the expanded log and use PLC staging when partial updates are unacceptable.
How do I verify the complete S7 OPC write path?
Write one safe command from Simple-Scada, observe it in the PLC staging area, confirm application acceptance, and read the resulting status back through arOPC. The final expected reading is the same accepted value in the application DB, mapped Modbus object, OPC tag, and SCADA indication.