Triggering a GigE camera

[josborne]

Newbie question for you all.  Hope this makes sense:

At the moment, we are using a Dalsa area scan camera and a NI PCI-1424 frame-grabber with a parallel digital interface.  We use LabVIEW and IMAQ software.  Our software creates an IMAQ session that sits and waits for a single external trigger on the PCI-1424 board.  When it receives the trigger, we acquire a series of frames at a given frame rate.

Now we want to upgrade the whole system and are considering a GigE camera from Basler (Pioneer piA640-210gm).   If decide to do this, how would we configure the triggering? 

I noticed that NI's GigE board (PCIe-8231) does not have any trigger inputs.  So I guess the only way to trigger the acquisition is to use the camera's trigger input?  But that doesn't even seem possible.  The user manual on the camera indicates that external triggering is used when you have a pulse train that triggers every frame.  We want the camera to wait for just one rising-edge which then triggers a pre-determined acquisition that is setup in the software.  Any ideas how to do that with GigE?

Also, we use NI-IMAQ software right now.  If we upgrade to GigE, then we are going to have to totally re-write our software to use NI-IMAQdx, right?

- John

[BlueCheese]

Hi John,

With Firewire and GigE cameras the triggering is generally* done on the camera rather than the interface into the PC. The reasoning is that the interfaces into the PC do not have low-latency, deterministic methods to trigger the camera except via a separate external trigger wire linking the PC and camera. (*With Firewire since you are bound to the distance limits of the bus, it is generally easy to make this connection than GigE). NI does sell products like the 8255R (a firewire interface combined with reprogrammable I/O suitable for use with triggering cameras via an external cable, but there is no device that combines this functionality with GigE ports (but no reason why you can't combine with a separate GigE network card). However, as I'll desribe below, GigE Vision has its own tricks that reduce/eliminate the need for this...

With the triggering moved to the camera, it is up to the camera vendor to decide the complexity the triggering methods they implement. On GigE Vision cameras, because they use GenICam XML files to allow the cameras to self-describe their features, any capabilities the camera manufacturer can dream up will be exposed through the driver. We are starting to see GigE cameras on the market with very complex triggering capabilities (including built-in pulse-generation capabilities, complex input and output interactions, etc) that can rival features on many framegrabbers. You can configure all of these features within MAX or your application just like you can control any other feature of the camera. Note that while there is flexibility to implement any feature desired, there is a "Standard Features Naming Convention" that, among other things, includes complex triggering definitions. This list aims to ensure that cameras that implement the same features (such as common triggering modes) use the same names and behavior for their features.

As to whether the Basler Pioneer will support what you want, I am unsure. I checked the triggering capability here: http://www.baslerweb.com/downloads/17785/pioneer_manual.pdf. According to their docs, they support an "AcquisitionStart" trigger, meaning you should be able to trigger the start of a single-frame, multi-frame, or continuous acquisition when that trigger comes in (and the source can be varied, including external I/O pins). However, I tried this on a Basler Scout that we have and only a single frame was generated in this mode when triggered via a software trigger. Its possible I have an earlier firmware that is behaving incorrectly, but in theory the Basler camera should be able to do what you want if they named it correctly. I would confirm the expected behavior with Basler to be certain. As I mentioned, there should be plenty of other cameras on the market that do support this triggering mode if the Basler does not.

With regards to re-writing your software for IMAQdx, its true that you would have to make the translation from IMAQ code. However, the API's are very similar for most things and code porting shouldn't be too bad.

Please let me know if you have any more questions regarding this,

Eric G

[josborne]

Thanks for an excellent, in-depth reply!

[jhc2]

Eric said that he'd been able to capture a single frame with ImaqDx from a Basler Scout.

I tried this on a Basler Scout that we have and only a single frame was generated in this mode when triggered via a software trigger.

Eric G

That's exactly what I'm trying to do with a PCIe-8231 and a Scout, but I could use one more hint. I can acquire an image in NI's MAX utility by configuring the Acquisition attributes and then clicking the Execute button for the 'Generate Software Trigger' attribute.

But I'm not sure how to actually generate the software trigger using ImaqDx. Is it simply a matter of (a) configuring the trigger attributes and (b) calling StartAcquisition? In other words, I don't see an ImaqDx function named "GenerateSoftwareTrigger".

What is MAX doing when the Execute button is clicked?

Thanks in advance -

James Crain

[BlueCheese]

Hi James,

Keep in mind that under GigE Vision, all the attributes you see under the Camera Attributes tree in MAX are described and controlled by the camera itself. In this case it has an attribute that is called "TriggerSoftware" (it may have a slightly different display name, but this is the name it is gets referred to by code). This happens to be the standardized name for a software-based trigger that most cameras follow in order to give the end-user some consistency between different camera vendors. All attributes have a type associated with them (like the common integers, doubles, enumerations, etc) and "TriggerSoftware" is of the type called a "command". A command attribute can be thought of as a write-only, self-clearing boolean. Under our IMAQdx API we allow you to set it as such (the same as a boolean), and writing to it will cause the command to be executed on the camera. The execution of this command is independent of the acquisition, so you'll have to start the acquisition prior to calling this. However, the camera will (if configured for the software trigger) wait to send images until getting that trigger command.

Please let me know if you have any further questions.

-Eric

[jhc2]

Eric

Thanks for the quick reply. As you noticed, it wasn't clear that 'TriggerSoftware' was a camera attribute rather than some API function. I was somewhat misled on this point by scanning Basler's Pylon doc for clues and by the button in MAX (rather than a 1/0 or T/F dropdown).

But I can capture images after triggering from IMAQdx now, which is exactly what I was hoping to do. I appreciate the suggestion.

James Crain

[benbeg]

Hi Eric,

Your post dealing with the triggering of a GigE camera using software Trigger in Labview is now 4 years old, but I am currently experiencing the same problem in my application. I am creating a Labview program to acquire images from a Basler (acA2500-14gm) camera, and can't really understand how to generate an equivalent to the MAX-command "Execute" within Labview. Your post helps me to understand how it works, but it is still not clear how to implement the "command type" required by the SoftwareTrigger attribute...

I have attached an image showing what I have implemented so far. By setting the "TriggerMode" attribute to Off, the acquisition starts as soon as the vi is executed, which is fine. However, by setting the "TriggerMode" attribute to "On", there are no error messages but the acquisition simply doesn't start by clicking the execute button and a timeout error occurs after 5 seconds... Could you give me some precisions about how to implement an Execute button?

Thank you very much in advance for your help!

Regards,

Ben

[Tim_O1]

Hi Ben,

If you can run your code without errors and then you get a time out usually that means the camera is not receiving the trigger. Please look at the documents below, they outline how to set up a task and shows an example for triggering with a GigE camera. If you are just trying to have your camera acquire after a user presses execute (and not worried about timing) you could use the Grab.vi example and put is within a Case Structure inside a While Loop and have you execute button controlling the Case Structure.

Triggered Acquisition GigE IMAQdx

https://decibel.ni.com/content/docs/DOC-7501

Acquiring from GigE Vision Cameras with Vision Acquisition Software - Part II
http://zone.ni.com/devzone/cda/tut/p/id/5750

Creating a Task in NI-DAQmx and Using it in LabVIEW
http://zone.ni.com/devzone/cda/tut/p/id/5374#toc0

Tim O

[benbeg]

Hi Tim,

Thank you for your answer and the suggestions. Unfortunately I am quite a novice in Labview and I couldn't find a satisfying solution so far, thus I still have further issues concerining this subject.

As far as I understood you, both examples using a DAQ (https://decibel.ni.com/content/docs/DOC-7501 and that with with creating a task) require an external connection with the camera, which I like to avoid. Please correct me if I'm wrong!

Your suggestion to simply use the Grab.vi is good, but the problem is that I want the camera to acquire a certain amount of frames (let's say, 10) after having clicked on "start". In order to be able to control the number of frames to be acquired with my camera (BASLER ac2500-14gm), the "acquisition start trigger" has to be set "On", which in turn requires some trigger signal. If the "acquisition start trigger" is set to "Off", your suggestion to simply use the Grab.vi would work but the camera will acquire frames continuously... How could I implement a simple software trigger like a start button?

Thank you,

Regards

Ben

[BlueCheese]

Hi Ben,

On the Ace you are using you could use the Acquisition Start (instead of Frame Start) trigger and set it to be triggered by a Software Trigger. Then you could set the Acquisition Frame Count to 10 frames. It would also make sense to use the Sequence VI rather than a continuous Grab since the camera will stop sending images after those 10 frames and the continuous Grab would time out. Then after you start the camera you could then send a Software Trigger whenever you want to start it. Of course this mechanism is not the best if you want to synchronize with other hardware like DAQ, in which case you'd likely want to use a trigger signal between them to have them be absolutely synchronized.

Eric