Teach pendant storage limit: split vision program files

You teach the next part, press save, and the pendant refuses. After the failed save the main program reads 0 MB and will not load, and the installation file that carries the snapshot position will not load either. Nothing is wrong with the camera or the teaching: the controller's program partition is full. This guide follows the failure in the order you meet it - where the taught models actually live, what to delete first, how many locate subprograms one program file should hold, how to split fifty taught parts across files without re-teaching any of them, and when the durable fix is to move locate onto a vision controller or smart camera. The reference numbers come from a controller whose program partition measured 1.8 GB and reported 100% used.

Why does saving fail while the camera still works?

The save fails because the pendant's program partition is full, not because the camera lost anything: in the case behind this guide the root partition is 1.8 GB and reports 100% used, so the save cannot write and the file is left at 0 MB.

The free -h output quoted in this situation reports memory, not disk: 1.8 GB total, 1.6 GB used, 215 MB free, with 577 MB of that sitting in cache the operating system releases the moment a task needs it. The failing resource is the next line down: the disk entry for the root partition, shown as /dev/disk/by-uuid and mounted on /, at 1.8 GB with 0 bytes free.

At 100% every write fails, including program saves, teach data and logs. A save that dies mid-write leaves a 0 MB program file, and a 0 MB file cannot load - exactly the state after the failed save. Treat a partition pinned at 100% as a stop condition: each further teaching attempt risks truncating another file.

Where are the taught objects stored?

Taught objects live on the pendant disk in two files: the program file holds the locate-and-pick subprograms you wrote, and the installation file holds the snapshot position, the calibration and the camera-side taught data, so every new object grows both files at once.

That split explains why the next object is the one that breaks the save: with 0 bytes free there is nowhere for either file to expand. It also sets the recovery order - copy before you clean. Copy every program file, the installation file and the calibration files off the controller, over its network share or a USB drive, before anything is deleted, because a lost installation file means re-teaching the snapshot pose and re-checking calibration from scratch.

Fixed storage is always a budget you plan around: the same accounting drives machine vision image retention within a storage limit, and a smart camera manages its own program storage the same way, as smart camera program storage and offline editing explained describes.

How many locate subprograms should one program file hold?

Keep fewer than ten locate subprograms in one program file. That cap keeps each file small enough to save and load comfortably on a pendant-sized partition, and it is the working limit practitioners settle on for locate-and-pick programs; fifty subprograms in a single file is what filled this controller.

Every locate-and-pick subprogram carries its locate node, its gripper outputs and its motion block, and a save has to write the whole file each time the operator touches any part of it. Size grows with every subprogram, and so does the cost of each save, load and edit.

Nine per file is deliberate: it keeps every file under the ten-subprogram line with room for one late addition, so the split survives a growing family.

What should you delete before touching the programs?

Delete the .old backup files in the program folder first. Each one is an earlier version of a program the controller keeps alongside the live file, and where they have piled up over months they free real space immediately.

After the .old copies, remove the obvious dead weight: backups of retired programs and trial files left over from commissioning. Then measure instead of guessing - the disk report shows the root partition's used percentage directly, and the cleanup target is 20% of the partition free, which here is 0.20 x 1.8 GB = 0.36 GB = 360 MB. The margin is not arbitrary: the controller writes logs and temporary data continuously, and the largest regular write, the program file you edit most, has to fit in what remains. Below roughly 10% free, 180 MB on this partition, saves start failing again.

How do you split fifty parts across files without re-teaching?

Split the parts into six program files of nine locate subprograms or fewer, all pointing at one shared installation file, and let a short dispatcher select the right file for the current batch - no part is taught twice and every save writes one small file.

1. Export everything first. Every program file, the installation file and the calibration files go to a network share or USB drive. Nothing on the pendant is deleted until a copy exists elsewhere.
2. Keep exactly one installation file. Snapshot position, calibration and camera settings live there once, and all six program files reference that same file. A private installation copy inside every program is the duplication that eats partitions.
3. Group the subprograms by part family. Fifty rectangles sort by the sizes that run together in a shift, nine per file, giving six files (50 / 9 = 5.6, rounded up). Name files by family so the operator sees at a glance which one to load.
4. Replace the fifty-branch if-loop with a dispatcher. One short main program asks which family is running and loads that file, the same top-level pattern as structure a vision-guided pick and place program around drop targets.
5. Collapse fifty models into one parametric model. Every part here is a rectangle differing only in length, width and height: teach the rectangle once and feed dimensions from a table. Parametric teach for geometric parts shows how a parameterized model replaces one teach per size, the deepest cut in file size this case offers.
6. Test, then measure. Load each program file against the shared installation, run one locate per family, and edit-save a small change to confirm writes succeed. Finish with a disk check: at least 360 MB free on the 1.8 GB partition.

When is moving locate off the pendant the better fix?

Move locate off the pendant when the part list keeps growing: the pendant's partition is fixed at manufacture, so no cleanup raises its ceiling, while a vision controller or smart camera holds the models on its own storage and hands the robot plain coordinates.

A stable part set needs nothing more than the split above. A list that keeps adding sizes keeps adding weight to a disk that cannot grow, and that is the point to move the models to a vision controller or to the camera itself. The split also takes image processing off the pendant's 1.8 GB of RAM, which otherwise shares its budget between robot control, screen and image buffers - the squeeze described in out of fast frame buffer memory.

The MV-VC3301H-128G66 gives the locate job an Intel Core i3 processor, 8 GB of memory, a 128 GB SSD and 4 built-in light channels, with 5+ LAN ports for cameras and cell I/O. The MV-VC2140-128G40-1T holds the same 8 GB of memory and 128 GB SSD on an Intel N-series processor and adds a 1 TB HDD for images and logs. The MV-VC5525-256G70-NN steps up to a 12th-gen Core i5 with 32 GB of memory, a 256 GB SSD, PoE camera ports and 8 built-in light channels.

Where one camera covers the whole cell, the camera can be the vision device: the smart cameras run the locate on the sensor and send results straight to the robot. The MV-SC5060XM-08M-WBN is a 6 MP mono GigE smart camera with an 8 mm M12-mount lens, the shape that suits a fixed snapshot position over a family of rectangles.

Size the lens by sensor width: a 1/2.4-inch-type sensor runs about 5.7-6.2 mm across by the inch-type convention, so an 8 mm lens covers 5.7 / 8 = 0.71 to 6.2 / 8 = 0.78 of the working distance. At a 300 mm working distance that is roughly 215-232 mm of width - an estimate from sensor width alone, but enough to check whether the rectangle family fits one snapshot.

How do you keep the partition from filling again?

Run prevention on three numbers: fewer than ten locate subprograms per program file, exactly one installation file, and at least 20% of the partition free after every teaching session.

• Export after every teaching change. A failed save then costs an import, not a re-teach - the difference between ten minutes and an afternoon.
• Delete .old files after heavy teaching sessions. Each save leaves its predecessor behind, so a day of edits can hold more backup than live program.
• Teach families, not parts. A new rectangle size is a new row of length, width and height in the parameter table, not a new taught model, so file size stays flat as the list grows.
• Watch the disk number. Anything trending under the 20% line gets cleaned the same week, not later.
• After any erase, re-calibrate and re-validate safety before the next production run.

If your part list is drifting toward the same wall, size the offload before the partition fills again: the smart camera finder covers one-camera cells, and camera count, part families and cycle rate are enough for a sized controller recommendation through the contact page. The systems topic page collects the neighboring guides on program structure and storage.