Triggering

Your project can acquire images (grab) either upon reception of a trigger or continuously. When your flowchart reaches a Camera step, the acquired image becomes available to your flowchart.

Continuous grab mode is convenient at runtime for focusing your camera and setting up lighting when testing or demonstrating a project. Typically, however, you will need to trigger your camera(s) explicitly. In this case, the Camera step receives the image only after receiving a trigger and your project operates in triggered grab mode.

There are several ways to configure the trigger for image acquisition when in triggered grab mode. Triggered grab mode has a positive impact on grab timing. See the Grab timing section later in this chapter.

Triggering from a hardware signal. The grab starts upon a specified transition of an auxiliary input signal (line).
Triggering from a software trigger. The grab starts upon a Trigger step or when clicking a button in the operator view that performs a Send software trigger action. With a software trigger, you can either acquire a new image or reuse the current image.
Triggering from a periodic trigger. The grab starts after a specified amount of time, determined using an internal clock. Periodic triggers are generally used for testing or demonstration purposes.
Triggering from a PLC with Quick Comm. The grab starts when the PLC changes a specific Quick Comm data field.
Triggering from a PLC without Quick Comm. The grab starts when your project detects a PLC acquisition start request using polling (for example, using a ModbusReader step) and triggers the acquisition.

Use the PhysicalCameraN page of the Platform Configuration dialog to configure the trigger settings.

Common trigger settings

The following is a list of common trigger settings for triggered acquisition. To change these trigger settings for a camera, use the PhysicalCameraN page of the Platform Configuration dialog. With GigE/USB3 Vision cameras, it is assumed that these standard features will be available.

Camera's trigger input	Description
Trigger	Sets whether to enable or disable the trigger. If enabled, acquisition from the camera will be in triggered mode; otherwise, it will be in continuous mode.
Source	Sets the source of the trigger.
Activation	Sets the signal transition upon which to generate a grab trigger. Typical transitions upon which to trigger include the rising or falling edge of a signal, or the high level or low level of a signal. In the latter case, acquisition will start when the trigger signal transitions to the specified level and will occur again if the trigger signal is at the specified level when the readout period is over.
Period	Sets how frequently the trigger signal should occur, when the trigger source is set to PeriodicTrigger, in msec.
Delay	Sets the delay between the trigger and the grab, in msec. See the Trigger speed subsection of the Grab timing section later in this chapter.

Triggering from a hardware signal

Triggering image acquisition from a hardware signal is the most common form of trigger used in high-speed vision applications. When in hardware triggered grab mode, the grab initiates each time the signal from the specified auxiliary input signal (line) arrives.

If configuring a trigger for a GigE/USB3 Vision camera from a hardware signal, the camera must support the TriggerSelector feature. To determine whether your camera has this feature, use the Feature Browser. This feature should be listed under the heading of Acquisition Control.

To enable hardware triggered grab mode, perform the following:

On the PhysicalCameraN page of the Platform Configuration dialog, enable the Trigger input.
Set the TriggerSource input to an auxiliary input signal (line).
Optionally, set the Activation input to determine the signal transition upon which to trigger.

To ensure your flowchart can perform other events while the Camera step waits for a trigger to arrive, refer to the Handling other requests while waiting for a trigger subsection of this section.

Note that, when in emulation mode, we recommend not to configure a hardware trigger.

Triggering from a software trigger

Triggering image acquisition from a software trigger is typically the default way to acquire an image in emulation mode and/or when not in a high speed application. There are 3 types of software triggers: a trigger button element in the operator view, a Trigger step, or a PLC trigger with Quick Comm (PROFINET or EtherNet/IP).

Note that you can also use a software trigger with image sets. For more information, see the Procedure for configuring image sets section in Chapter 29: Acquisition using image sets.

To configure your project at runtime (for example, change its trigger source), bind input elements directly to platform configuration settings, use a CameraSettings step in the main or a subflowchart, or link a Button element in the operator view to the Change Camera Settings action.

Procedure for using the Trigger step to initiate a grab

The Trigger step can initiate a grab when your camera is in software trigger grab mode. To use the Trigger step to initiate the grab, perform the following:

On the PhysicalCameraN page of the Platform Configuration dialog, set the camera to software triggered mode by enabling the Trigger input and setting its Trigger Source input to Software.

Note that instead of using a Trigger step, to initiate the grab from the operator view, you can add a button element that performs a SoftwareTrigger action and specify the camera to which to send the trigger upon a button click. For more information on configuring the button element in the operator view, see the Buttons section in Chapter 50: Customizing the operator view.
Add the Trigger step at a location in the flowchart at which you want to grab the next image.
On the Configuration pane of the Trigger step, select either the Send software trigger (next image) option to trigger the acquisition of the next image, or select the Reuse current image option to trigger the reuse of the same image. The latter allows you to modify annotations or elements on the operator view and see the results on the previously acquired image.

Using a PLC trigger with Quick Comm (EtherNet/IP or PROFINET)

Triggering image acquisition using a PLC trigger with Quick Comm allows up to 8 cameras to receive software triggers from external devices using the PROFINET or EtherNet/IP protocol. To use a PLC trigger with Quick Comm:

Setup your runtime platform and project to communicate with a PLC using the PROFINET or EtherNet/IP protocol with Quick Comm. For more information, see the Set Quick Comm to trigger acquisition automatically subsection of the Procedure for communicating with controllers section in Chapter 41: Quick Comm protocol and PROFINET and EtherNet/IP steps.
On the EthernetIP or Profinet page of the Platform Configuration dialog, enable the PLCCameraNTrigger data field by setting its Trigger event to trigger PhysicalCameraN. This associates the physical camera with the PLC trigger.
On the PhysicalCameraN page of the Platform Configuration dialog, set the Camera step to software triggered mode by enabling the Trigger input and setting its Trigger Source input to Software.

Using a PLC trigger without Quick Comm

Triggering image acquisition from a PLC trigger (triggering from the network) without Quick Comm does not use a hardware trigger, a software trigger, or an image queue. Instead, when your project detects a PLC acquisition start request using polling (for example, using a ModbusReader step), it should trigger the acquisition. So, the Trigger input and the Image Queue Size input, both found on your physical camera's page of the Platform Configuration dialog, must be disabled.

To detect a PLC trigger without Quick Comm, you poll for a signal from your PLC. Since it is not efficient to poll the communication step faster than the scan time of the controller, you should place a Halt step and set the Wait input to the required amount of time.

In the following illustration, the AnyReader step could be an EthernetIPReader step, ProfinetReader step, or ModbusReader step.

This frees the CPU from busy-waiting for a signal that won't arrive. For developers familiar with Visual Basic, this is similar to using a DoEvents statement. The Camera step should immediately follow the signal loop break. This ensures the smallest time between the signal being received, and grabbing the image.

Triggering from a periodic trigger

Triggering image acquisition from a periodic trigger has limited production purposes, but is often used when designing and testing a project that will eventually use another trigger mode (such as when testing in emulation mode but intending to deploy on a runtime platform with cameras). Periodic trigger mode sets up a trigger at a specified fixed interval.

Your camera is in periodic trigger mode when the Trigger input is enabled and the trigger's Source input is set to Periodic on the PhysicalCameraN page of the Platform Configuration dialog.

Handling other requests while waiting for a trigger

When in triggered grab mode, the Camera step takes an image from the image queue. If the queue is empty, the flowchart will wait at the Camera step until a trigger is received and an image is grabbed. If the trigger takes a long time to arrive, you can process other requests while waiting, by creating subflowcharts for the other processes and initiating them from an operator view event. While the Camera step is waiting for a trigger, the project can still handle events arising from operator view interactions or Quick Comm PLC events, using a subflowchart.

In the above flowchart, if an event from the operator view occurs between the Camera and inspection steps, the inspection process is performed before the event is handled. If, however, the event occurs while the camera is waiting for the trigger, the request is performed immediately. Once the event-triggered subflowchart is finished, control returns to the waiting Camera step.

Although less efficient, you can automatically have the Camera step timeout, perform other processing, and then return back to wait for the trigger. To do so, set the Timeout input (in msec) on the PhysicalCameraN page of the Platform Configuration dialog. If not set, the timeout value is assumed to be infinite (that is, the Camera step will never timeout). The timeout value must be at least twice the Exposure time value. You can then create a loop in your flowchart based on a timeout expression in a Condition step.

Note that if the Camera step times out and it does not grab an image, all subsequent steps that use Camera.Image or Camera.CorrectedImage cannot run. Also, in the operator view, any data in the same publishing group as a display linked to Camera.Image or Camera.CorrectedImage will not be published. To prevent this, precede the steps that rely on the Camera step with a Condition step so you do not proceed to these steps if the camera has timed out. .