For the Productivity 3000 capability reported in February 2015, the answer is no: it could not exchange ASCII over Ethernet or implement a custom Ethernet protocol for the Fluke 8845A telnet workflow. Keep a controller that can open a TCP connection, send the meter command, and receive its response, or redesign around serial only if the meter and project support that interface.
Stop treating CPU serial support as Ethernet support
The Productivity 3000 CPU’s built-in RS-232 port was described as supporting ASCII, Modbus, and custom protocols over serial. Those capabilities do not provide a TCP client. Switching between ASCII and Modbus instructions, or configuring another serial protocol, will not make the CPU open an Ethernet socket to the meter.
A second quick fix is to add the P3-SCM because it offers additional serial ports and RTS/CTS control. That module addresses serial port and handshake needs; it does not add the missing ASCII-over-Ethernet or custom Ethernet capability. Choose it only when the design uses a compatible serial connection and needs its supported signals.
Do not treat a PLC feature called “network read” or “network write” as proof that it can create an arbitrary TCP client session. Check the controller documentation for a client socket that can connect to the meter, send application data, and receive a reply. The capability statement for the Productivity 3000 at the time ruled out the required ASCII-over-Ethernet exchange.
Separate telnet, TCP, and serial before selecting hardware
TCP provides a transport connection; the application protocol defines what data the endpoints exchange. A terminal program can make the interaction look like typing text and reading a response, but the PLC must still implement the required connection behavior and message exchange. Telnet can also use protocol negotiation, so a raw TCP socket and a telnet session are not automatically interchangeable.
For this application, the required operation is an Ethernet connection to the meter, followed by a command string and a response. Confirm the meter’s documented connection mode, command syntax, message terminators, and any session negotiation before programming. The source describes a working terminal-style TCP exchange on Do-more, but gives no port number, command string, terminator, or timeout to copy.
| Observed need or assumption | What it means for the design |
|---|---|
| Open a TCP connection to the meter, send a string, and wait for a response | Select a controller with documented arbitrary TCP client and send/receive support. |
| Use the Productivity 3000 CPU’s built-in ASCII capability | The documented port is RS-232; this does not meet the stated Ethernet requirement. |
| Use serial with RTS and CTS | Evaluate the P3-SCM, whose three ports were described as supporting both signals; first confirm the meter can use serial. |
| Use a controller feature named network read/write | Verify its documented endpoint and protocol behavior; the name alone does not establish generic TCP socket support. |
Keep the serial option conditional on the meter interface
The serial path may be an alternative only if the Fluke 8845A setup supports a serial interface and the project can use it. Verify the meter’s available ports, electrical interface, serial settings, and command protocol in its documentation. Do not buy or wire a serial module on the assumption that Ethernet commands will translate directly to serial.
If serial is viable, match the required handshake to the PLC hardware. The CPU RS-232 port was reported to have an RTS pin only. If the meter requires both RTS and CTS, evaluate the P3-SCM; the reported module has three ports that support both signals. Confirm pinout, cable wiring, signal direction, and settings from the applicable hardware manuals before connecting the devices.
ASCII, Modbus, and custom protocol support were reported for the CPU’s RS-232 port. Select among them based on the meter’s documented serial protocol. A serial solution changes the physical and transport interface, so validate the complete request and response exchange rather than assuming that a working Ethernet command sequence will work unchanged.
Keep the demonstrated TCP controller for a temporary restore
The user evaluating the system reported that Do-more had already communicated with the meter over TCP by opening a connection, sending a string, and waiting for a response. If that tested arrangement is available in the project, retain it as the temporary production path while the permanent controller standard is decided. Capture its working connection settings and command/response behavior from the actual configuration and meter documentation.
Do not substitute a Productivity 3000 into that path based on the CPU’s serial ASCII support or the availability of serial modules. That substitution changes the capability being relied on: the required operation is Ethernet socket communication. If Ethernet is mandatory, select a controller whose current documentation explicitly supports the required client session and application data exchange.
Run the controller selection procedure
- Write down the required transport. Record whether the project requires Ethernet TCP to the meter or permits a supported serial interface. Keep the meter model and required operating mode with the interface specification.
- Define the exchange from the meter documentation. Identify the connection method, command and response format, message termination, and any telnet negotiation or session behavior. Read exact values from the meter’s programming documentation; do not infer them from a terminal display.
- Compare the controller capability. For Ethernet, require documented arbitrary TCP client behavior with application data send and receive. For serial, verify the controller port’s electrical interface, protocol support, and required handshake signals.
- Apply the P3000 decision. The February 2015 capability answer rules out the Productivity 3000 for ASCII-over-Ethernet or a custom Ethernet protocol. Consider its serial functions only if serial satisfies the meter and project requirements.
- Prototype before standardizing. Test the selected interface with the actual meter, command sequence, and expected response. Save the working configuration and record how the controller reports connection failures and invalid replies.
Verify the whole request and response path
Acceptance requires more than seeing an Ethernet link or opening a TCP session. Verify that the selected controller reaches the intended meter, sends a valid request in the required format, receives the expected response, and handles the response boundary correctly. Compare the received data with the meter’s documented reply, including terminators or negotiation data where applicable.
For a serial design, verify the actual port and cable, protocol settings, and handshake signals. If using the CPU port, account for its reported RTS-only capability. If the meter requires RTS and CTS, test the P3-SCM path and confirm that the configured port and wiring provide both signals.
Repeat the exchange after a connection interruption and confirm that the program detects a missing or incomplete reply instead of treating stale data as a new measurement. Define the timeout and retry behavior from the application requirements and the controller and meter documentation; no timing values are given here. Record the successful request, response, and recovery behavior as the acceptance baseline.
FAQ: Productivity 3000 and Fluke 8845A Ethernet
Why does Productivity 3000 ASCII support not work over Ethernet?
The reported ASCII capability was for the CPU’s built-in RS-232 port. The February 2015 answer said the Productivity 3000 could not communicate with ASCII over Ethernet or use a custom Ethernet protocol at that time.
Why won’t the P3-SCM add telnet communication?
The P3-SCM was described as a serial module with three ports supporting RTS and CTS. It addresses serial communications and handshake needs, not the missing Ethernet TCP client capability.
Why is a TCP connection not always the same as telnet?
TCP carries the connection, while telnet may include negotiation in addition to application text. Check the meter’s programming documentation and the controller’s socket features to confirm they handle the required session.
Can Productivity 3000 network read/write instructions open a meter socket?
Do not infer arbitrary TCP client support from the instruction name. Check the current controller documentation for the required socket and application-data behavior; the historical capability answer ruled out ASCII-over-Ethernet and custom Ethernet protocols.
What is the practical workaround for Fluke 8845A TCP commands?
Keep a controller with a tested generic TCP client in the path if Ethernet is required. Consider the Productivity 3000 serial functions only after confirming that the meter and project support serial and that the required handshake matches the chosen port.
Stop the Productivity 3000 selection if acceptance still requires the meter’s Ethernet TCP command exchange. Contact AutomationDirect official support to confirm current controller capabilities before adopting the platform as a PLC standard.