Why Won't a TCP Driver Tag Read Fluke Endurance ASCII Replies?

Read the Symptom Before You Touch Settings

The TCP device shows Connected. A terminal session to the same IP and port gets an answer every time you type ?E and press Enter. The tag you built at Device/?Char stays empty. Writing a request into a string tag returns nothing.

Start here. Connected only proves the TCP handshake completed. It does not tell you whether a complete, correctly terminated command left the driver, or whether the reply was framed into a message.

A raw TCP driver has no address syntax that turns a tag path into a query. It gives you two things:

• An outbound writeback string that the driver pushes down the socket.
• An inbound buffer that the driver cuts into messages at a delimiter.

The terminal handled both for you without showing it. Pressing Enter sent a carriage return, and the screen printed whatever bytes arrived. In the driver, you configure both explicitly.

Check 1: Free the Port and Confirm the Socket

1. Close the terminal session. Embedded sensor interfaces often serve one client per port. A terminal left open can hold the session the driver needs.
2. Confirm the TCP device uses the same IP and port that worked in the terminal.
3. Read the device status.

• Connected: go to Check 2.
• Not connected: fix IP, port, routing or firewall first. Delimiters do not matter until the socket is up.

Check 2: Get a Writeback Tag, Drop the Path Tag

Open the TCP device's advanced settings and enable writeback. This creates a writable tag bound to the connection. Without writeback, the driver only receives data, and nothing you configure can send ?E to the sensor.

Delete the Device/?Char tag. Tweaking that path is a dead end and wastes time. The driver treats it as an address, not as bytes to transmit.

• Writable tag present: go to Check 3.
• Option missing: check the driver's documentation for your gateway version before you continue.

Check 3: Put a Real Carriage Return on the Request

The sensor's poll-mode protocol is strictly framed:

The sensor waits for CR before it acts. When you write ?I0D into a string tag, it sends four characters: ?, I, 0, D. No terminator arrives, so the sensor keeps waiting. Typing ?I\r into a value field usually sends a literal backslash and the letter r. Most value fields do not interpret escape sequences.

The driver's delimiter fields do interpret escapes. Set the writeback delimiter to \r. The driver then appends to every write, so you write only ?E.

• Raw view shows bytes starting with ! after the write: the sensor answered. Go to Check 4.
• Nothing arrives: repeat the exact request in the terminal with the driver disabled.
  • If the terminal works, the driver is still not sending CR. Recheck the delimiter field.
  • If the terminal fails too, check the parameter letter and the sensor's output mode. The protocol above applies to poll mode.

Check 4: Frame the Reply With CR LF

The driver buffers incoming bytes until it sees the configured message delimiter. It then publishes everything before the delimiter as one message.

The sensor ends every answer with CR LF, so set the message delimiter to \r\n. The message tag then shows !E0.975 cleanly.

When the delimiter is wrong:

• Delimiter never matches: the frame never completes. Quick Client shows raw data, but the message tag never updates.
• Delimiter set to \r only: the message publishes, but the trailing LF lands at the front of the next message. Parsing then breaks on a leading newline.

Build the Poll Loop and Verify It

1. Configure the TCP device:
   • Sensor IP and port.
   • Writeback enabled.
   • Writeback delimiter \r.
   • Message delimiter \r\n.
2. Write ?E to the writeback tag by hand. Confirm the message tag reads !E followed by a value.
3. Automate the request. A poll-mode sensor never transmits unprompted. Write the request from a timer script at the update rate you need.
4. Parse the reply in three steps:
   • Reject any message that does not start with !.
   • Reject any reply whose parameter letter does not match the request.
   • Convert the remainder to a float.
5. For multiple parameters, keep one request outstanding at a time. Match each reply by its letter before sending the next request.

# Timer script, pseudocode, generic driver tags
PARAM = 'E'
write(writeback_tag, '?' + PARAM)      # driver appends \r
wait_for_update(message_tag, timeout)
msg = read(message_tag).strip()        # drop any stray CR/LF
if msg.startswith('!' + PARAM):
    value = float(msg[len(PARAM) + 1:])
    write(value_tag, value)
else:
    flag_comm_error(msg)

Verification

• Compare the parsed value with a terminal reading taken with the driver disabled.
• Confirm the message tag timestamp advances on every poll. A frozen timestamp with good quality means the request stopped going out.
• Pull the sensor's network cable briefly. The device should drop to disconnected, and the value should go bad or stale. It should recover without a restart.

Pitfalls that recur

• Polling faster than the sensor answers. Replies interleave, and the message tag holds only the last one.
• Exposing the writeback tag on an HMI. Anyone can send E=0.975-style set commands and change the sensor's configuration. Restrict write access to the script.
• Hard-coding substring positions. Parse on the ! and the parameter letter instead, because value length varies.

FAQ