Missing vision models after restart: configuration recovery

A camera can still deliver clear images while the application has lost its inspection models or remote command assignments. Restarting again may hide useful evidence or overwrite a recoverable configuration. This troubleshooting procedure helps you distinguish an incorrect project from a failed save, changed permissions or replaced files. You will also learn how to restore a verified backup and test configuration persistence before returning the cell to production.

1. Preserve evidence and separate the symptoms

Place the equipment in its documented safe maintenance state before changing projects or testing remote commands. Ordinary vision results and application communications must not substitute for machine safety functions.

Record the application version, active project name, full project path, signed-in account and startup method. Capture the model list, command mapping table and relevant error messages. Preserve application logs and configuration files through supported export or backup tools before saving over anything.

Distinguish these different failures:

• Models are absent from the editor: investigate the loaded project, dependencies and saved configuration.
• Models are listed but find no targets: investigate images, active recipes, model enable states and inspection settings.
• Command assignments are absent: investigate the configuration store, account context and save process.
• Assignments are present but requests fail: investigate communications, permissions and command routing.

Working camera previews prove only that some acquisition functionality remains available. They do not prove that the correct inspection project or command configuration is loaded.

2. Confirm the exact project and configuration locations

Start with project identity before assuming corruption. Two folders can contain projects with identical display names but different model libraries or command assignments.

Read the active path from the application where available. Compare it with the approved production record, not just a recent-files entry. Check shortcuts, startup scripts and service configuration for arguments that select another project or working directory.

Determine whether models and remote command mappings belong to the same saved object. Depending on the software, mappings may be application-wide, project-specific, account-specific or stored separately. Establish this from the documentation for the installed version; do not infer it from file extensions.

Check for these location changes:

• A local project opened instead of the approved network copy.
• A backup or commissioning folder selected by a startup shortcut.
• A different account resolving a relative path to another directory.
• An unavailable network location causing a documented fallback configuration to load.
• An import that restored the project but omitted separately exported integration settings.

For example, a project name may match while its full path points to an older commissioning copy. Matching the name alone is therefore insufficient evidence of a correct load.

If the configuration appears correct but another project owns the active work, use the checks in vision picking project changeover ownership troubleshooting. That is a different problem from settings that fail to survive a restart.

3. Test whether changes actually persist

A model that works during the current session is not proof that its saved representation is durable. Some applications distinguish between applying an edit, saving a project and exporting integration settings.

In an isolated test environment, use the documented save process and check its completion status. If the software has separate project and communications saves, verify both. Review warnings about read-only locations, unavailable storage, insufficient space or denied access.

Use the intended runtime account for persistence testing. An interactive account may have different file access from an application service or scheduled startup account. Correct the specific folder permissions through the approved administration process; do not grant broad administrative access as a workaround.

Check the relevant logs for the actual save destination and any rejected write operation. File modification times can support the investigation, but they cannot prove that every setting was written successfully.

When startup automation also writes camera settings, investigate it separately using trigger overlap configuration and startup write verification. Restoring inspection models does not establish that acquisition settings are correct.

4. Look for replacement, partial restoration and version changes

When both model definitions and command assignments revert, investigate anything capable of replacing their configuration stores. Examples include deployment scripts, automated synchronization, backup restoration and software maintenance.

Correlate application logs with authorized maintenance records. Compare file metadata and, where permitted, checksums against a verified backup. A checksum difference proves that files differ; it does not identify which copy is correct.

Do not edit proprietary project files, binary model data or undocumented configuration databases. A readable file is not necessarily safe to modify manually.

If a software change preceded the incident, use the machine vision software upgrade validation checklist to structure compatibility checks and any supported rollback.

5. Restore a verified backup through supported tools

Choose a backup by provenance and content, not simply by its newest timestamp. A recent copy may already contain the missing configuration.

1. Preserve the failed state. Export what remains and retain logs before importing or saving another configuration. Record the incident time and application version.
2. Identify a known-good revision. Use commissioning records, approved change records or previous acceptance results to establish which backup contains the intended models and assignments.
3. Check the backup scope. Confirm whether it includes project data, model dependencies, calibration, recipes and remote integration configuration. List anything stored separately.
4. Confirm software compatibility. Follow the documented restore or migration procedure for the installed version. Obtain required software and licensed components through authorized channels.
5. Restore in an isolated environment where supported. Prevent unexpected machine commands while checking that the project opens and its dependencies resolve.
6. Restore separate integration settings. Use the application's documented import or configuration interface. Do not copy unknown files into guessed directories.
7. Save to the approved destination. Verify the destination and save result, then close the application normally before testing another load.

A verified backup should have an identifiable revision, source location and acceptance history. It should also preserve the relationships between project data and separately managed settings.

If no trustworthy backup exists, rebuild models and command assignments through supported interfaces using approved requirements. Do not invent command values from memory or accept populated defaults as evidence of correctness.

For assignments that remain visible but address the wrong destination, consult vision project controller mapping transfer troubleshooting. A restored table can still contain an incorrect destination mapping.

6. Verify content, behavior and restart persistence

Validation needs three layers: the configuration exists, it behaves correctly, and it survives the intended startup sequence. Passing only the first layer leaves substantial uncertainty.

First, compare model names, enabled states, recipe associations and command assignments with an approved manifest. Counts are useful screening checks, but equal counts do not establish equal content.

Next, test detection with a controlled image set containing known-good parts, expected rejects and difficult conditions. Record the selected recipe, expected decision, actual decision and relevant position or orientation results. Use approved tolerances rather than visual agreement alone.

Test remote commands separately. Verify the request, acknowledgement, selected destination and resulting application state. Observe duplicate or ambiguous command assignments and the software's documented response to unknown requests. Use a documented simulation or isolated test method where available.

Worked restart example

Suppose an illustrative acceptance plan contains 20 reference images and 4 remote command mappings. Run the checks after 3 normal application restarts under the intended runtime account:

For each restart, record the full project path and compare configuration content before executing the tests. Any missing model, changed assignment or unexpected response requires investigation, even if the total counts match.

These numbers illustrate test coverage, not a reliability guarantee. Include a host reboot or other startup condition if it belongs to the approved acceptance plan. Perform power-cycle testing only through the equipment's documented shutdown and startup procedures.

If recipe selection changes the apparent model set, review local vision recipe switching from operator buttons. An inactive recipe can resemble missing content without any file loss.

7. Locate the configuration owner before considering hardware

Configuration recovery is primarily a software and storage investigation. Replacing a camera is not a supported remedy for missing host-side project data.

For vision controllers, determine which device owns the project, which account runs the application and how its configuration is backed up. The controller category helps identify hardware options, but project compatibility requires separate confirmation.

The MV-VC2101-128G40-NN is a controller example for a documented compatibility review. Its catalog listing does not establish support for a particular project format or recovery procedure.

With area scan cameras, distinguish acquisition configuration from the inspection application's saved models. The LS-CMR-0395 is an acquisition hardware example, not a configuration-recovery tool.

For smart cameras, establish whether the inspection job resides on the device, on a host or in both locations. Consult the documented backup scope rather than assuming a host project contains everything.

Use the camera finder or camera configuration step only when a separate hardware requirement has been identified. Neither replaces validation of the restored application.

8. Prevent recurrence and release the cell deliberately

Close the investigation with a reproducible startup and recovery record. A successful restore without an understood save destination can leave the original failure mechanism in place.

Before release, check the following:

• Approved paths recorded: document the project location and each separate configuration store so startup does not depend on recollection.
• Runtime account verified: test the intended access permissions and startup method, not only an interactive engineering session.
• Save boundaries documented: identify which actions save models, recipes and remote command assignments.
• Replacement processes reviewed: confirm that deployment and backup jobs do not restore obsolete configuration unintentionally.
• Backup restoration demonstrated: retain an approved copy that has actually passed a supported restore test.
• Acceptance evidence retained: save configuration comparisons, image results and command-response records with the revision.
• Production release authorized: complete the site's machine restart and safety checks before enabling automatic operation.

Investigate unresolved differences before release rather than normalizing them as harmless defaults. Keep the failed configuration and incident records until the cause and corrective action are documented.

If you need help identifying compatible vision hardware, bring the application version, configuration ownership map and acceptance requirements to technical support. For a persistence fault, those records are more useful than a camera replacement request.