3D camera ping works but no image: reset apps and check the trigger

A 3D camera that answers ping, reads back its full configuration, and even accepts new applications — while the viewer stays blank — is one of the most common integration faults on the bench. It wastes hours because the network looks proven and the SDK reports a first-frame timeout that sounds like a driver problem. It is almost always camera-side state: an application waiting for a trigger, or a stale application set. This guide gives you the test order — read the trigger mode, reset to the factory applications, set free run, then test client exclusivity, stream format and MTU — plus a counted-capture check that proves the fix. Budget about 15 minutes.

Why does a 3D camera answer ping but show no image?

Ping proves only that the camera's IP stack answers; when configuration reads succeed but no frames arrive, the cause is camera-side state, in this order: the active application waits on a trigger that never comes, the application set is stale, or another client owns the camera.

Ping is an ICMP echo handled by the network stack. The depth stream is a separate UDP session that starts only when an active application produces frames, and configuration traffic usually rides a small, reliable control channel. A settings dump that succeeds therefore tells you the stack and the control protocol are alive — and nothing about the data path.

A ToF or structured-light head streams continuously only in free run, typically at 5-30 fps. If the active application's trigger mode is hardware or software trigger and nothing sends edges, no frame is ever produced, and your client times out. The blank viewer is a faithful report, not a bug. The same symptom appears when a second client holds the camera, because most 3D heads serve one subscriber at a time.

If your failure is a timeout on the image buffer while ping succeeds, the timeout waiting for image buffer guide covers the host-side version of this fault; the steps below fix the camera side.

Which cause do you test first: the trigger or the applications?

Read the trigger first, because it is a one-minute, non-destructive check: in the camera's web interface or configuration tool, open the active application and read its trigger mode — if it reads hardware or software trigger, the camera produces no frame until an edge arrives.

The order matters. A trigger read changes nothing, while a reset erases configuration, so you read before you wipe. Bench cameras carry settings from the last project: a trigger wired to a digital input that is no longer driven, a software trigger waiting for a command that no longer comes, or two preinstalled applications with neither active in the state your client expects.

List the applications, note the active index and its trigger mode, and keep both in your notes — you will want them after the reset. For the modes themselves, industrial camera trigger modes compared explains the full ladder from free run to PTP scheduling, and the hardware trigger defaults guide shows why free run is the sane bench default and how to drive the input properly when you do need edges.

How do you reset a 3D camera to its factory applications?

Run the factory-application reset your SDK documents — one command restores the shipped application set and deactivates whatever a previous project left behind; export the current configuration first, because the reset erases custom applications.

1. Connect and enumerate the camera with your SDK, then read back the complete configuration and save it to a file; most SDKs write it as JSON.
2. Note the active application index and its trigger mode.
3. Run the SDK's documented factory-application reset command — every major 3D camera SDK ships one as a listed operation.
4. Wait for the ready state: a reboot and re-enumeration, typically under a minute.
5. Confirm the network settings, then read the application list again. It should now hold the factory set, normally one free-run application.

What the reset fixes: heads that ship with two applications can power up with the wrong one active, or with an application half-edited from a previous job; the reset collapses all of that to a known state. On most cameras the IP settings survive the reset, but check after the first one so you know how your firmware behaves.

How do you set the active application to free run?

Set the active application's trigger mode to free run, save the application, and restart your stream — at a typical 10 fps ToF rate the first frame lands about 100 ms after streaming starts, so a viewer still blank after 5 s is not waiting on a trigger.

1. Open the active application in the web interface or configuration tool.
2. Find the trigger mode parameter; it sits in the application's acquisition or trigger group and reads free run, software trigger or hardware trigger.
3. Set it to free run — some interfaces call this continuous.
4. Save and apply; a few cameras need an explicit save-then-activate step.
5. Restart your stream and watch the frame counter, not the viewer.

Two variants. If the station triggers from a PLC, leave the application on hardware trigger and have your test client send software triggers instead; the abort a capture waiting for a trigger guide shows how to end the wait cleanly when edges stop. And if frames arrive but slowly, the low frame rate on software trigger guide covers the data-stream settings that throttle them.

What if the stream stays blank after reset and free run?

Work down four remaining causes, one test each: a second client holding the camera exclusively, a stream type or format your application does not produce, an MTU mismatch that passes short control packets but drops video, and a host-side driver path.

• One client at a time. Most 3D heads accept a single control client and one stream subscription; a viewer left open in another window makes your program time out. Test: close every other client, including background nodes. The camera busy in the vendor tool guide walks the pattern.
• Stream type or format. Requesting RGB from an application that produces depth and amplitude, or a depth mode the application does not list, returns nothing even though the camera streams. Test: read the application's output list and subscribe to exactly those outputs. The RGB works but no depth guide and the no matched video stream profile fix cover the two ways this presents.
• MTU mismatch. Control packets are tens of bytes and pass through anything; video packets are sized to the path MTU — 1500 bytes on standard Ethernet, up to 9000 bytes with jumbo frames. A camera emitting 9000-byte packets into a 1500-byte link gives working configuration and dead video. Test: set the packet size to 1500 bytes on both ends and retest. The GVSP packets but no image debugging guide does the full walk.
• Host driver path. On Linux, a media stack rebuilt by an update can drop frames while enumeration still works. The depth stream missing on Linux guide traces where frames stop.

When is ping the wrong test for a 3D camera?

Ping tests ICMP reachability and nothing else, so a camera can answer every ping while its streaming port is filtered, its address points to the wrong device, or its protocol is not the one your client speaks — treat ping as necessary, never sufficient.

The reachability test that means something is the SDK's device enumeration plus a successful configuration read; the data-path test is the counted capture in the next section. Two network faults imitate this symptom exactly: an IP conflict, where ping is answered by the wrong device — the camera IP conflict guide shows the tell-tales — and a DHCP setup with two servers handing out leases, which the 3D camera DHCP guide fixes with one server and a static reservation.

The same ping-versus-protocol trap fills PLC work: Modbus TCP that fails while ping works is diagnosed the same way — prove the protocol, not the echo.

How do you prove the fix and keep the fault from coming back?

Prove the fix with a counted capture and a sized timeout: subscribe from your own client, record for 10 s, and check the count against the rate — 10 s at 10 fps must return about 100 frames, and the receive timeout should be at least three frame periods, 300 ms here.

Read the count as an estimate with one frame of phase: 99 or 101 at 10 fps over 10 s is normal, zero is the fault. A count of zero with free run confirmed points back at the camera or the transport; a count of about 100 in the SDK with a blank viewer points at the viewer or the format you subscribed to. That one number splits the remaining fault domain in half.

Prevention is three habits: pin the trigger mode in the saved application file, re-import that file after any firmware update, and keep exactly one client on the camera. The teach versus run time guide is the fuller story of settings that work in the studio and die on the line.

When do you swap the camera head instead of reconfiguring it?

Swap the head once a factory reset, free run, and a known-good cable, switch and host have all failed — after those four checks the fault is inside the camera, and a bench swap takes 15 minutes and closes the case.

The swap test is strict on purpose: give the spare the same address or a static IP, connect through the same cable and switch, and run the same minimal capture script. If the spare streams and the first head does not, package the first head for the service channel and stop tuning it. A bench spare that matches your interface keeps the test honest:

If the station is built on a laser profiler, blank free-run viewing is normal, not a fault: profilers produce a profile only per software trigger or encoder tick, so test them with the trigger armed. Profilers that suit a swap test of the trigger path:

Pick the replacement in the 3D sensors category, filter interface and trigger options in the camera finder, or start the whole chain in the configurator. Send us your trigger scheme, frame rate and interface through the contact page if you want the swap specified before you order, and the 3D camera topic page collects the rest of the fault guides in one place.