Imaginghub Forum - basler pypylon WaitForFrameTriggerReady() returns in variable time

We are noticing that, the camera might have unstable frame rate. I hope to check if there is any way to mitigate this.

We are using the python API. We have a busy loop that's like this (pseudo code):

camera.AcquisitionStatusSelector = "FrameTriggerWait"
camera.TriggerSelector.SetValue("FrameStart")
camera.TriggerMode.SetValue("On")
camera.TriggerSource.SetValue("Line1")
camera.TriggerActivation.SetValue('RisingEdge')
camera.StartGrabbing(pylon.GrabStrategy_OneByOne)

while True:
    cam.hard_trigger()  # hardware trigger
    cam.WaitForFrameTriggerReady()
    cam.retrieve()

What we are seeing, is that WaitForFrameTriggerReady() call duration fluctuates between 12 - 30ms. Initially we thought this is a python issue. However, we've isolated this down to a minimal script that calls the basler python api. And the issue persists.

Is there any way to make the frame rate more stable?

Detailed setup:

camera model: acA2440-75uc
Camera has been used for roughly 4.5 Million captures
I'm using exposure time 300 microseconds.
I provide the hardware trigger to the cameras. The frequency is between 40 to 70Hz. I capture 20 - 30 images at a time at that frequency. The setup is like this: a. In computer software (python), I monitor a variable at 500 Hz. This variable is a rotating axis's encoder reading. I want to capture at every 12 degrees. b. As soon as the variable changes, I call WaitForFrameTriggerReady(), then hard trigger. The variable change frequency is between 40 to 70Hz. However, I always respect the WaitForFrameTriggerReady() until I hard trigger. In other words, there is a chance I miss the next variable change, because WaitForFrameTriggerReady() takes too long to respond.
I capture in frame mode. I use pylon.GrabStrategy_OneByOne. I don't think I want burst mode, because I want to capture at the precise moment when my variable changes (I don't want to miss a variable change because camera is not ready).

Answers

Hi, by using the same software loop to create a "hardtrigger" you could just use Trigger Source "Software" and GenerateSoftwareTrigger.Execute(), because in this way it is kind of a soft trigger anyways :-) But using the genicam softtrigger still might be slower and have more jitter than a real hard trigger.

But for a real hard trigger you need an independent kind of clock/trigger source (hardware or high priority software thread) to trigger the camera and then your existing loop won't execute the trigger but only retrieve and process the images from the camera. If you are using this kind of real hardtrigger you only have to make sure you don't exceed the value of ResultingFrameRate register, because this would cause an "overtriggered" condition and trigger signals will be ignored then, if the period was to short.

cheers

Hello, I would also like to offer that if you are using a microcontroller, etc. for your hardware trigger, then you can monitor the hardware output signal that is the equivalent of WaitForFrameTriggerReady, FrameTriggerWait. I have a project on here for arduino which does exaclty that (https://imaginghub.com/projects/115-arduino-shield-for-basler-ace-camera) e.g.

bool useFrameTriggerWait                              = false;                      // Shall we use FrameTriggerWait?

CameraFrameTriggerWaitSource myFrameTriggerWaitSource = Output_Line2; // If yes, where is FrameTriggerWait?

Add Answer

basler pypylon WaitForFrameTriggerReady() returns in variable time

basler pypylon WaitForFrameTriggerReady() returns in variable time

Answers

Need support?