LabVIEW VI never advances: fix the vision inspection state machine

You wired a LabVIEW VI into a vision inspection to read the machine speed and compute the camera's line rate. You press run, the first step lights up, and nothing else ever happens: the acquisition and inspection steps never fire, and stopping the run is the only way out. The cause is almost never the arithmetic; it is the shape of the VI. An inspection step calls your VI and waits for it to return, and a VI whose while loop waits for a stop button that nobody can press never returns. Work through the checks below and you will find the blocking construct, strip the loop so the calculation runs once and returns, keep the camera session out of the step, and hand the computed line rate to the acquisition step as a plain number.

Why does the inspection sit at the first step and never advance?

The inspection sits at step one because the Run LabVIEW step is still executing: your VI contains a while loop whose only exit is a front-panel stop button, the step never shows that panel, so the button is never pressed and the VI never returns.

That is the whole mechanism, and it matches the symptom exactly. The step runs your VI as a subroutine, without a visible front panel and without an operator. Your three-state design, calculate the line rate, acquire, inspect, back to calculate, is a state machine, and the inspection's own step list is meant to be that state machine's outer loop. Putting a second, user-stopped loop inside state one deadlocks the pair: state one never completes, so the transition to state two never fires. The software is not stuck in the sense of an error; it is doing exactly what the diagram says, iterating until someone presses stop.

You can confirm this in ten seconds. Run the VI alone in the development environment: it computes once, then spins until you click stop. That click is the event the step can never deliver, which is why closing the VI looked like the only way forward. An abort does break the loop from outside, but it is the wrong fix, for the reason the warning below gives.

What does the Run LabVIEW step expect a VI to do?

The step expects a VI that runs once: read its inputs, do the calculation, write its outputs, and return, which for a two-operation calculation means microseconds, because the inspection calls the step again on every cycle through the states.

Hold the VI to that contract and the hang disappears:

• Inputs wired in as values: machine rpm, feed per revolution, sampling pitch.
• A straight-line body: no loops, no dialogs, no waits.
• Outputs as terminals the step can read: the line rate as a number.
• Nothing that touches the camera: acquisition belongs to the acquisition step.

The state machine itself is the step list. Calculate is state one, acquire is state two, inspect is state three, and the loop back to calculate is the transition logic. The classic while loop with a case structure belongs to the host, and your VI is one case's body. The same run-once-and-return contract is what lets a step hand results to code outside the inspection, as in Smart camera LabVIEW integration: use inspection results as data.

Which constructs in the VI block the state machine?

Four constructs block a step, in the order we meet them: a while loop waiting on a front-panel stop, a camera session opened inside the step, a hidden dialog waiting for input, and an input wired from a source that never produces a value.

The camera case hides behind the first one, so check it deliberately. The acquisition step opens the camera's session when the inspection loads and holds it for the whole run, and one camera serves one session; a second session from inside your calculation VI fails with the camera-already-in-use error before a single frame arrives. Keep every grab and session call out of custom steps. That one-session rule is what the multi-camera acquisition session architecture is built around, and it is also why a camera node refuses to write when another application holds the device, as in GenICam node not writable: check camera access state.

How do you rewrite the VI to calculate once and return?

Delete the while loop and let the diagram run straight through: wire rpm in on the left, compute the line rate in two operations, write the result to an output indicator, and the step returns by itself.

1. Open the calculation VI and select everything inside the while loop except the stop terminal.
2. Move that code to the top level of the diagram and delete the loop, the stop button and the shift registers; each pass recomputes from the live rpm, so no history is needed.
3. Wire rpm, feed per revolution and sampling pitch as input terminals, not as front-panel prompts.
4. Compute web speed and line rate with the two formulas in the next section.
5. Wire the result to a numeric output indicator the step can read.
6. Remove any camera, grab or session node you carried over from the old version.
7. Save, run it standalone, and confirm it computes once and stops with no interaction.

How does the calculated line rate reach the acquisition step?

The VI outputs the line rate as a plain number, and the acquisition step applies it to its Line Rate attribute, so the camera's line rate follows the machine on every cycle instead of being typed in once.

Worked example. The machine turns at 1,800 rpm and feeds 25 mm of web per revolution, and the smallest defect you must catch is 0.5 mm, so you sample every 0.25 mm along the motion, two samples across a defect.

• Web speed: 1,800 rpm ÷ 60 = 30 rev/s; 30 rev/s × 25 mm/rev = 750 mm/s.
• Line rate: 750 mm/s ÷ 0.25 mm/line = 3,000 lines/s, so the output indicator reads 3000.0.
• Exposure ceiling: (0.25 mm ÷ 2) ÷ 750 mm/s ≈ 167 µs; set 100 µs and motion blur is 750 mm/s × 0.0001 s = 0.075 mm, about 0.3 of the pitch.
• Slowdown: at 1,200 rpm the next pass computes 1,200 ÷ 60 = 20 rev/s; 20 rev/s × 25 mm/rev = 500 mm/s; 500 mm/s ÷ 0.25 mm/line = 2,000 lines/s.

The VI returns 3000.0 on the first pass and 2000.0 after the slowdown, and the acquisition step applies each value to its Line Rate attribute with no edit and no restart. This is the runtime pattern behind Make line scan line rate follow machine speed at runtime, and passing a number at run time also covers Runtime camera parameter control: exposure and white balance live when exposure must track speed as well.

How do you verify the fix before running production parts?

Three checks take about five minutes: the VI runs and stops on its own with no click, it returns the right number at two known speeds, and the full inspection cycles calculate, acquire, inspect and back without stalling.

1. Standalone run: start the VI by itself; expect one computation and a clean stop with zero interaction. Anything that waits is a wait node to remove.
2. Numbers: with a 0.25 mm pitch and 25 mm/rev feed, the indicator must read 3000.0 at 1,800 rpm and 2000.0 at 1,200 rpm.
3. Cycle test: run the inspection and let it cross calculate, acquire, inspect and back at least ten times; the absence of the camera-already-in-use error on the first pass confirms no second session.
4. Follow the speed: change the machine speed between passes and confirm the next acquisition adopts the new line rate without a restart.

Once acquisition cycles, the next bottleneck to watch is processing time. If the camera delivers frames faster than the inspection finishes them, that gap and its fixes are covered in Acquisition faster than processing: fix the frame rate gap.

How do you keep the next inspection from hanging the same way?

Build every custom step to the same contract, inputs in, straight-line computation, outputs written, return, and reserve while loops and camera sessions for the host inspection, where they are managed for you.

Checklist for the next time you wire custom code into an inspection:

• No while loops in a step VI; looping belongs to the inspection's step sequence.
• No camera, grab or session nodes in a step; the acquisition step owns the camera.
• Outputs as readable terminals, computed from live inputs each pass, so speed changes propagate.
• Every step VI tested standalone: it must start and stop with no interaction.
• If the whole loop moves onto a smart camera instead, the same contract holds there too: one pass per trigger, no hidden waits.

The inspection software, its Run LabVIEW step and the camera session all live on the vision controller, so the box you pick needs the LAN ports for your cameras and the built-in channels to drive the lights without an external unit. The MV-VC3301H-128G66 pairs an Intel Core i3 with a VM6200Pro license for the inspection software.

For lines that log every frame, the MV-VC2140-128G40-1T runs an Intel N-series processor and carries a large hard drive for image archives.

Both sit in the vision controllers range alongside the rest of the options, and more run-time patterns like this one are collected on the systems topic page. If you want a review of the inspection architecture before you deploy, contact us.