GigE Vision camera events: get exposure end signals into your code

You switched on an exposure-end event inside a GigE Vision camera, opened the Register Events function in your acquisition software, and found three entries: Frame done, Attribute Updated and Plug and Play. The camera's documentation promises more — events sent when exposure ends, when a trigger fires, when an overtrigger occurs. Most host libraries register only the common subset and never ask about the rest. The camera still generates every event it documents, and its GenICam XML republishes each one as a timestamp attribute you can read like any other register. This guide enables the event, latches that timestamp from your code, sets a poll rate that cannot miss an event, and proves the signal end to end.

Why the event list stops at three entries

The host library, not the camera, decides which events get delivered. Libraries implement a fixed list — Frame done, Attribute Updated, Plug and Play — and register for nothing else, even when the camera advertises richer events in its XML alongside its ordinary attributes. The list is static in the host, so no camera-side setting will extend it. Plug and Play is the giveaway: it reports hot-plug on transports that support it and is inert elsewhere, which tells you the list was written once for all cameras rather than built from what each camera offers.

What the standard gives you is control-channel interoperability: reads, writes and streaming work across vendors, while event delivery beyond the common set depends on what the host implemented. The details are in what GigE Vision compatibility actually guarantees. Two paths reach the extra events — make the host carry the event message, or read what the event refreshes. The second needs nothing from the host but attribute reads.

What the camera sends when the event fires

GenICam cameras keep an event-control section in their XML. You pick the event — exposure end appears as ExposureEnd, and some XMLs spell the enable ExposureEndEvent — and switch its notification on. Two things then happen on every occurrence:

• The camera pushes a short event message carrying the signal-change point over the GigE Vision link. It reaches your code only if the host registered for that event, which is the support your three-entry list does not have.
• The camera refreshes GenICam attributes that report the timestamp of the last triggered event. Any host that can read an attribute can see the event, and with Attribute Updated you can turn the refresh into a callback.

The second path is the portable one: enable the event on the camera, then register Attribute Updated on the timestamp attribute, or poll it on a timer.

What you need

• A GigE Vision camera whose XML exposes the event enable and the event timestamps — nearly every industrial camera does. If the names do not appear where you expect, finding a GenICam feature that is not exported covers where they hide.
• A host that reads and writes camera attributes over the control channel, ideally one that can register Attribute Updated on a chosen attribute.
• A network path you control. Event reads are small, but they belong on the camera link, not the plant LAN. A dual-port PoE NIC such as the MV-GE2002P puts each camera on its own port and powers it over the same link.
• For a multi-camera cell, a 4-port GigE card such as the MV-GE1104 keeps every control channel isolated; browse GigE frame grabbers for the port count your cell needs.
• A locking data cable, so a bumped connector cannot drop the control channel mid-run — a 15 m RJ45 camera cable with a locking stud, such as the LS-CBL-0117, holds through vibration.

The parts that carry the control channel:

Any camera in the GigE area scan cameras range carries these event features; the camera finder filters by interface, resolution and shutter so you can shortlist by the imaging job first.

Enable the event and latch the timestamp

1. Open the camera's GenICam feature list — the attribute browser in your host, or the XML itself. Find the event enable: ExposureEnd, ExposureEndEvent, or an event selector paired with a notification switch.
2. Write the enable while the camera is idle. Some cameras refuse feature writes during acquisition; if you must change it live, follow the safe way to apply camera settings while streaming.
3. Locate the timestamp attribute — the one reporting the timestamp of the last triggered event. Note the unit the XML prints, nanoseconds or device ticks, and keep one unit through all your math.
4. Register Attribute Updated on that attribute. In the handler, compare the value with the previous one: a change means the attribute was written again, which for these registers is one event.
5. If your host cannot watch attributes, poll: read the attribute on a timer at half the event spacing — the arithmetic is below. If the timestamp is not exported to your attribute list, read it as a raw register; runtime register access on a GigE camera shows the pattern.
6. Count events by detecting value changes, storing the last value you saw. Equal consecutive values mean no event, not a stalled link.
7. Sanity-check with deltas: at a fixed frame rate the timestamp steps by one frame period per event. A step of two periods means your cadence missed one.
8. Prove it end to end: force one trigger and confirm the timestamp changes exactly once, then run at rate and watch for the double-period tell-tale.

Worked example: latching ExposureEnd at 9 fps

The case: one LS-CMR-0053, a 12 MP GigE camera with a rolling shutter at 9 fps, photographs parts on a conveyor. The control code must see every exposure end, count no frame twice, and raise a fault within 200 ms if events stop.

Inputs:

• Frame rate: 9 fps, from the camera configuration.
• Event gap = frame period = 1000 / 9 = 111 ms.
• Fault requirement: silence detected within 200 ms.

Rule: poll no slower than half the shortest event gap. Then at most one event can land between two reads, so every changed value is exactly one event and none can hide.

Arithmetic:

• Frame period: 1000 ms ÷ 9 fps = 111 ms.
• Poll interval: 111 ms ÷ 2 = 55.5 ms → set a 50 ms timer.
• Missed-event tell-tale: a timestamp delta of 2 × 111 ms = 222 ms means one event slipped between polls — halve the interval.
• Fault timeout: 3 × 50 ms = 150 ms of unchanged timestamp while acquiring → alarm, and 150 ms sits inside the 200 ms requirement.

Decision: at 9 fps, run a 50 ms poll or an Attribute Updated registration on the timestamp attribute; both catch every event, and the 150 ms silence alarm covers a stalled link. A faster camera tightens everything: 1000 ÷ 30 = 33 ms per frame and a 16 ms poll. At that cadence, about 60 control reads a second, take the callback instead of polling. The LS-CMR-0166 runs its 12 MP at 30 fps over USB3, and the same attribute mechanism applies.

Where the trick goes wrong

Auto-exposure noise. Gain and exposure attributes also change during a run, so an Attribute Updated registration must filter by attribute name or you will count exposure adjustments as events. Auto-exposure disturbs measurements in other ways too — contour position jitter under automatic exposure covers the imaging side.

A callback that blocks. On many hosts your handler runs in the acquisition thread. If it does file I/O or logging, frames pile up behind it and you meet buffer overflows; diagnosing GigE camera buffer overflow errors walks the fixes. Keep the handler to a compare-and-store.

Arrival time is not event time. The timestamp is taken inside the camera; when your code happens to read it says nothing about delivery delay. Keep that distinction when you chase frame arrival jitter between camera and host.

Two writers on one camera. A second tool writing features fires Attribute Updated events of its own and can switch your enables off. One writer per camera, always.

Events nobody reads. Every enabled event refreshes attributes and pushes messages where the host listens. Enable only the ones your code latches.

Checks before you rely on the signal

• Two reads at rest return the same timestamp — a value that wanders while idle points to a second writer.
• One forced trigger changes the timestamp exactly once.
• Deltas at rate equal one frame period; a double period means you missed an event — halve the poll.
• The timestamp unit is confirmed from the XML before you compare anything with host clocks.
• Poll or callback survives a cable reseat; the locking connector is what makes that a non-event.
• The fault timer fires when you unplug the trigger line, not only when you unplug the network.

When you add the camera that has to carry this signal, the system configurator walks camera, NIC and cable in one pass. More on wiring cameras into control code sits under the systems topic, and the contact page reaches our applications team for a specific model's event list.