Name is not defined compile error: fix stale variables in scripts

Your vision program has compiled for months; today the compiler stops on a name you never typed: name 'nb_occurence_0' is not defined. The reflex is to comment blocks out and back in until the build passes. That works by accident, and it breaks again on the next edit, because the ritual never touches the cause. This page shows where generated variables come from, why deleting or moving a single node leaves live references to a dead name, and how to audit the script once so the fix is deliberate. It is written for anyone maintaining node-generated vision and robot programs: camera locate steps, gripper loops and output logic that the software writes for you.

What the compile error is actually telling you

Node-based programs have two layers. The tree you edit — the locate, gripper and digital output blocks — is the source of truth. The flat script in the advanced view is generated from that tree every time you edit or compile.

Each node contributes two things: code, and variables that carry its results. A locate node writes the number of parts it found into a counter; a later loop reads that counter to size the pick sequence. The error means a read survived while its definition did not. The compiler checks names before any image is taken or any bus message is sent, so the hardware was never addressed and the fault sits in the program tree.

The same reference-without-definition failure shows up across plant software, not only vision: a walkthrough of a global name not defined in a script module follows the identical mechanism in a control-room system. Keep this fault separate from its cousin: a name that compiles fine but carries last cycle's value is a stale result, and the fix there is to trigger a fresh measurement per pick.

Likely causes, most probable first

1. The defining node was deleted. A process change removed the locate or count step, but later nodes still read its counter. Test: search the script for the name; if every hit has it on the right of an equals sign or inside a condition, nothing defines it.
2. The node was re-added or duplicated, and the index moved. Generators index variables per node instance, so a rebuilt node writes a new suffix while old reads still point at the old one. Test: look for a near-identical name that differs only in the trailing number.
3. The node moved below its first use. The script runs top to bottom, so a definition after the read is no definition at all. Test: the assignment's line number is larger than the read's.
4. A block was pasted in from another program. The paste carried references that do not exist in this tree. Test: the missing name never appears on the left of an assignment anywhere in the script.
5. A software upgrade changed the generator. The error appears immediately after an update and many names change shape at once. When the break comes from an upgraded camera library rather than your own edits, fixing camera SDK build errors after a library upgrade is the closer match.

Renaming deserves its own caution: node names feed the generated code, and non-ASCII characters in a name break the locate node in ways that mimic this error. Keep node names to plain letters and digits.

Audit the script once: map every use to its definition

Open the advanced view and work through four steps.

1. Search for the exact missing name, case included.
2. Classify every hit: an assignment (nb_occurence_0 = 3) is a definition; the name inside a condition or a calculation is a use.
3. Compare line numbers. Every use must sit below its definition, because the script executes top to bottom.
4. Decide from the map. No definition means the owning node is gone: restore it or delete the reads. A definition below the first use means the node moved: drag it up. A differently indexed sibling nearby means a rename or rebuild: remap the reads.

The pattern behind almost every case (illustrative lines, not a vendor's API):

# definition, written by the camera locate node
nb_occurence_0 = 3
# use, written by a later pick node
while nb_occurence_0 >= 1:
    # pick one part, then count down
    nb_occurence_0 = nb_occurence_0 - 1

Worked example: the locate step finds 3 parts, so the generator writes nb_occurence_0 = 3. The loop runs 3 − 1 = 2, then 2 − 1 = 1, then 1 − 1 = 0 and exits: three picks for three found parts. Delete the locate node and the while line reads a name with no definition, so compilation fails before the robot moves. Delete the loop instead and the counter compiles unused; the program simply never picks. That asymmetry is why the audit matters — it tells you which side of the pair to rebuild. On a typical mid-size program the whole audit takes about 10 minutes once you know the four steps.

Fix it in one pass

1. Export a dated copy of the program before editing anything. Structural edits are easier to cause than to undo.
2. Restore the definition. Re-add the locate or count node above the first use, or drag the existing node above it.
3. Note the new name. A re-added node usually gets a new index; if the node now writes one suffix and the reads say another, remap every read, or rename the node's output back if your software lets you set it.
4. If the step is gone for good, delete the reads and everything built on them: the loop and any output pulse driven by it.
5. Recompile. The error should clear without any hardware being touched.
6. Run one cycle to prove the program, not just the compile.

Why comment-and-uncomment ever seems to work

Every toggle is an edit, and every edit regenerates the whole script from the tree. Toggling blocks changes what is active and in what order, so sooner or later one combination lands with the definition above the use and the build goes green. Nothing was repaired. The orphaned reference is still in the tree, and the next rename or reorder breaks it again. The ritual is a blind search over block combinations; the audit above is the same search with the answer visible, done in one pass.

Where these variables come from on the vision side

The counter, the positions and the match score in your script are the camera node's published results. If you script against them directly, it helps to see how scene result variables are read from your script. On the hardware side, this kind of program lives in one of two places: a compact camera that runs the inspection itself, or a controller-class unit that hosts the vision application and writes the robot-facing script.

A camera that runs inspection on the device keeps the whole loop in one housing. The smart cameras category covers them; a model such as the MV-SC3050XC-16M-ATN-H — 5 MP colour, global shutter, M12 mount — publishes locate results as scene variables like the one in this error.

When the vision application runs on a controller instead, the robot sees the script that unit generates. In the vision controllers category, a unit such as the MV-VC3301H-128G66 — Intel Core i3, 8 GB memory, four built-in light channels, VM6200Pro license included — runs the vision software and outputs that script.

When the missing name is one you wrote

Then the fault is on your side, and two classics produce the identical message. Spelling and case: the generated counter in this error is spelled occurence, with a single r in the middle where the English word has two, and names are case-sensitive — one different character raises the same error. Scope: a name assigned inside an indented function or branch is not visible where the failing read runs; move the assignment above the read at the same level, or pass the value in explicitly.

Missing variables also bite inside node logic. A calculator step fails on unavailable variables when an input name it references was never produced upstream. The failure class is not vision-specific either: PLC projects surface it as compile warnings for code that was never generated, where a program references output the build never produced.

Prevention: keep the tree and the script in agreement

• Rename nodes only through their property fields. Text typed into a generated region vanishes at the next regeneration and desyncs the name map.
• After deleting any node, recompile immediately and search the script for its output names. The orphan is cheapest to catch while you still remember which node you removed.
• Export a dated copy before structural edits and keep the last known-good file, so a broken tree can be rolled back instead of reverse-engineered.
• Treat generated regions as read-only, and place your own counters and flags in dedicated script-code nodes above their first use.
• Copy blocks between programs sparingly, and re-check every variable a pasted block reads against the new tree.
• After a software upgrade, recompile once before production; wholesale naming changes surface at compile time, not mid-shift.
• If a program misbehaves after edits with no compile error at all, stale leftover settings are the cousin problem: start from a known state and re-verify.

Once the audit habit is in place, this error costs minutes, not evenings. If you are sizing the vision side that generates these scripts anyway, the camera finder filters by resolution, shutter and mount, and where the application needs a separate compute box, compact industrial mini PCs are the usual host. More fixes in this series sit on the systems topic page, and the learn hub indexes the rest.