Production returns after the reachable DataMan reader receives the DMCC reboot command over its Telnet connection and the TCP driver reconnects. Before rebooting, separate a dead reader from a stale host connection; a heartbeat alone does not make that decision.
Stop using the usual quick fixes
| Quick fix | Why it fails | Use instead |
|---|---|---|
| Reset the heartbeat only after a successful decode | No decode means no reset. That mixes barcode activity with connection health and cannot prove that the peer receives data. | Run the timer independently and require an application-level response when end-to-end health matters. |
| Guess the peer's random TCP port | The connecting client normally receives an ephemeral source port. That port identifies one connection; it is not a fixed management endpoint. | Send through the active communication-handler context or open a new session to the reader's configured listening port. |
| Reboot through a connection after it has closed | Once TCP disconnects, that session cannot carry a command. | Use another reachable management connection, or use the site's approved local power-recovery method. |
Paste both sample onResult functions into one script |
Both functions have the same name. In a shared JavaScript scope, the later declaration replaces the earlier behavior rather than combining it. | Keep one onResult function that performs formatting and resets registered heartbeat handlers. |
Separate heartbeat traffic from recovery
The communication sample creates a handler for each connection. onConnect stores peerName, starts a timer, arms expectFramed("\0", "\0", 128), and adds the handler to comm_handler. The configured beat_timer is 10.0 seconds. When the timer expires, onTimer sends a timestamped line and calls resetHeartBeat to schedule the next event.
That proves only that the script attempted an outbound send. It does not prove that the host application processed the message, that the driver remains usable, or that scanning still works. A true watchdog needs a defined request, a matching response, a timeout evaluated by an independent supervisor, and a bounded recovery policy.
The supplied onDisconnect callback removes the connection from comm_handler; it does not reboot the reader. That is the correct lifecycle boundary because a closed connection cannot issue its own recovery command.
Identify which side is still alive
| Observed condition | Check | Decision |
|---|---|---|
| The driver reports a lost or hung connection | Try a fresh management connection to the reader and inspect both reader and host connection diagnostics. | If management access works, recover the failed session before deciding to reboot the reader. |
| The reader still decodes but results do not reach the application | Compare reader-side decode activity with host-side received messages. | Treat this first as a driver, socket, framing, or application-consumption fault. |
| The Telnet command channel accepts DMCC commands | Send an approved non-disruptive DMCC query from the official command reference. | The reader remains reachable; a controlled DMCC reboot is available if session recovery fails. |
| No management path reaches the reader | Check link state, addressing, switching, and the approved local power path. | A network command cannot recover an unreachable device. |
Collect the state before clearing it: which of the 60 connections failed, whether failures occurred together, whether decoding continued, and whether a new TCP session succeeded. Simultaneous failures point toward shared host or network infrastructure; repeatedly rebooting individual readers removes useful diagnostic state.
Use the connection context instead of chasing ports
A TCP connection contains a local address and port plus a remote address and port. The server listens on a configured port, while the connecting client commonly uses a temporary source port. Seeing that source port change is normal.
Inside this communication script, onConnect(peerName) supplies the peer identity and assigns it to peer_name. The handler later calls this.send(...) for that live connection. Use that connection object; do not build recovery logic around a remembered ephemeral port.
If the reader initiates the connection to the host, the host can reply while that socket remains open. After it closes, reconnect through a separately configured reader service or wait for the reader to establish a new session. Read the actual listening-port setting from the reader configuration rather than assigning a number from another installation.
Send the reboot command through a reachable session
- Confirm the target reader identity. With 60 readers, map the connection or address to the physical station before sending a disruptive command.
- Capture the current connection and reader diagnostics. Preserve timestamps and the failure state for later root-cause work.
- Attempt an orderly driver or socket reconnect. If decoding continues and only the host session is stale, this restores service without restarting the reader.
- Open a Telnet connection to the reader's configured command port when the reader remains reachable.
- Transmit the exact DMCC command
||>REBOOT\r\n. The\r\nterminator is part of the command framing. - Expect the management session to close as the reader restarts. Do not classify that expected disconnect as another fault.
- Allow the reader and driver to re-establish their configured connections, then perform the production verification below.
For automatic recovery, place the decision in an external supervisor that can still act when the data socket fails. Require consecutive failed health checks, cap retries, add a cooldown, and raise an alarm when recovery does not hold. Stagger recovery across the fleet so one shared disturbance does not reboot all 60 readers together.
Verify the repair and harden the script
- Confirm the reader becomes reachable through its configured management path.
- Confirm the production TCP driver creates a new session and remains connected.
- Trigger a known decode and verify the exact result reaches the consuming application with the expected line termination.
- Verify the heartbeat repeats at the configured
10.0-second interval and that the host processes it. - Review reader, driver, host, and switch diagnostics for a repeated disconnect pattern.
Guard the handler removal logic. The sample obtains an index with comm_handler.indexOf(this) and immediately passes it to splice. If the handler is absent, an index of -1 would remove the last array entry. Check that the index is zero or greater before removing it.
Keep variables local where possible. The sample assigns today and num_send without declarations, which can create shared globals and cross-connection interference. Also consolidate the duplicate onResult declarations so result formatting and resetHeartBeat calls execute in one function.
FAQ
Why does the Cognex DataMan TCP port look random?
The connecting side commonly uses an ephemeral source port for each TCP session. Send through the active handler context, or connect to the configured listening port; do not treat the temporary source port as the service port.
Why does a 10-second heartbeat not detect every hang?
The sample's 10.0-second timer proves that a send was attempted, not that the host application received and processed it. Add a request-and-response health check with an external timeout decision.
Why does the reboot command disconnect Telnet?
||>REBOOT\r\n restarts the reader, so the command session closes. Verify recovery by observing a new management connection, a new production TCP session, and a successful decoded result.
When should I stop rebooting a Cognex DataMan reader?
Stop when the command channel is unreachable, the reader enters a reboot cycle, or multiple readers fail together after one recovery attempt. Preserve the reader, driver, host, and network diagnostics, then escalate through official Cognex support with the configuration and timestamps.