Use camera trigger lines as digital outputs when space is short

You are one terminal block short: the panel is full, the PLC has no spare output card, and the inspection needs three more digital signals — a part-present lamp, a mode bit for the light controller, a reset command. The frame grabber already inside the PC has four external trigger lines sitting idle between acquisitions. This guide shows you how to drive those lines as static TTL outputs from your software, how to wire them out with one I/O cable instead of a breakout block, and where the trick stops working — because a software-timed line carries about a millisecond of jitter and must never carry a strobe or a safety function.

Can trigger lines double as digital outputs?

Yes — a grabber of this class carries four external trigger lines, and each can be driven as a static output: software sets the line asserted for a TTL high near 5 V or unasserted for a low near 0 V.

The lines exist to gate acquisition, but between frames they are ordinary TTL buffers with a drive function behind them. The trigger-drive call takes two settings: which trigger line terminal to use, and the drive state — Asserted for TRUE and a logic high, Unasserted for FALSE and a logic low. The level latches until your next call, and nothing in the acquisition engine changes while you use it. These same four lines close the loop described in frame grabber image acquisition for Camera Link and CoaXPress, so anything you export this way shares the camera's ground domain unless you isolate it.

One physical detail decides your wiring: on many boards, external line 0 is the SMB connector on the front panel, and the remaining lines sit on the I/O header or an extension board. Count the lines you can physically reach before you promise the cell three outputs.

How do you get the lines out without a breakout block?

Buy one flying-lead I/O cable instead of a terminal block: a grabber with a DB9-style I/O connector takes a cable with open, numbered leads, and a 7 m run covers most cabinets. Ferrule or solder the leads straight into the consumer's terminals and label both ends; that is the whole installation.

The frame grabber I/O cable is built for exactly this move — a DB9F end on the grabber, open leads on the far side.

If your PC also holds a data-acquisition card that shares a routing bus with the grabber, a second route exists: pipe the grabber's lines across that bus and land them on the DAQ card's own terminal block. The states travel, and you save the grabber-side block — which is the entire point when space is short. The timing does not travel with them: every write now crosses the shared bus and a second card, so treat the latency numbers below as a floor, not a ceiling.

The levels are symmetric. The same 5 V logic that leaves a trigger line also clocks things in reverse — triggering a camera from a 5 V source follows these wiring rules when a PLC or DAQ output must start an exposure.

How do you set a line high or low in software?

One call per level change: your code selects the trigger line by number, requests the drive state — Asserted drives TRUE and the high level, Unasserted drives FALSE and the low level — and the line latches until the next call.

1. Reserve the lines you will not trigger with. If you hardware-trigger, keep one line as the input and take the rest as outputs.
2. Set direction once at start-up: configure the chosen lines as outputs (trigger drive) in the grabber driver, not on every call.
3. Write levels with the drive call: line number, state Asserted or Unasserted.
4. Measure before trusting: a multimeter from line to logic ground should read near 5 V asserted and near 0 V unasserted. If the sense is inverted, flip the polarity setting in software — never fix polarity in the wiring.
5. Wrap it: one function in your code, set_line(n, state), is the only place that touches the lines.
6. Log the first week: timestamp every write next to the inspection record, so jitter and ordering surprises show up as data instead of scrap.

On an older analog chain the order matters the same way it does in analog frame grabber integration with vision software: configure the board, claim the lines, then open acquisition.

How much jitter does a software-timed line have?

Budget 1 ms of uncertainty on the edge and design as if it were 10 ms: the write is software-timed on a general-purpose OS, and crossing a shared routing bus to a second card adds the same order again — far too coarse for strobe or encoder work.

Worked example, the operator lamp. The line inspects at 4.5 parts per second, so the loop period is 1 / 4.5 = 0.22 s = 220 ms. The result handler writes the line at the next loop pass: 110 ms of wait on average, 220 ms worst case. The write itself: 1 ms. The consumer — a controller input plus the 5 ms PLC program scan that reacts to it.

Typical: 110 + 1 + 5 = 116 ms. Worst: 220 + 1 + 5 = 226 ms.

Decision: an operator lamp that must light within 0.5 s passes with margin (226 ms < 500 ms). A reject diverter that must act within 150 ms fails (226 ms > 150 ms); that signal goes to a hardware-timed output on the PLC.

The strobe case is not even close. A 100 µs flash at 30 frames per second is 0.1 / 33.3 = 0.3% duty — see LED strobe duty cycle: matching lights and controllers — and its edge must land inside the exposure, not a millisecond after it. When the light fires and the frame stays black, the streams have crossed; strobe light on but camera image is black: fix the timing is the repair path before you touch wiring.

What is safe to switch with a spare trigger line?

Slow state signals only: part-present lamps, recipe or mode bits into a light controller, enable lines to a PLC, arm lines to a strobe controller — anything that tolerates 10 ms of uncertainty; never a solenoid, motor starter or 24 V load directly.

The pattern that works: the line drives an input, and the input's owner does the power switching. A digital light controller is the natural consumer — one asserted line selects or switches a channel, and the controller's outputs carry the current. The 4-channel digital LED light controller is exactly that kind of load: your spare lines send the commands, its channels do the work.

Filter light controllers by control type when you shop for the consumer end — you want a digital input per channel. And the same static-output logic applies when the spare outputs live on a robot instead of a grabber: trigger strobe lighting from robot IO digital outputs walks that version of the trick.

How much current can one line source or sink?

Treat a trigger line as a 5 mA logic signal: classic TTL outputs are rated near 16 mA sink and under 1 mA source, board buffers commonly run 4–8 mA, and opto-isolated inputs draw 2–10 mA — which is the load these lines were built to drive.

So the line drives an opto LED, a logic input or a small solid-state relay, and nothing else. An opto input also answers the ground question: with isolation you never tie the grabber's ground to the PLC's. Real 24 V current switches through a controller channel or an interposing relay with a flyback diode; an unprotected short across a digital output is its own failure class, and PLC digital output short-circuit protection covers the design side.

When is a trigger line the wrong tool?

When the edge itself is the timing: strobe pulses, encoder-locked lines, flashing inside an exposure, high-speed reject actions, and every safety function — the first four need hardware-timed outputs and the last needs rated safety hardware.

On new builds the I/O often moves onto the camera body: current industrial cameras expose user-settable output lines through their GenICam line settings, so the same asserted/unasserted idea runs from the camera with the same software-timing limit. Do I need a camera GPIO cable for image acquisition? answers the wiring side, and GigE camera ignores external trigger: check acquisition mode first is the companion trap when a line stops behaving. A rebuild that stays on Camera Link keeps the architecture — camera to grabber, I/O on the board — and the MV-GC1102IOL is a Camera Link frame grabber for that job.

What should you check before you give up the panel space?

Seven checks, fifteen minutes with a meter and your wiring drawings: run them before you delete the PLC output card from the bill of materials, because timing and current are where this trick quietly fails.

• Line budget: four lines, minus the hardware trigger input and the strobe output you already use. The remainder is your I/O count.
• Physical access: which connector carries each line — a front SMB for line 0 on many boards, the I/O header or a DB9 for the rest — and the cable that fits it, ordered with the camera wiring from cables.
• Load type: every consumer is an opto or logic input; anything bigger switches through a controller channel.
• Timing budget: write down the three numbers — loop period, 1 ms write, consumer scan — and add them against the deadline the machine gives you.
• Ownership: one function writes each line; two writers is last-write-wins and a day of debugging.
• Polarity: measured once, corrected in software, never in the wiring.
• Fallback: note the lead time of the output card you are deleting, while changing the order still costs nothing.

Next step: open the system configurator at the accessories step, where grabbers and I/O cables sit together. If the timing arithmetic lands within a factor of two of your deadline, bring the three numbers to the contact page and we will check the budget with you.