Own your trained model weights: export, archive and deploy locally

Trained-model weights are production assets, like PLC programs and camera files: the line stops without them. In one reported support case, a detector trained locally and uploaded to a hosted training platform kept serving hosted inference while its weights download returned a storage error saying the stored object did not exist. The vendor confirmed a platform-side fault, and the suggested workaround was to retrain on the platform — no workaround at all for weights trained somewhere else. This guide is for engineers who train detection or classification models and deploy them to production lines. It sets out the archive bundle to produce after every run, the checks that prove a portable export is good, and the controller sizing that keeps inference running on hardware you own.

A model you cannot download is not yours yet

The decision comes first: never let a hosted platform hold the only copy of your trained weights.

The failure pattern is narrow and easy to miss. The model trained fine on a local workstation. It uploaded through the platform's SDK, and hosted inference on it ran every shift. Weeks later, the download request failed with a 'key does not exist' storage error. The support checks — workspace and project IDs, API key, SDK version — all cleared, because the upload genuinely had succeeded. The platform simply could no longer produce the stored object.

The lesson: serving inference and storing a downloadable copy are two separate promises, and either can break on its own. Support can restore neither the file nor the training session behind it. So the rule for production work is two formats, two storage locations, copied at run time — not next week, not when the project wraps. Everything below puts that rule into practice.

What to archive after every training run

A training run produces more than the weights file. The archive bundle is what lets an engineer redeploy the model years later, without the original workspace, dataset or login. Keep all of it in one folder per run:

Export to a portable format, then prove the copy

ONNX is an open format for representing trained models, and the common inference paths on a line — from the OpenCV DNN module to a dedicated ONNX runtime — read it. Export once per run, immediately after training, while the native weights and the recorded metrics sit side by side.

An export fixes the input size: the graph is built for the resolution you export at, so record that size next to the file. If training used non-square images, the export size interacts with the training image size and rect mode; the non-square YOLO training guide covers that pairing.

Then prove the export before it becomes the deployment copy:

1. Load it in the runtime version production will use, not just the newest one on your workstation.
2. Run your labelled validation set through both the native model and the export. Small numeric drift is normal. A systematic confidence drop across classes usually means preprocessing does not match training, which the preprocessing mismatch guide helps you pin down.
3. Record the file size and a SHA-256 checksum at export, and compare after every copy. A mismatch means a truncated or partially written file; the truncated weights file guide lists the signs.
4. Time the export in that runtime. The same ONNX file performs differently across runtimes, and the runtime choice guide explains where the milliseconds go.

Where the copies live

Three locations, each independent of the others:

• Training PC — the working copy, next to the dataset references and run notes.
• Shared drive or NAS — the copy your controls engineer can reach from the line's panel without borrowing the training workstation.
• Removable media — an offline copy kept with the line's documentation, safe from ransomware and from the NAS being repurposed.

Name each folder with the project, date and run number so the newest good bundle is obvious during a 6 a.m. restart. Keep every production run's bundle, not only the latest one: a rollback is only possible to a run you archived. Size is not the constraint — a detection-model bundle runs from a few tens of megabytes to a few hundred — and even a compact vision controller carries a 128 GB SSD, with models such as the MV-VC2140-128G40-1T adding a 1 TB HDD for exactly this kind of on-machine archive.

A hosted workspace is none of these three. The support case above ended with the suggestion to retrain on the platform and download those weights, which only works when the training happened there. If you are moving weights out of a hosted platform while download still works, the hosted-platform model export walkthrough covers the export paths, IDs and deployment options.

The same copy-and-verify habit covers the rest of the line's deployable files: deploying an exported robot program to a robot controller follows the same export, copy, verify and archive sequence, and the robot program deployment walkthrough shows one complete example.

Run inference on hardware you control

Once the export is verified, choose where it runs. Three options cover most lines.

On the camera. Smart cameras inspect on the device with no PC, which removes the archive-and-runtime problem almost entirely: the camera's own environment manages the model. The catch is import support, so check whether the software accepts a model you trained elsewhere. The MV-SC5060XM-08M-WBN, for instance, is a GigE smart camera with a built-in 8 mm M12 lens that runs its inspection on the device.

On a vision controller. The default when you own the ONNX file: PC-class hardware in an industrial housing, with several Ethernet ports for cameras, PLC and service, plus built-in light-controller channels so the strobe wiring lives in the same box. Browse the vision controllers; the system configurator narrows the field by ports, memory and mounting. If you prefer to run the model on your own office-grade hardware instead, dedicated industrial mini PCs cover that route.

On an inference terminal. When models are large or camera counts climb, an AI inference terminal sits between cameras and PLC and does nothing but infer. The MV-VAC5724-256G02 is one such terminal, with PoE camera ports and 8 built-in light channels.

For the software side — which stages run on the camera and which on the host — the edge inference deployment guide lays out the split. If the product is anomaly detection rather than object detection, the ONNX anomaly detection guide shows the same weights-to-decision path, from score maps to pass/fail outputs.

Worked example: port and light-channel budget for a two-camera station

Case: one station inspects both faces of an assembly. Inputs: two GigE cameras, one strobed light per camera, results to the PLC over Ethernet, a service laptop during commissioning, and a second identical station planned next year. The station counts are the inputs; the capacity figures come from the controller data sheets.

The sizing rule has two lines:

Arithmetic:

• Ports: 2 cameras + 1 PLC link + 1 service laptop + 1 spare = 5 Ethernet ports. A controller with 3-4 LAN ports runs today's cameras and leaves nothing for commissioning or a hot swap.
• Light channels: 1 light per camera × 2 cameras = 2 channels today, rising to 4 when the second station duplicates the first.

Decision: buy to the five-port, four-channel budget, not to today's two channels. The MV-VC3301H-128G66 meets it with 5+ LAN ports, 4 built-in light channels, 8 GB memory and a 128 GB SSD — the right machine while the model is small and the streams are few. When the second station arrives or the model grows, the MV-VC5525-256G70-NN steps up to PoE camera ports, 32 GB memory and 8 built-in light channels.

Acceptance checks before the line relies on it

Five checks turn 'we think the line is running v3' into a checked fact:

• Disconnect test. Unplug the link to the hosted platform and the office network, and run a full shift from the local controller alone. This is the test the support case above would have failed.
• Checksum on target. Recompute the SHA-256 of the deployed file on the controller and match it to the archive record.
• Class-order match. Confirm the output indexes map to the class names the PLC logic expects; an off-by-one passes images and rejects good parts.
• Per-condition agreement. Compare production captures with the training-time metrics per condition — lighting, orientation, line speed — as the model generalization guide sets out.
• Rollback bundle. Keep the previous run's archive on the controller or NAS, so a bad deployment reverts in minutes.

Total effort is about an hour per run.

Where to go next

Export the latest run's weights today, verify the ONNX against your validation set, and put both copies where the line can reach them without a login. If the deployment target is still undecided, the systems topic page collects the rest of the deployment reading, and free expert support comes with every order if you want a port and channel count checked against your station list before you order.