Access a camera parameter tree over TCP from a second app

You want to reach into a running 3D camera application from outside it: open a tree editor, change binning or capture settings, and watch the next frame reflect the edit. In C and C++ this keeps failing in one specific way. The editor connects, then shows every parameter greyed out and read-only. The cause is almost never a license or a driver; it is a frozen process. Park the process on a real wait instead of a debugger breakpoint, and the library keeps answering on its TCP port, so your edits go through live.

Why the tree goes read-only under a debugger

The SDK library your application links does not run only when you call it. It holds worker threads inside your process, and one of them owns the TCP port that serves the parameter tree. A tree editor, or a plain browser, talks to that thread to read and to write settings.

A breakpoint stops the whole process, not just your current line. Every library thread freezes with it, so nothing answers on the port and the read-write connection never happens. The same behavior repeating across SDK releases and Windows versions is the clue: it is architectural, not a bug in one build.

What you see instead is the debug fallback, working as designed: a snapshot of the tree as it stood when the process stopped, served from shared memory, and read-only by design. Inspecting a hung process is the intended use of that mode. Treat greyed-out parameters as a symptom of a stopped process, not a broken installation.

How read-write access over TCP works

While your process runs unpaused, the library answers requests on the port it opened. A browser GET returns the whole tree as JSON, and a write from the tree editor changes the live setting. Structured-light SDKs built this way serve the tree on a local HTTP endpoint: with the library listening on port 24000, the address 127.0.0.1:24000/api/tree shows the tree in a browser, and the editor attaches to the same port for read-write access.

One rule sits behind every symptom in this workflow: the port belongs to your process. Running and unpaused gives read-write over TCP; stopped gives a read-only snapshot. Nothing about the camera, the cable or the license changes between the two states.

What you need

• The application that links the 3D camera library, with its initialise call and its open-TCP-port call, which takes the port number as its argument.
• A fixed port number above 1024, kept the same between runs.
• The vendor's tree editor for writes and any browser for the first read check.
• A wait that blocks without stopping the process: std::cin.ignore() in a console application, or the message loop a GUI application already runs.

Build configuration is not the variable here. A Debug build that keeps running gives full access; a Release build stopped at a breakpoint gives none.

Wire the tree port into your application

1. Initialise the library once at startup, before the first capture.
2. Open the tree port right after initialisation and keep the number fixed, for example 24010. A browser tab or editor bookmark pointed at last month's number is the usual reason a session seems to lose the tree.
3. Replace the debugging breakpoint with the wait. In a console application, std::cin.ignore() parks the program at a prompt with the process alive; in a GUI application, let the message loop run.
4. Prove the endpoint on the machine that runs the application. In a browser, open the port you chose on the loopback address, with the tree path of your SDK's local endpoint — 127.0.0.1:24000/api/tree is the shape in this SDK pattern. You should see the tree as JSON, including your camera's serial number.
5. Connect the tree editor to the same port. It should attach in read-write mode.
6. Edit a parameter and read the result from the running application's next captures.

The code pattern, with placeholder names to substitute from your SDK's manual:

// Substitute your SDK's initialise and open-port calls for these names.
const int treePort = 24010;   // fixed port, above 1024
bool ok = false;              // set by each library call below
ok = libraryInitialize();     // your SDK's initialise call
ok = ok && libraryOpenTcpPort(treePort);
if (!ok) return -1;           // no port, no external tree access
std::cin.ignore();            // alive and unpaused: the port answers

Verify the edit: binning, with the numbers

Binning is the cleanest test because the frame size moves by a factor you can calculate. Suppose the application logs 8-bit mono frames at 1920 x 1200. At binning 1 x 1, one frame is 1920 x 1200 x 1 B = 2,304,000 bytes, about 2.3 MB. In the editor, set binning to 2 x 2 while the program waits on std::cin.ignore(). Width and height halve, so the frame falls to 960 x 600 x 1 B = 576,000 bytes, about 0.58 MB, one quarter of before. When the log shows that number from the first full capture after the edit, the write went through the port, into the library and out to the camera.

Two timing details keep the judgement honest. Cameras latch settings at capture boundaries, so a frame that was already integrating finishes with the old exposure; Why a 3D camera needs two captures after a parameter change walks through the mechanism. Binning also trades detail for signal: one binned pixel collects the charge of four, so signal rises about fourfold while spatial resolution halves and fine features blur.

The tree editor is for bench setup. Parameters that must switch per part in production belong in the application logic, changed between scans; Switch 3D camera capture parameters per part between scans shows that path.

Pick the host and the camera

Editor and application talk over loopback on one machine, so the camera keeps a dedicated link and plant traffic never shares it. That argues for a host with spare network ports, which is the vision controllers design brief: the MV-VC3301H-128G66 lists 5+ LAN ports, 4 built-in light channels and 8 GB memory, while the MV-VC2140-128G40-1T covers smaller benches with 3-4 LAN ports and an Intel N-series processor.

On the camera side, the richest trees sit on structured-light devices, where capture, calibration and decoder settings live in one hierarchy. A projected structured-light 3D camera such as the MV-DPS200P-02 is the kind of device this workflow fits.

If the station already runs a general-purpose box, the same pattern works on an industrial mini PC at the bench. To compare depth devices before you commit, the 3D sensors category groups profilers and stereo cameras, and the camera finder filters them by type.

Common mistakes

• Expecting write access while stepping in the debugger. The step freezes the library threads with the process, so wait on input instead.
• Reading the greyed-out tree as a fault. The read-only shared-memory snapshot is the designed view of a stopped process.
• A different port every run. Pick one number above 1024 and keep it; a stale port in a bookmark explains most reports that the editor stopped working.
• Judging the first frame after an edit. Settings latch at capture boundaries, so judge from the next full capture.
• A second capture program on the same host. Your application owns the camera, and a competing process shows up as vanishing device nodes; Camera device nodes disappear when a second application starts diagnoses that failure.
• Editing a value your startup code rewrites. If the application writes the tree at initialisation, a live edit vanishes on the next start, so fix the value in code once the bench test confirms it.

Keep the debug port out of production

An open tree port is a read-write window into camera configuration, so treat it as a debug feature. Gate the open-port call behind a build definition or a command-line switch, so release builds never open it. Where a bench keeps it permanently, bind it to the local machine and keep the plant network off that path. Anyone who can reach the port can rewrite camera settings, so closed stays the default.

When the read-only snapshot is the right tool

For a hung or crashed process, the shared-memory view is exactly what you want: it shows the tree as the process last saw it, without touching anything. Use it for post-mortem work, and read calibration values from the camera's model rather than guessing; Depth camera intrinsics and distortion parameters: read, don't guess shows where they live. For live tuning, the TCP route above is the faster path, and the 3D topic page collects the rest of the depth-camera debugging guides. To put the hardware side together, build a system around the camera you settled on.