Save a triggered image to disk with a numbered filename

A push button on the trigger input is the simplest capture station you can build: the operator places the part, presses, and one image lands on disk. The filename is where these stations go wrong. Save to a fixed name and every press overwrites the last image; leave the camera in free-run and the save loop fills the folder with frames nobody asked for. This guide gives the wiring, the acquisition setting, the event-driven save and the counter scheme that produces image_0001, image_0002 and so on with no collisions, plus the storage arithmetic to run before the first shift. It applies to any machine-vision camera you drive from an SDK, and to smart cameras that log images on the device.

What you need

• A camera with a hardware trigger input on its power and I/O connector; the manual's pinout page names the input line and its reference lead.
• A push button: a plain dry-contact button, or a three-wire sensor-style button with a PNP output.
• A power and I/O cable with open leads on the camera end, so the button wires can land on bare conductors.
• The capture side: your camera SDK on a PC, or the smart camera's own job editor with its image-save output enabled.
• A target folder on a local drive, sized by the storage arithmetic below.

Wire the push button into the trigger input

Start with the polarity, because it decides the wiring. A PNP device pushes the positive wire: its output carries +24 V when pressed. An NPN device pulls its output down to 0 V. The common three-wire convention is brown to +24 V, blue to 0 V and black as the switched output, but confirm with a meter before you trust the colors.

For a PNP button, land the black output on the camera's trigger input and tie the input's reference lead (the COM pin on the same connector) to 0 V. A plain dry-contact button instead wires between the trigger input and its reference, with the camera's own trigger supply feeding the loop. Keep the trigger pair twisted and route it away from the camera's power run.

The camera end of this lands on the power and I/O cables that bring the connector out to open leads; choose the length for the route the cable must take, not just the straight-line gap.

One safety line: this button is an operator convenience, never a safety function — keep it clear of the cell's emergency-stop circuit entirely.

Put the camera into hardware-trigger acquisition

Cameras ship in continuous acquisition (free run): they stream frames as fast as exposure allows, and no button matters. Three GenICam features switch that off: set TriggerMode to On, set TriggerSource to the input line your button lands on, and set TriggerActivation to RisingEdge for a PNP button that pulls the line high. On a smart camera the same switch lives in the job editor's acquisition settings; the wording differs by software, the sequence does not.

Two failures cover most of the support traffic. A camera that ignores the button is usually still in free run; a camera that takes exactly one frame and stops is usually left in a single-shot acquisition mode. Both have write-ups: stopping the free-run default and why a trigger fires once then stops.

The save routine step by step

Drive the save from the frame event, once per accepted trigger — not from a job loop that may run zero times or several times per image.

1. Seed the counter: scan the target folder for existing image_ names, read their numeric suffixes and set the counter to the highest number plus one.
2. Arm the acquisition in hardware-trigger mode, source set to the button's input line.
3. On the frame-acquired event (your SDK's frame-ready callback; on a smart camera, the job's image-save output on trigger), compose the filename: the prefix image_ plus the counter, zero-padded to four digits.
4. Write the file from a worker thread, never inside the callback; disk writes in a callback can stall acquisition.
5. Increment the counter only after the write succeeds.
6. Re-arm: ignore further trigger edges until the button releases or the re-arm interval has passed (bounce, below).

The PC-side version of this loop, with runnable code, is in hardware trigger grab loop in Python: acquire and save each frame.

Illustrative logic, with the variables declared:

counter  = 1     # int, seeded from the folder at start-up
REARM_MS = 50    # int, minimum spacing in ms between accepted triggers

on frame_acquired(buffer, t_ms):        # your SDK's frame-ready event
    name = "image_" + pad_left(counter, 4, "0") + ".bmp"
    write_file(folder, name, buffer)    # worker thread, not the callback
    counter = counter + 1

The names here are illustrative: frame_acquired stands for whatever frame-ready event your SDK or job editor exposes, and pad_left fills with zeros so image_0009 sorts before image_0010.

Build the filename so nothing overwrites

Zero-padding is not cosmetic: without it a file browser sorts image_10 before image_2 and the newest image hides mid-list. The padding width also sets the rollover point. Four digits count from image_0001 to image_9999; at one press every 5 s that is 9,999 × 5 s = 49,995 s, about 13.9 hours — fine for one shift per day. A line running two shifts or more wants five digits, 99,999 × 5 s ≈ 138.9 h ≈ 5.8 days, or a date in the name.

The counter must survive restarts, because a job that wakes up at image_0001 overwrites the first images from every earlier run. That is why the routine seeds it: scan the folder, parse every numeric suffix, take the highest plus one. Two cameras sharing one folder need more still — counters do not coordinate across processes. Prefix the camera ID (station1_image_0007.bmp) or give each camera its own folder.

Size the disk before the first shift

Worked example: a 6 MP mono camera at 3072 × 2048 px, one press every 5 s across an 8-hour shift.

• Bytes per image: 3072 × 2048 = 6,291,456 px; at 1 byte per pixel that is 6,291,456 bytes ≈ 6.3 MB for an uncompressed BMP.
• Presses per shift: 8 h × 3,600 s/h = 28,800 s; 28,800 ÷ 5 = 5,760 images.
• Per shift: 5,760 × 6.3 MB ≈ 36 GB.
• Keep five shifts and the archive wants about 181 GB, so hold 256 GB free for margin. 8-bit color triples the bytes per image (3 × 6,291,456 = 18,874,368 ≈ 18.9 MB) and takes the week to roughly 543 GB.

If the archive lives on its own box in the cell rather than in the camera, a fanless industrial mini PC beside the camera keeps the writes local and off the office network.

PC-side capture runs on a vision controller: it takes the camera stream on its LAN ports and writes to local drives. The MV-VC2140-128G40-1T pairs its SSD with a 1 TB HDD, which is where that archive lives.

Verify it worked

Four checks, in order:

• Ten presses: exactly ten files, image_0001 through image_0010, none missing, none doubled.
• Size check: each file lands near the arithmetic above, about 6.3 MB in the worked example; a file near zero bytes means the save ran before the buffer was complete.
• Restart test: close the capture software, reopen it, press once. The new file must take the next number; if it starts again at image_0001, the seed scan is missing.
• Spacing test: log a timestamp with every save and press briskly twenty times. Every gap must clear the re-arm interval; two saves closer than that mean bounce is getting through.

Common mistakes

• A fixed filename in the save call: every press overwrites the last evidence. The counter exists to prevent exactly this.
• Saving from the job loop while the camera still free-runs: the folder fills with untriggered frames. Fix the acquisition mode first; the save code stays the same afterwards.
• Contact bounce: a mechanical button keeps bouncing for roughly 1-10 ms, and a rising-edge trigger counts every bounce as a new press. Accept one frame and ignore edges until release, or re-arm on an interval — the 50 ms in the example or longer; some cameras also expose a trigger filter or delay you can set above the bounce window.
• JPEG for defect records: lossy compression moves the edges and gray levels you may need to measure later. Save BMP or PNG, never JPEG.
• One counter for two cameras: both start at 1 and one process overwrites the other. Split the folders or prefix the camera ID.

Which hardware fits this job

Three builds cover most push-button stations.

On-device, nothing but a button: a vision sensor runs the job and logs the images on the camera itself. The MV-SCB007EC-12S-WBN pairs a 12 mm lens with the sensor, so there is no lens choice to make at all.

On-device with more resolution and lens choice: a smart camera takes the trigger on its power and I/O connector and keeps the inspection local. A hand-placed part sits still while the operator presses, so a rolling shutter costs nothing there; when parts move under the lens, filter the camera finder to global shutter. The MV-SC5060XM-08M-WBN gives 6 MP over GigE with an 8 mm M12 lens already mounted.

For the button side, the LS-CBL-0300 runs 7 m from an M8 8-pin male connector to open 8-core leads, which is exactly what the trigger wiring above needs.

Before you commit a smart camera to a job that must run your own logic, read smart camera software compatibility: what to check — the job language and the SDK matter more than the sensor does.

To wire the whole chain, camera to trigger to storage, in one pass:

The decision for each case

• One station, images kept for review: a vision sensor or smart camera with on-device logging, a four-digit counter, lossless files and a re-arm above the bounce. Nothing else is needed.
• Files must land on a shared PC folder: keep the camera in hardware trigger, run the frame event on a vision controller, seed the counter from the folder at every start-up, and hold the 256 GB from the storage math for a week of 6.3 MB images.
• Several cameras on one line: five-digit counters, one folder per camera where you can, camera ID and date in the name where you cannot.
• Presses faster than about one per second: write to a local SSD, use PNG only when disk space forces it, and let the archive math, not the trigger, set the limit.

To spec the chain end to end — camera, trigger cable, capture PC — build a system, or send us the layout through the contact page for a quoted parts list.