Vision tool silently ignores the add command: fix the project file

You click Add, choose the component, and the dialog closes — but nothing appears in the project tree. No error, no warning, no log entry: the tool simply ignores the command. This guide is for the engineer who has hit that wall in a machine-vision or automation engineering suite, where one project refuses every add while another project on the same PC accepts the same component without complaint. That contrast hands you the diagnosis before you touch anything. You will rank the likely causes, confirm the guilty one with a few quick tests, rebuild the project through a template, and prove the repair by making one add survive a full close-and-reopen.

The symptom already names the culprit

Read the failure as three facts. The add dialog opens and closes on demand, so the interface layer is alive. The component never reaches the project tree, so the write that should follow a successful add never landed — or landed and was rolled back the next time the file was read. And the same add works in another project on the same installation, so the software, its license and the hardware drivers are healthy.

Put those together and the fault sits in one place: the failing project's own file, damaged by an interrupted write or last saved by a different release of the tool. Commit to that reading and stop reinstalling the suite, because the installation is the one thing the symptom has already cleared. This is silent data corruption at application scale: a write fails in a way the writing program does not detect, so the store on disk drifts from what the GUI believes it saved. The usual origins are a crash mid-save, an upgrade that re-wrote sections it did not understand, a lock from a second instance, or a sync client that raced the save.

Why the failure hides below the dialog

A configuration GUI is layered: the dialog you click, the in-memory model it edits, the serializer that writes the model to the project file, and the file system underneath. Errors in the first two layers surface as messages, because that is where the suite's error handling lives. Errors in the last two often do not, because many suites validate a project when they load it, not when they save it.

That load-time habit explains the classic release gap. A project last saved by an older release opens with sections the current release can read but will not extend. Your add is accepted into memory, the save skips the section it does not own, and the reopen drops it — no message anywhere. The layering applies wherever a vision tool sits inside a bigger engineering environment; a vision tool configured inside a CAM package has the same dependency on its enclosing project file.

Those two lines say where to aim. A silent failure means at least one of the last two terms is false, and the serializer meeting a store it cannot write is the term your symptom pattern points at.

Rank the causes and test them in order

Work down this table. Each test takes minutes, and each row ends in a decision.

The first row costs about a minute and splits the whole problem in half. Industrial software repeats this pattern well beyond vision: when an HMI project transfer fails silently, the cause is likewise in the transfer path, not in the screen that started it.

The fix: migrate the project through a template

A template, not a copy. A normal save rewrites the existing structure in place and carries damaged sections forward. Exporting a template re-serializes every setting through the current release's writer, and whatever the writer cannot parse is dropped instead of copied. A new project created from that template gets a store the installed release wrote from scratch — which is why it accepts adds the old file refused.

1. Back up the failing project. Copy the whole project directory somewhere safe and mark it read-only; you keep the evidence and the fallback.
2. Open the failing project and save it as a template. The save-as-template function sits beside Save As in the file menu of most engineering suites.
3. Close the project fully, and close the suite if it caches projects in memory.
4. Create a new project from that template.
5. Run the add that failed. The component should appear in the project tree.
6. Close the suite entirely and reopen the new project. The component still being there is the proof that the write path is repaired.
7. Migrate the remaining configuration node by node, saving and reopening after each group, so any regression tells you exactly which node brought it back.

Worked example: rebuilding a four-camera cell on a vision controller

Case: a four-camera GigE inspection cell whose project refuses every add, rebuilt on its vision controller.

Inputs. The host is the MV-SVC2506-16G60-128G; its printed data gives 4 camera GigE ports, 1 configuration GigE port and 1 communication GigE port.

The camera ports carry MV-CU020-90GC cameras. The cell also runs a remote I/O slave — the class of component whose add started the failure. The camera model is interchangeable for this procedure; what matters is that each camera port in use becomes a node the rebuilt project must show.

Rule. The rebuilt project must account for every node the hardware defines, and the count must survive a reopen.

Arithmetic. Cameras 4 + I/O slaves 1 + controller nodes 1 = 6 nodes. The 4 comes from the controller's printed camera-port count, the single slave from the failing project, and the controller node from modeling the printed communication port as a project node. Add all six in one session, then close and reopen once and count — one reopen replaces six.

Decision. At 6 of 6 nodes after reopen the migration is sound; carry the rest over in groups and repeat the reopen check after each. At 5 of 6 the store is still dropping writes: do not patch it node by node — start a fully fresh project and re-enter the configuration by hand. Then prove each camera node earns its place with a live grab, because a node that enumerates but cannot grab usually lost its address or pixel-format settings in the move.

On where the project lives: a PC-hosted suite keeps its file on your disk, while a vision controller bundles project and runtime on one machine. The MV-VC3301H-128G66 ships with a VM6200Pro license, so the project file and the software that reads it travel together — migrate that file with the same template discipline.

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Checks before you call it fixed

• The add survives a full close-and-reopen, not just the session that created it.
• The node count after reopen equals the hardware budget — 6 of 6 in the example above.
• Every camera node produces a live image. A node that enumerates but cannot grab lost settings in the move; the camera-side half of that persistence problem is covered in GenICam driver fails after restart: fix the camera configuration.
• The I/O slave answers: toggle an input from the suite and watch the state change.
• Triggers fire on the line, not only at the bench.
• The old project file is archived read-only, and the new one has a backup from today.

A rebuilt project that passes all six checks is done. Anything less is a migration in progress.

When the template rebuild fails too

Three escalations, in order of cost.

First, build a fresh, empty project and re-enter the configuration by hand. It is the slow route and the only one that removes every legacy section at once.

Second, align releases. If the project predates the installed release, open and re-save it in the older release, then step forward one release at a time, testing one add at each step. Version chains bite everywhere in vision — 3D camera SDK v2 firmware version mismatch: no device found and MIPI camera driver kernel version match: pin or rebuild are the camera-side twins of the same rule.

Third, if a brand-new project also refuses every add, the fault has moved into the installation. Reinstall the suite from its own installer; copying files between installations recreates exactly the damaged-store problem you are escaping, as camera driver file corrupted: reinstall, don't copy files shows for driver files. And when the tool itself is the endangered part — the vendor has moved on and the project type is stranded — the decision widens to the one covered in smart camera configuration software unavailable: migrate or replace.

If models or jobs vanish after a restart on hardware that otherwise runs, that is the runtime-side cousin of the same persistence fault: missing vision models after a restart: fix and validate walks it.

Prevention: keep the project store healthy

• Pin one release of the suite per cell. Upgrade deliberately, one release at a time, with a migration test after each step.
• Edit projects on local disk. Move them to network shares or sync folders only after closing the suite; sync clients and serializers fight over the same bytes.
• Never hand-edit the project store. When you need automation, use the suite's own export or scripting interface, which writes through the same serializer the GUI uses.
• Put the project under version control and commit after every working change. A commit whose diff shows nothing after an add is the earliest alarm that the write never landed.
• Start every test session from a known state, reopened from disk rather than resumed — the habit 3D camera test flaky on leftover settings: start from a known state makes routine.

Checklist: silent add failure in a vision project

• A brand-new empty project accepts the same add: the suite is healthy, and the old project file is the fault.
• The old project, copied to a local writable folder outside sync, still refuses: the store itself, not a lock.
• Saved as a template, rebuilt from the template, one add, one full reopen: the component persists.
• Node count after reopen equals the hardware budget — cameras in use + I/O slaves + controller nodes.
• Live grab from every camera node, I/O states answer, triggers fire on the line.
• Old file archived read-only, new file committed to version control.

If the rebuild lands on new hardware instead of a repair, the vision controllers category lists the controllers and area scan cameras the cameras to fill the ports. The system configurator walks the whole chain, the systems topic page collects more integration guides, and the contact page puts a migration plan in front of our applications team before the line stops.