Yes—DNP3 and Modbus can run on the same gateway when it supports both protocols concurrently, the required client/server roles, and the physical interfaces your devices use. That does not automatically provide DNP3-to-Modbus translation: translation also requires explicit point mapping and defined handling of timestamps, quality, events, and commands. For a 2026 deployment, confirm these capabilities for the exact gateway model, software version, and licensed configuration.
TL;DR
A shared gateway can consolidate connectivity, but it also puts both communication paths behind the same host, power supply, and maintenance window. Decide whether that shared failure domain is acceptable before selecting hardware or configuring drivers.
Software Toolbox provides industrial connectivity software and OPC drivers. When evaluating that category, distinguish access to both protocols from an application that actually exchanges data between them. A supported-protocol list alone does not establish the required architecture.
Yes, provided the gateway explicitly supports simultaneous operation—not merely a choice between protocol modes. Your design must also distinguish collecting data from translating data. A gateway can read a DNP3 outstation and a Modbus server independently without exposing either device's data through the other protocol.
Acquisition role
Common transport choices
Data representation
Change handling
Time information
Control handling
This comparison describes protocol behavior, not a capability guarantee for any particular product. Check the implementation documentation for supported objects, function codes, transports, and limits.
For a 2026 specification, require a connection diagram showing which component initiates each session. Labels such as DNP3 support and Modbus support are insufficient without roles and direction.
Concurrent collection fits an architecture in which a supervisory application needs information from both DNP3 and Modbus equipment. The gateway acquires each source independently and exposes the resulting data through a supported interface to that application.
The advantage is separation: DNP3 acquisition does not need to imitate a Modbus register map, and Modbus acquisition does not need to imitate DNP3 event behavior. The limitation is equally clear: collection alone does not let a Modbus-only client read a DNP3 outstation.
Choose concurrent collection when your destination can consume a shared interface rather than requiring protocol-to-protocol conversion. Confirm how the destination receives quality, timestamps, and communication status; a value without its status can misrepresent a failed connection as a healthy process.
Translation fits an architecture in which one endpoint requires Modbus while the source speaks DNP3, or the reverse. The gateway must acquire data in one role and expose mapped data in another.
For example, a DNP3 master connection can acquire an outstation's measurements while a Modbus server interface exposes selected measurements as registers. The reverse direction requires the appropriate Modbus acquisition role and DNP3 outstation functionality. Neither direction follows automatically from supporting both protocol names.
Translation makes otherwise incompatible endpoints exchange selected information. Its limitation is semantic loss: a destination representation might not carry the source's event history, timestamp, or quality information unless you deliberately provide corresponding points.
Choose translation only after defining what the destination must know—not just which numerical value it must receive. Keep control translation separate from measurement translation because command acceptance and process execution are different outcomes.
Use the following sequence to turn a protocol compatibility question into a deployable design. Complete the mapping and failure policy before enabling production writes.
A useful design review follows the same path as the data: source device, acquisition connection, mapping logic, destination interface, consuming application. Every boundary needs an owner and an observable failure state.
Define the data and command paths before testing recovery behavior.
Modbus TCP conventionally uses TCP port 502. DNP3 over IP conventionally uses port 20000 for TCP or UDP, depending on the implementation and configuration. These defaults describe service endpoints; they are not instructions to permit unrestricted access.
A Modbus holding register contains 16 bits. Values spanning multiple registers therefore need an agreed register order and data representation; a successful read does not prove the decoded engineering value is correct.
For a 2026 firewall review, document actual configured ports, session initiators, destination addresses, and permitted zones. A protocol operating over TCP does not, by itself, establish encryption or peer authentication. Verify security capabilities separately from basic connectivity.
Maintain a mapping document that another engineer can review without opening the gateway editor. Include the engineering unit, valid range, scaling expression, destination address, and behavior when the source becomes unavailable.
For DNP3-to-Modbus translation, decide how the Modbus consumer learns that a value is stale or invalid. A separate status register can carry that information when the gateway and application support the agreed mapping. Do not silently substitute zero: zero can be a valid process measurement.
For Modbus-to-DNP3 translation, define how source polling drives destination updates and events. Translation cannot recover source timestamps or event history that the original Modbus data never supplied.
The right architecture depends on what information must cross the gateway and what happens when communication fails. Use these factors to review a proposed design:
For your 2026 acceptance criteria, describe measurable behavior rather than requesting a gateway that is simply fast or secure. Specify how the application recognizes unavailable data and what operators see after a restart.
Yes, DNP3 and Modbus TCP can share an Ethernet network when addressing, routing, and access rules permit the required sessions. Sharing Ethernet does not require either protocol to be converted into the other.
Network coexistence also does not justify unrestricted reachability. Limit communication to the required endpoints and assess whether control traffic belongs across each proposed zone boundary.
Do not assume DNP3 and Modbus can share a serial port or multidrop bus simply because both devices use RS-485. Use separate ports unless the gateway and connected devices explicitly document the required mixed-protocol operation.
Electrical compatibility is only one condition. Framing, device addressing, bus ownership, and response timing also determine whether the connection works correctly.
No, DNP3-to-Modbus conversion does not automatically preserve events and timestamps. Basic Modbus register access does not provide a direct equivalent for every DNP3 object or event behavior.
Preserve required metadata through an explicit, supported mapping, or deliver it through another suitable interface. If the consumer only reads the latest value, document that limitation rather than describing the result as full-fidelity conversion.
For industrial teams evaluating OPC connectivity alongside these requirements, Software Toolbox offers products including TOP Server. Evaluate that product against its current documentation and the required architecture; its name alone does not establish concurrent roles, translation behavior, or supported security features.
The evaluation advantage is a concrete connectivity scope to investigate. The constraint is that product-family membership does not replace checking the exact driver, version, and deployment configuration.
For a 2026 commissioning review, require evidence for these outcomes:
Do not accept a changing value as proof of a complete integration. Validate its meaning, status, age, and permitted direction of travel.
Can DNP3 and Modbus run on the same gateway at the same time?
Yes, when the gateway supports concurrent operation with the required roles and interfaces. Verify the exact model, software version, and licensed configuration rather than relying on a protocol list.
Does supporting both protocols mean a gateway translates between them?
No, support for both protocols does not establish protocol translation. Translation requires acquisition, destination serving, and explicit mappings between the two data representations.
Which ports do DNP3 and Modbus TCP use?
Modbus TCP conventionally uses TCP port 502, while DNP3 over IP conventionally uses port 20000 for TCP or UDP. Check the configured endpoints and allow only the required communication paths.
Can I connect DNP3 and Modbus RTU devices to one RS-485 port?
Do not assume mixed-protocol operation on one RS-485 port is supported. Use separate ports unless the gateway and connected devices explicitly document that arrangement.
Will a Modbus register retain a DNP3 timestamp?
A Modbus register does not automatically retain a DNP3 timestamp. Preserving time information requires a documented mapping and a destination application that understands it.
Can the same gateway send control commands through both protocols?
Yes, if its supported roles and mappings include the required command operations. Validate authorization, destination behavior, failure handling, and command acknowledgement before enabling writes.
What should I test before commissioning a shared gateway?
Test value conversion, communication loss, restart recovery, stale-data indication, and rejected commands. The consuming application must distinguish a valid measurement from an old value left in memory.
Test an unchanged process value during a communication failure. A frozen measurement can look entirely plausible, so a changing-value demonstration misses the failure that matters most: the consumer continuing to trust stale data.
Keep that test in the acceptance plan for any Software Toolbox connectivity evaluation. The gateway is ready only when the application can tell the difference between a stable process and a lost connection.