Separate the PLC's internal structures from its Ethernet interface. Use an explicit registry to map stable public names to selected values, return typed results with clear status, and validate every permitted write through application logic.
A PLC structure organizes values inside the program. It does not, by itself, define how an Ethernet client discovers those values, requests one by name or changes a setting. For that, you need an explicit parameter interface: a registry of permitted values, a request format, lookup rules and responses that distinguish success from failure.
Keep that interface separate from the control program's internal layout. You can then reorganize function blocks without changing every connected client, and reject invalid requests before they affect machine behavior.
Separate the data model from the network interface
There are three distinct parts to the design:
- Internal data: structures, function block instances and variables used by the PLC program.
- Parameter registry: the values deliberately exposed to external clients, with their public names and permissions.
- Network handler: the documented communication mechanism that receives requests and returns responses.
An internal expression such as PumpA.ElapsedRunTime selects a known member in the PLC program. A client sending the text PumpA and ElapsedRunTime is doing something different. Those strings are input data. A resolver must match them to an approved entry before reading a value.
Some controller environments provide documented symbolic access or parameter services. Others require an application-defined interface. Check the controller's supported protocols, libraries and resource limits before choosing an implementation. A structure declaration alone does not establish a network service.
Also decide whether names are needed at all. A fixed monitoring application might use stable numeric identifiers. A commissioning application might need a browsable directory. Both still need a defined contract between the PLC and the client.
Make the registry the public contract
Expose only the parameters the application needs. Do not treat every internal variable as a public parameter.
A useful registry entry contains enough information to resolve a request and describe its value accurately:
| Registry field | What it defines | Example meaning |
|---|---|---|
| Public key | Unique group and parameter pair | PumpA, ElapsedRunTime |
| Stable identifier | Optional alternative to text lookup | An identifier that remains unchanged across compatible revisions |
| Data type | The representation clients must expect | Boolean, signed integer or floating-point value |
| Units and scaling | How to interpret the number | Seconds, or an integer representing tenths of a degree |
| Access | Which operations are permitted | Read-only or controlled read/write |
| Read handler | Where the current value comes from | A specific structure member or calculated value |
| Write handler | How an allowed change is validated | Application logic for a requested setpoint |
| Limits | Conditions that restrict a write | Engineering range and permitted machine state |
This is a conceptual design, not a requirement to store function pointers or variable addresses. On a small PLC, explicit selection logic may be easier to implement and review than a generic table-driven system.
Keep the public names stable even if internal names change. The external key PumpA.ElapsedRunTime could remain unchanged while its read handler is updated to use a different internal structure.
Do not expose raw memory addresses as a substitute for a registry. They tie clients to the implementation and can make unintended data accessible.
Define lookup rules before writing the resolver
A name-based interface needs rules that leave no room for guessing.
Define whether names are case-sensitive, how long they may be and which characters are accepted. State whether whitespace is significant. If group and parameter arrive as separate fields, retain that separation rather than inventing ambiguous dotted paths.
Each complete key must resolve to exactly one entry. Two devices can both have a Setpoint, but the group or instance identifier must distinguish them. Duplicate complete keys should be rejected when the registry is built or checked.
For a small set of parameters, explicit branches are reasonable. For a larger set, a searchable registry can reduce repeated logic. Either approach should have the same behavior:
- A known key selects only its registered value.
- An unknown key produces a failure status.
- An unsupported operation does not fall back to another operation.
- A failed lookup never returns a default value disguised as a successful read.
Avoid fallback matching such as returning the first Setpoint found when the group is missing. That can produce a plausible value from the wrong device, which is harder to diagnose than a clear rejection.
Bound request lengths and processing work. A malformed packet should not cause an unbounded search or interfere with time-critical control tasks.
Return status separately from the value
A numeric result alone cannot describe a parameter read. Zero might be a valid value, an initialization value or the result of an unsuccessful conversion.
Define a response envelope containing a request identifier, operation status and, on success, a typed payload. Include an interface version so incompatible clients can be rejected clearly.
The following statuses are examples for an application-defined interface, not names prescribed by an Ethernet standard:
| Status | Meaning for the client |
|---|---|
| Success | The requested operation completed as defined |
| Invalid request | The message format or required fields are incorrect |
| Unknown parameter | The complete key is not registered |
| Access denied | The client is not permitted to perform the operation |
| Type mismatch | The supplied value has the wrong representation |
| Out of range | The value is outside the permitted engineering limits |
| State rejected | The current machine state does not permit the change |
| Value unavailable | The key exists, but a usable value is not currently available |
| Version mismatch | The client and interface versions are incompatible |
A failed response must not accidentally include a previous successful payload. Define which fields are valid for each status, and have the client honor those rules.
For values that can become stale, provide quality information and an age or timestamp with a documented time basis. A successful lookup means the name resolved; it does not necessarily mean the underlying measurement is current.
Document durations separately from clock times and calendar dates. Also define numeric widths, string encoding and byte order wherever the selected protocol does not already define them.
Build browsing from the same registry
If clients need to discover parameters, generate the directory from the registry used by the resolver. Maintaining a separate handwritten list creates two places that can disagree.
A directory entry should identify the key, type, units and permitted operations. It should not imply that a value is writable simply because it is visible.
Large directories need bounded responses. Define pagination, an end-of-list indication and a registry revision. If the registry can change during browsing, the client needs a way to detect that its pages came from different revisions and restart the listing.
Apply access permissions to directory results as well as reads and writes. Browsing should not reveal restricted entries merely because it returns metadata rather than live values.
If discovery is unnecessary, leave it out. A documented fixed parameter set can be simpler to maintain than a directory service.
Treat writes as validated requests
A network write should request an application change, not directly assign arbitrary data into control memory.
Validate the request format, client permission, parameter access mode and incoming type first. Then check engineering limits and the conditions that apply at the point of use. A valid setpoint range does not establish that changing the setpoint is appropriate in every machine state.
Reject invalid values explicitly. Do not silently convert text to a number, discard fractional data or clamp an excessive request unless that behavior is part of the documented interface. For floating-point inputs, handle non-finite values explicitly.
Where necessary, pass an approved request to control logic for application at a defined point in the PLC cycle. Distinguish accepted from applied if those events happen separately. The client should be able to read back the effective value or obtain a completion result.
Related settings may need a staged update followed by one validated commit. Otherwise, individually valid writes can briefly create an invalid combination. If the controller cannot support such an update, document the limitation instead of implying atomic behavior.
Retries also need rules. Repeating a setpoint assignment differs from repeating a command that starts an action. A request identifier only prevents duplicate execution if the application actually records and handles duplicates. After a timeout, reconcile the result rather than blindly repeating a non-idempotent command.
Keep safety functions and interlocks independent of this general parameter service. Network permission is not a safety function, and the interface must not bypass protective logic. Use supported authentication and access controls, restrict network reachability and avoid exposing the service directly to the public internet.
Check the mapping and the exchange independently
Verify the registry before diagnosing the network. Give similar parameters in different instances distinct test values so an incorrect mapping is easy to spot.
Useful checks include:
- Every advertised key resolves to the intended value and type.
- Duplicate keys are detected.
- Unknown groups and parameters return clear failures.
- Read-only parameters reject writes.
- Values at and beyond each permitted boundary produce the expected result.
- A rejected request cannot reuse an earlier response's payload.
- Interrupted exchanges and repeated requests follow the documented retry rules.
- Related values are coherent when the client needs a common snapshot.
Then check the complete exchange: received key, resolved entry, selected PLC value, serialized response and client interpretation. This separates a wrong mapping from a decoding error or stale client display.
Record the interface revision with the test results. A change to a public type, unit or write behavior can break a client even when its parameter name stays the same.
Keep monitoring separate from control
A monitoring client can often use a read-only subset of the registry. That reduces write exposure and gives the display application a smaller, clearer contract.
If several readings must describe the same machine state, define a snapshot mechanism or shared sample sequence. Reading each parameter successfully in separate requests does not establish that all values came from the same control cycle.
For a downstream screen, the distinction between a live factory data display and a signage workflow matters: defining the PLC interface does not by itself provide data collection, rendering or freshness handling. Likewise, a factory status display is not an operator HMI.
The practical result is a narrow interface with predictable behavior: known names, explicit types, bounded requests and validated changes. Internal PLC structures can then evolve without becoming an accidental network contract.
Questions
Does a PLC structure automatically provide Ethernet name lookup?
No. A structure defines how values are organized inside the PLC program. External access depends on a supported communication service and a defined mapping to exposed parameters. Some environments provide documented symbolic access, while others require explicit request handling and lookup logic.
What should a PLC parameter directory contain?
Return only the parameters intentionally registered for external access. Build the directory from the same registry used for lookup, and include each entry's type, units and permitted operations. Apply access permissions to browsing, and define pagination if the list cannot fit in one bounded response.
What should a client do when a parameter write times out?
A timeout does not prove that a write failed. The controller may have applied the change before the response was lost. Define retry behavior, distinguish assignments from action commands, and use readback or a completion query to reconcile the result before repeating a potentially non-idempotent operation.
Does a successful parameter read confirm current, coherent data?
Not necessarily. Separate reads can succeed while sampling different PLC cycles. If the application needs related values to represent one state, provide a snapshot or shared sample sequence. Include quality and freshness information where a valid parameter can contain an old or unavailable measurement.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.