A vision sensor can answer ping while its control connection fails immediately. Ping checks an ICMP exchange; your application may need a separate TCP service before it can read settings or start acquisition. For engineers commissioning networked inspection stations, the useful question is not simply whether the device responds, but which connection stage fails.
Start with the application’s actual destination and lowest-level error. Then verify device identity, routing, and the documented control endpoint. This sequence separates network faults from unavailable services without unnecessary password changes, software rebuilds, or hardware replacement.
1. Identify the failed connection layer
An application may label several failures as a timeout even when its underlying transport reports connection refused. Read the detailed log before increasing retry counts or changing acquisition settings.
A refused TCP connection usually indicates an active rejection. The sensor may have no service listening on that port, or an intermediate firewall may reject the attempt. It does not prove that the intended camera received the request.
| Observation | What it establishes | Next check |
|---|---|---|
| Ping replies | An endpoint answers ICMP at that address | Verify identity and the application’s route |
| TCP connection refused | The connection attempt received an active rejection | Check the documented port, service state, and reject rules |
| TCP connection times out | No successful connection or definitive rejection arrived before the deadline | Check routing, filtering, device state, and return path |
| TCP connection succeeds | Something accepts TCP connections at the endpoint | Test the documented application protocol |
| Authentication error | An application service responded far enough to evaluate access | Use approved credentials or documented account recovery |
| Control works but acquisition fails | The tested control exchange succeeds | Diagnose the separate acquisition connection and configuration |
A generic network fault should first follow the vision camera network connection troubleshooting workflow. Continue here when the device appears reachable but its control endpoint remains unavailable.
2. Confirm the destination, address, and route
Check the address used by the failing process, not just the address entered in a terminal. A launch configuration, environment variable, saved profile, or compiled example may still point somewhere else.
On a Linux host, these read-only checks help establish the local network state:
ip -br address
ip route get 192.168.40.20
ping -c 3 192.168.40.20
ip neigh show 192.168.40.20
The addresses here are illustrative. Substitute the approved sensor address on your own network. The route lookup shows the selected interface, source address, and next hop. The neighbor entry is most useful when the sensor is directly connected on the local subnet; a routed connection resolves the gateway instead.
For a worked example, suppose the host is configured as 192.168.40.10/24 and the sensor as 192.168.40.20/24. Their subnet mask is 255.255.255.0:
Both addresses belong to the same subnet under those masks. That calculation does not establish physical connectivity: switch segmentation, conflicting routes, and duplicate addresses can still prevent communication with the intended device.
Compare the device identity reported by its documented configuration utility with the equipment record. For intermittent identity changes or unexpected devices, use the multiple-camera discovery checks.
Also check for overlapping address ranges across Ethernet adapters, wireless connections, and virtual interfaces. A successful terminal test is not decisive if the application runs inside a container or another network namespace. Repeat the relevant checks from the application’s actual execution environment.
3. Test only the documented control endpoint
Obtain the control transport, port, and protocol from documentation for the exact device and firmware. Do not infer them from another sensor, a browser bookmark, or an unrelated example application.
A discovery channel, configuration service, and image stream can use different endpoints. Seeing the device in a discovery utility therefore does not establish that its control service is available.
For a documented TCP service, make one bounded connection check from an authorized host. This example assumes the approved configuration explicitly specifies port 5000; that number is illustrative, not a camera specification:
nc -vz -w 3 192.168.40.20 5000
Use this only against equipment you are authorized to diagnose. Do not scan port ranges or probe unrelated devices. Command options vary between implementations, so check the local command help before use.
Interpret the outcome narrowly:
- Immediate refusal: verify the destination, configured port, service enable state, and any explicit firewall rejection.
- Timeout: investigate routing, dropped traffic, unavailable equipment, and the return path.
- Successful connection: proceed to a documented, read-only application request. A TCP listener alone does not prove protocol compatibility.
A TCP probe is not a valid test for a UDP-only service. Use the manufacturer’s documented diagnostic method for that transport.
If approved packet capture is available, observing a connection request followed by a TCP reset supports the refusal diagnosis. Correlate the capture with device and network logs to identify the rejecting component. A host-side capture alone may not establish where the rejection originated.
4. Separate client configuration from device availability
Once the endpoint is verified, compare the failing application with the manufacturer’s supported configuration utility. Close competing configuration clients if the documentation limits control sessions.
Use the same host, destination address, and intended device. Then compare these cases:
| Supported utility | Application | Most useful investigation |
|---|---|---|
| Connects | Refused or timed out | Application endpoint, execution environment, or connection sequence |
| Cannot connect | Cannot connect | Shared network path, device service state, or firmware support |
| Connects | Connects, then rejects a request | Protocol version, request format, permissions, or session handling |
| Connects only after startup delay | Fails during startup | Readiness detection and documented retry behavior |
Inspect the application’s effective settings at runtime. A configuration file can be correct while a command-line option overrides it. Log the resolved address and port without logging credentials.
Check the exact sensor variant, firmware release, SDK release, and supported operating system against the manufacturer’s compatibility documentation. Obtain software and firmware only from the manufacturer or its distributors.
The firmware and SDK alignment checks explain how to investigate version mismatches. Treat compatibility as a hypothesis to verify, not a reason to install arbitrary older packages.
Repeated failures in many automated tests can share one failed connection setup. Read the earliest connection error before treating every failed test as a separate image-processing defect.
5. Inspect service state before changing credentials
If the destination and documented port are correct, inspect the sensor’s supported configuration path. Look for a disabled service, incomplete startup, unsupported operating mode, or a configuration change that moved the endpoint.
Do not assume a missing password caused a TCP refusal. Authentication normally occurs after the transport connection succeeds, although device policies can vary. A protocol-level access-denied response is much stronger evidence of an account issue than a failed TCP connection.
Use authorized credentials when the service requests them. If access has been lost, follow the manufacturer’s documented account recovery or reset procedure, or contact its support channel. Do not try password-removal commands borrowed from another model.
Before a restart, firmware change, or reset, place connected equipment in the site-approved safe maintenance state. Preserve the configuration and calibration through documented export methods when available. Review what the procedure erases and how the station will be revalidated afterward.
If service availability remains unexplained, prepare a support package containing:
- Device identity and exact firmware release.
- Client and SDK versions, including the operating environment.
- The configured address, transport, and documented port.
- Route information and the outcome of the bounded connection check.
- Timestamped, sanitized logs showing the earliest transport failure.
- Whether the supported configuration utility connects under the same conditions.
Remove passwords, session tokens, and unrelated production data before sharing logs.
6. Verify recovery at every required layer
A successful ping after a change is not a complete acceptance test. Verify the same sequence that the production application needs.
- Confirm that the intended device identity is stable at the configured address.
- Connect to the documented control endpoint.
- Perform a supported, read-only identity or status request.
- Establish an authorized control session if required.
- Start acquisition through the documented workflow.
- Confirm that the received data belongs to the intended sensor.
- Close the session and reconnect cleanly.
Repeat the sequence after an approved application restart. After an approved device restart, check whether startup readiness is handled correctly rather than assuming ping means every service is ready.
Use bounded retries with a clear failure state. For example, a commissioning policy might allow 3 attempts with a 2-second connection deadline and 1 second between attempts:
This is a planning example, not a recommended timeout for every sensor. It excludes protocol processing and other application work. Choose production deadlines from documented startup behavior and your station’s requirements.
If control succeeds but a downstream occupancy stream still fails, move to the occupancy stream connection checks. Do not keep changing the now-working camera control endpoint.
7. Check compatibility before replacing or ordering hardware
Connection refused is not, by itself, evidence that the sensor needs replacement. Prove the endpoint and service fault first. A replacement with the same unsupported software path can reproduce the problem.
When choosing among 3D sensors, begin with the measurement method and then confirm the documented integration interface. The camera finder supports hardware selection; interface and SDK compatibility still require verification for the exact candidate.
MV-DT01WMU is cataloged as a ToF sensing camera.
- Type
- Depth / ToF camera
MV-DPS200P-02 is cataloged as a projected structured-light 3D camera.
- Type
- Stereo / structured light
These are measurement-method examples, not confirmed replacements for an existing installation. The catalog information supplied here does not establish their control ports, operating-system support, or compatibility with your application.
For installations using vision controllers, confirm the supported SDK environment, camera interface, and network configuration before selecting the host. More processing capacity will not restore a service that is disabled or addressed incorrectly.
8. Prevent the same fault at the next deployment
Keep a short commissioning record beside the station configuration:
- Identity: record the intended device and its approved address assignment, so another responding endpoint is not mistaken for the sensor.
- Endpoint: record control and acquisition transports separately, including their documented ports and configuration sources.
- Routing: identify the intended interface and subnet, especially on hosts with several network connections.
- Compatibility: retain the validated firmware and SDK pairing, with approved installation sources.
- Startup: distinguish network reachability from control-service readiness in application logs.
- Verification: retain a read-only control check and a separate acquisition check.
- Recovery: document configuration backup, authorized access recovery, and the escalation path.
For a new station, begin with the camera configuration workflow. For an existing station with an unresolved control connection, send the sanitized evidence through technical support before changing hardware.
Questions
Why does the camera answer ping but refuse its control connection?
Ping and camera control use different communication mechanisms. A device can answer ICMP while its TCP control service is stopped, disabled, or configured on another port. A firewall can also allow ping while rejecting control traffic. Verify the intended device and its documented endpoint rather than treating ping as a complete connection test.
How is connection refused different from a timeout?
A refusal usually means the connection attempt received an active rejection. A timeout means the connection did not complete before the deadline, without a definitive rejection reaching the client. Application wrappers can obscure this distinction, so inspect the underlying socket error and timestamped diagnostic log before choosing the next test.
Should I reset the camera password when the connection is refused?
Not solely because a TCP connection is refused. First establish whether the application can reach the correct service. Use approved credentials when the service returns an authentication response. If access is lost, follow the documented recovery procedure; an unnecessary reset can remove configuration without correcting the original network fault.
What should I verify before buying a replacement sensor?
Confirm the control transport and port, supported device variant, firmware and SDK pairing, operating-system support, and any session restrictions. Also distinguish configuration access from acquisition access. A sensor’s measurement method or physical network connector does not establish compatibility with a particular software client.
Which diagnostic information is most useful for support?
Provide the device identity, firmware and SDK versions, effective destination settings, route information, and the earliest detailed transport error. Include whether the supported configuration utility connects from the same environment. Remove credentials, session tokens, and unrelated production information before sharing diagnostic files.