Four replies come back from the camera in under a millisecond, and the driver still gives up with an XML-RPC timeout. This guide is for integration engineers connecting a 3D camera to a Linux host over Ethernet. It explains what a successful ping can and cannot prove, why the driver's control channel fails while ICMP succeeds, and hands you an ordered test plan: confirm the driver supports the sensor generation, verify the address and the control port, then clear proxy interception. Work the list in order and most of these faults separate in minutes.
Why does ping work when the driver still times out?
Ping works because the camera answers ICMP echo requests, a network-layer check that proves only cable, IP and routing; the driver then needs a TCP session to the camera's XML-RPC control port, and ICMP says nothing about whether that session can open.
ICMP echo is a control protocol at the network layer, described in the Internet Control Message Protocol reference: it asks a host stack whether it is there and receives a yes. That yes proves the link is up, the address is set and the path forwards packets. The driver's first move after loading is different: it opens a TCP session to the camera's XML-RPC control port, reads device state over HTTP, and only then starts the frame stream. Two transports share one cable, and the ping exercises only the first.
So the failing driver sits between two neighbouring faults. When the ping itself fails, that is subnet and cabling - see 3D camera not pingable on a Linux controller: fix subnet and link. When ping passes and the image stream never starts, the trigger path is the usual suspect - see 3D camera ping works but no image: reset apps and check the trigger. A driver that cannot finish initialization at all has a healthy link and a dead control session, which is the case this guide resolves.
What does the XML-RPC timeout actually measure?
The timeout is the driver's own RPC wait expiring, typically about one second. In the failing startup below, the driver begins camera initialization at 1563824663.816 and reports the timeout at 1563824664.818, so it waited 1.0026 s - the library's default window, not a slow network.
A failing startup prints two warnings on this pattern:
[ WARN] [1563824664.818563389]: -100001: Lib: XMLRPC Timeout - can you `ping' the sensor?
[ WARN] [1563824664.818752803]: Could not initialize pixel stream!
Error -100001 means the library's XML-RPC wait expired before the camera answered the configuration call. The message suggests ping because a silent link is the most common reason that wait expires - but your ping has already answered that question.
The wait length is readable from the log. Initialization starts and the timeout warning lands 1.0026 s later, which is a one-second default RPC window:
The ping in the same startup measured 0.226 ms round trip, so the driver allowed roughly 4,436 round trips (1.0026 / 0.000226) before giving up. A one-second cap expiring on a sub-millisecond link is not a latency story. The session is being refused, swallowed by an intermediary, or dialing an address with nothing on it.
What fails first when ping answers but the RPC session doesn't?
Rank the causes before you test: a camera generation the driver family never supported, a client dialing a different address than the one you pinged, proxy variables capturing the HTTP-based control session, and only then the control service down or filtered behind a firewall or VLAN.
- Unsupported camera generation. The sensor predates the driver family and its control interface was never implemented in it. Test: the camera's own configuration tool connects while every SDK call times out.
- Wrong address in the client. DHCP moved the camera, or the driver kept its default address because the device-IP parameter was never passed. Test: log or print the address the client actually dials and compare it with the address you pinged.
- Proxy interception. The control calls are HTTP, so proxy environment variables reroute them. Test: clear the variables for one run, as the next sections show.
- Service down or filtered. The camera is still booting, its control service crashed, or a firewall or a VLAN trunk-versus-access mismatch blocks the port. Test: a timed TCP connect, described below.
| Observation | Leading cause | Decisive test |
|---|---|---|
| Configuration tool connects, SDK times out | Unsupported generation | Supported-device list against the model |
| Driver dials instantly, no listener | Wrong address in the client | Client's logged target IP |
| Connect succeeds, RPC still dies | Proxy capturing HTTP | Run once with proxies cleared |
| Connect hangs to the limit | Filtered port or dead service | Timed TCP connect, firewall and VLAN check |
Fix the cause the test names. A fix applied to cause four cannot rescue cause one, which is why the order matters more than the tools.
How do you test the control port the way the driver does?
Open a TCP connection to the camera's XML-RPC port yourself and time it. With the example's ping RTT at 0.226 ms, a healthy connect completes in about 0.2-1 ms; a connect that hangs until your tool's own limit means a filtered or absent service, not latency.
Work from the driver's own host and user account, because proxy settings differ per user and a service account can carry a stale environment:
- Confirm the reply is on-link. The ping output shows ttl=64: the camera's stack starts replies at a TTL of 64 and each router subtracts one, so 64 means zero hops crossed - the answering device is on your subnet.
- Confirm you are talking to the camera. Check the ARP entry for the address against the MAC printed on the camera label; another station can own an IP address honestly.
- Open a TCP connection to the control port and time it. A connect is one round trip, so expect completion in about 0.23 ms on this link (one trip at 0.226 ms).
- Read the ending. Instant refusal: the host is reachable and the port is closed, so the service is down or not yet booted. Silent hang to your limit: firewall or VLAN filtering, or a proxy accepting the session on the camera's behalf.
- Connect succeeds but the RPC still times out points at proxy interception of the HTTP session - clear the proxy variables and retry.
The two endings give you the decision: a connect under a millisecond with the RPC still dying is the proxy signature; a connect that never completes is the firewall signature. Neither is a cable problem, and the green ping told you that from the start.
Does the driver support your camera generation at all?
Check the support list before touching the network. A legacy generation that predates the driver family answers ping and even its own configuration tool, yet the driver never implemented its control interface; no proxy edit or port change can fix that, and the durable fix is a supported generation.
This is the dead end worth finding first, because it costs an afternoon of network tuning before it costs nothing but the truth. The signature is exact: the camera's own configuration tool connects and exposes parameters, while the SDK times out inside its one-second window and never returns device state. When you see that split, stop tuning. Ask the manufacturer which documented software release supports the generation - if the answer is none, the sensor becomes a spare and the inspection moves to a supported family. The same compatibility-first habit applies when the camera has to drive a robot: read 3D camera robot integration: check compatibility before wiring, and Depth camera SDK support check: verify stereo cameras before you buy before purchasing a stereo camera at all.
For the replacement, match the output style to the job: a laser profiler for profile-based height and width, a ToF or structured-light camera for full-frame depth and volume.
- Type
- Depth / ToF camera
The MV-DT01WMU is a Depth / ToF camera for full-frame depth sensing in the style of the legacy hardware above.
- Type
- Laser profiler
The MIS-DP3850-01P is a 3D laser profile sensor for height, width and deformation profiling.
Laser profilers and stereo 3D cameras
170 models · from $699.00Which proxy settings capture the XML-RPC session?
XML-RPC rides on HTTP, so a set http_proxy or HTTP_PROXY sends the control calls to the proxy instead of the camera. Exempt the camera IP in no_proxy as a comma-separated list without spaces, and clear the variables entirely for one run as an A/B test.
Because the control channel is HTTP, the usual variables apply: http_proxy, HTTP_PROXY, https_proxy and all_proxy redirect the calls to the proxy host, while ICMP has no proxy concept at all - which is exactly why ping stays green while RPC dies. The frame stream, once it runs, uses direct TCP and never sees the proxy, another reason the fault looks one-sided.
Fix it in this order:
- Clear the proxy variables for one test run and start the driver again. A connect that now succeeds proves the cause in a single iteration.
- Add the narrowest permanent exemption: the camera's IP in no_proxy, comma-separated without spaces - 127.0.0.1,localhost,192.168.4.180, not entries padded with spaces. Several HTTP clients never match padded entries because they do not trim whitespace, so a list copied with spaces after each comma silently exempts nothing.
- Restart the driver from the same shell or service account you tested with; environment differences between accounts are the classic relapse.
For the full shell-level walk-through of these variables, see XML-RPC timeout on 3D camera tools: fix shell environment variables.
How do you keep the control channel healthy afterwards?
Pin the camera's address and boot in the right order. Reserve the IP outside the DHCP pool, pass it explicitly to the driver at startup, start the camera's control service before the driver initializes, and treat any future one-second timeout as a configuration fault first.
- Pin the address. Reserve the camera's IP outside the DHCP pool; DHCP enabled plus a hand-fixed IP is an ambiguity that survives until someone touches the lease table.
- Pass the address explicitly. Give the driver its device-IP parameter at every startup and never rely on its default.
- Boot in order. Wait for the control service to accept a TCP connect before launching the driver; a 30 s start delay covers a cold camera.
- Write the budgets on the station sheet. One-second RPC window, sub-millisecond connect target, ping RTT baseline of 0.226 ms - so the next timeout is triaged against numbers, not guesses, in seconds.
When is ping the wrong test for a vision device?
Treat ping as a cable test, never an application test. Some controller and HMI ports answer ICMP while their application protocol is dead; others answer ICMP only after it is enabled, so a green ping proves the link, not the service.
The split is industry-wide, not a 3D-camera quirk. A robot controller port can answer ICMP while its application protocol times out - the same two-layer failure on different hardware (a robot controller Ethernet port that answers ping while its application port times out). Some HMIs stay silent on ping entirely until ICMP is enabled on them (an HMI that ignores ping until ICMP is enabled), so a dead ping can lie in the other direction too. And when two devices share one address, the ping is honest but the session belongs to a stranger - the camera IP conflict: ping works but the web page is wrong case.
The rule that survives all of these: ping the cable, then test the protocol. Open the port the application actually uses and read the ending - refusal, hang or success each names its own cause.
If the generation check ends the line for your sensor, the 3D sensors category and the camera finder list current supported families, and the system configurator pairs the sensor you choose with the lens, light and controller around it. For a legacy-generation question that needs a human answer, use the contact page. More diagnosis guides for depth hardware sit on the 3D camera topic page.
Questions
Can a firewall pass ping and still block the driver?
Yes. ICMP echo and TCP are filtered independently, so a firewall can answer echo requests while dropping the connection attempt to the control port. The ping stays green and every RPC call times out. Test by opening a TCP connection to the XML-RPC port from the driver's own host, then allow that port in and out on the host firewall and any switch access list between them.
What does ttl=64 in the ping reply tell me?
The camera's stack starts echo replies at TTL 64, and every router along the way decrements the value by one. A reply showing ttl=64 therefore crossed no router: the answering device sits on your own subnet. That confirms the camera is on-link and, with the ARP entry checked against the label's MAC, that the IP you pinged belongs to the camera rather than to a neighboring station.
How long should a manual connection test wait before I call it a failure?
Use a bounded window of five seconds and read the ending, not just the duration. A connect completing in under a millisecond means a healthy path; an instant refusal means the port is closed and the service is down; a silent hang to your limit means filtering or a proxy is swallowing the session. Each outcome names a different cause, which the timeout message alone does not.
The camera's own configuration tool connects but the driver still times out - what does that prove?
It proves the network path, the address and the control service all work, because the tool uses the same channel. The remaining variable is software support: the driver family was never built for that camera generation. Ask the manufacturer which documented software release supports the generation; if none does, keep the sensor as a spare and move the inspection to a supported current model.
Should I exempt the whole camera subnet in no_proxy?
Start with the exact camera IP, for example 192.168.4.180, comma-separated and without spaces. Prove the cause first by clearing the proxy variables for one test run, then add the narrowest entry that works. Broad wildcard entries behave differently between HTTP client libraries, and a wide exemption can quietly reroute other traffic that legitimately needs the proxy.