Save data before a scene switch: sequence it with an I/O handshake

Press Scene switch on the panel and the controller flips scene instantly — and the data save that should have run first gets cut off. The file loses its tail, or the last inspection results never reach disk. The fix is not a bigger timer between the two commands. It is a handshake: the button pulse raises a data-save request, the controller raises a save-done output once the file is closed, and only then does the PLC pulse the scene-switch input. This guide gives you the wiring, the PLC sequence, a worked 500 ms timing example and the tests that prove the save finishes before the scene changes.

What you need

A vision controller or smart camera that offers both operations — whatever your platform calls its job-data save and its scene or user-set switch — plus a PLC or HMI with two spare discrete outputs and two spare discrete inputs, and the controller's I/O pinout from its own manual, because polarity and sink or source wiring differ between product families.

On a controller line, the vision software and its save and scene commands run on the vision controller. The MV-VC3301H-128G66 is a VC3000-series unit with an Intel Core i3 processor, 8 GB of memory and four built-in light channels: the class of machine that sits beside the PLC and holds the inspection programs.

Where the saved data lands also sets the timing. Mechanical disk writes run far longer than SSD writes, so a controller that logs to a hard drive stresses the wait the most. The MV-VC2140-128G40-1T pairs an Intel N97 processor and 8 GB of memory with a 128 GB SSD plus a 1 TB hard drive.

Decide who sequences the two operations

Two places can own the order. Pick one before you touch a screwdriver.

Inside the vision software. Platforms with event scripts, macros or flow-chart steps can chain the operations: one external input starts a job that runs Data save and then Scene switch. The PLC never sees two commands, so it cannot get the order wrong; keep one done output to the HMI anyway. Prefer this route whenever the software offers it.

From the PLC. When the software cannot chain steps, the PLC sequences them: save request, wait for done, switch request. It costs more wiring, but the order sits on a drawing and the timeout logic lives in one reviewed place.

Both routes share the request–wait–done shape. The soft alternative — writing the request and reading the status over Ethernet — follows it too: the send vision coordinates to a PLC through a register handshake guide shows the register version, and the vision controller to PLC TCP ports and firewall rules checklist covers what must be open before any of it connects.

Name and wire the four lines

Four signals carry the sequence. The names below are suggestions for your own PLC tags and drawing, not a vendor's connector labels.

• Save_Request, PLC to vision: a pulse, never a level. A line left high makes some platforms re-save on every scan.
• Save_Done, vision to PLC: rises when the save has closed the file, drops again when the next save starts.
• Switch_Request, PLC to vision: pulsed only after a Save_Done edge has been seen.
• Seq_Fault, PLC to HMI: your alarm bit, raised when the wait times out.

Polarity, sink or source wiring and the minimum pulse width come from the controller's I/O manual. A 100 ms pulse clears the low-millisecond filtering that industrial discrete inputs apply, with margin to spare.

If the cell already runs a trigger-and-results handshake to the same controller, the save exchange reuses that four-way pattern under new names; a complete PLC trigger-and-results handshake sequence walks the signals in order.

The PLC sequence, step by step

1. Arm check. Accept the button only when the sequence is idle and Save_Done is low. A done line stuck high from a previous cycle must not arm a new sequence.
2. Raise the save request. On the button's rising edge, set Save_Request true and start the 500 ms timeout timer.
3. Wait on the edge. Sample Save_Done every scan; at a 20 ms scan that is the 20 ms poll. Record the elapsed time at the done edge — after a week of cycling, that log is your measured worst case.
4. Fire the switch. On the Save_Done rising edge, drop Save_Request and pulse Switch_Request for 100 ms.
5. Fault cleanly. If 500 ms pass with no done edge, set Seq_Fault, drop Save_Request and hold the current scene. Alarm on the HMI with the active job name.
6. Close the loop. If the vision platform offers its own busy or done line for the scene switch, wait for that too; if not, treat the switch pulse as accepted and return to idle on the next scan.
7. Prevent overlap. Return to idle only after Save_Done has dropped, so two button presses can never run two sequences at once.

Every tag in this listing is one you declare: the BOOL tags start FALSE, the integer starts at 0, and the timer is the IEC 61131-3 standard on-delay TON. No vendor API is involved.

(* Illustrative IEC 61131-3 structured text; every tag is one you declare. *)
(* Btn_Scene, Save_Request, Save_Done, Switch_Request, Seq_Fault : BOOL := FALSE *)
(* Seq_State : INT := 0;   T_Wait : TON;                                        *)
IF Btn_Scene AND Seq_State = 0 AND NOT Save_Done THEN
  Save_Request := TRUE;
  Seq_State := 1;
  T_Wait(IN := TRUE, PT := T#500MS);
END_IF;

IF Seq_State = 1 THEN
  IF Save_Done THEN
    Save_Request := FALSE;
    Switch_Request := TRUE;      (* pulse: clear it on the next scan *)
    Seq_State := 2;
  ELSIF T_Wait.Q THEN
    Save_Request := FALSE;
    Seq_Fault := TRUE;           (* hold scene, alarm on the HMI *)
    Seq_State := 3;
  END_IF;
END_IF;

The listing proves itself with the timeout test in the verification section below: force Save_Done low, press the button, and Seq_Fault must arrive at about 520 ms — 500 ms of timer plus a scan to notice.

Worked example: a 500 ms window polled every 20 ms

This is the timing budget for the handshake as drawn above.

Inputs and their source. The 500 ms timeout and the 20 ms poll are the starting values this design recommends: a job-data save of a few megabytes to a local SSD typically completes in tens of milliseconds, so 500 ms leaves roughly an order of magnitude of headroom, and a 20 ms poll matches a common PLC scan. The 100 ms pulse width covers discrete input filtering with margin.

Rule in words. Polls in the window = timeout / poll interval. The delay the polling adds before the switch pulse is at most one poll interval plus one scan.

Arithmetic:

• 500 ms / 20 ms = 25 polls inside the window
• worst-case done-to-switch delay = 20 ms (last poll) + one scan ≈ under 30 ms
• timeout fault at 500 ms + one scan ≈ 520 ms after the button

Result. A 45 ms save switches at about 60 ms total. A 480 ms save still switches, at roughly 500 ms. A hung controller faults at 520 ms and the scene stays exactly as it was.

Decision. If the done edge lands within the 25-poll window, pulse the switch. If all 25 polls pass dark, fault — never switch anyway. When your log shows real saves longer than 500 ms, raise the timeout to about twice the measured worst case and keep the poll at 20 ms.

Verify it worked

Run these five tests before the panel gets its label:

• Slow-save test. Save your largest job or scene set, the slowest real save you have, and confirm the switch still waits for done. On a hard-disk controller this is the cycle that kills a fixed delay.
• Timeout test. Force Save_Done low — unplugging the line at the controller counts — press the button, and confirm Seq_Fault rises at about 520 ms with the scene unchanged.
• Gap test. Start a PLC timer on the done edge and stop it on the switch pulse, or capture both lines on a two-channel scope. The gap should sit near one poll interval, about 20 ms in this design.
• Power-cut test. Drop controller power during a save and restore it. The PLC must have faulted instead of switching, and the HMI must show a clean state after the controller reboots.
• Repeat run. Twenty consecutive cycles without a stuck line, a missed edge or an overlapping sequence.

Common mistakes

• Switching on timeout. A timeout is a fault. The controller may be mid-write, and switching anyway is the exact corruption the handshake prevents.
• Level instead of pulse on Save_Request. A line held high can make some platforms save again on every scan.
• Done line left asserted. Require Save_Done to drop before the next button press is accepted, or two runs overlap.
• Saving after the switch. The order is the whole point; reversed, the file holds the old scene's data and downstream consumers read stale results. The conveyor vision scene timing guide covers how stale data slips in when order breaks.
• No state on the HMI. The operator needs saving, switching and fault next to the button. If the camera image also lives on the panel, keep them together: the smart camera image in a PLC HMI guide explains what that image actually is.

The same handshake on a smart camera

A camera that runs inspection on the device switches its own scene or user set, and the identical request–wait–done exchange applies; only the connector moves to the camera's I/O. The MV-SC5060XM-08M-WBN (6 MP mono, GigE, M12 mount) and the MV-SC6050C-08M-XBN (5 MP color, global shutter, multi-color light source) are the class of camera that carries that job on board.

Order of work and next steps

Pick the sequencing owner, wire the four lines, set 500 ms and 20 ms, run the five tests, then log save durations for a week. If you are choosing the hardware itself, start on the vision controllers page for a controller-line build or the smart cameras page for a camera-line build; the system configurator walks camera, lens, light and controller in one pass, and more sequencing patterns live on the vision systems topic page. For a wiring review before commissioning, reach us through the contact page.