Trigger Delay is resetting by itself

[sevincom]

Hello,

I am using a Point Grey Grasshopper USB3 camera, GS3 51S5M-C, with buffering and triggering in VBAI 2014. I set the camera attributes and even save this attributes to a user set but when I turn off and on the camera the trigger delay attribute is changing to 999.98 ms by itself. The other attributes are remaining same as they should be but trigger delay is not.

The computer has three USB3 cameras connected on it. I do not know if it is relevant but sometimes I am getting an error with image size. One of the cameras get the image size of the other camera. If I try to snap or grab frames, it gives an error.

Does this Grasshopper camera's user sets saves the trigger delay value? Or is there another problem do you think?

I configure the camera with Wait for next image mode.

[Brad]

The inspection only saves "persistable" camera settings. These are defined by the camera. Anything not saved you can force to be what you want by using a Read/Write Camera Attribute step. The camera user sets may or may not save all the attributes you care about, so use the Read/Write Camera Attribute step if the camera doesn't save the settings you want.

As for the settings switching between cameras of the same model, this is fixed in VBAI 2015 I believe.

Hope this helps,

Brad

[sevincom]

Hello Brad,

Is not it necessary to acquire image from the camera before writing an attribute to it? Can I write trigger delay parameter to a device in the first start of the program, before acquiring an image?

And these cameras are not the same model. The other two are Chameleon 3 and Basler.

[sevincom]

By the way I just see that I wrote something wrong. I am using Continous Get Every image mode with buffer number 6.

[udka]

Attributes that are set programmatically with IMAQ Set Camera Attribute VI or an IMAQ Property Node are only set temporarily. Once the session to the camera is closed, the attributes that were changed will revert back to the original values that are specified in the camera's camera file.

If you would like to make permanent attribute changes, there are two options:

• Use Measurement & Automation Explorer (MAX) to manually alter the attribute values. When a camera attribute is changed and saved in MAX, the camera file is updated accordingly so that the changes become permanent until they are modified again. This option is the preferred method, but it does not allow for permanent attribute modification from LabVIEW.
• When you connect your camera to your computer for the first time, its configuration file will be extracted from the camera and saved in <Shared Documents>\National Instruments\NI-IMAQdx\Data. The file name should include the make, model and serial number of your camera, so you can identify the file should you have multiple cameras. Also, the file will have the file extension .icd. You can open this file and edit the attributes in a text editor such as Microsoft Notepad. Once you have saved the file with the desired attribute values, you can then use the same camera file.

-If  above methods fails, you can programatically change the required parameters after opening the camera session and configure it and then start acquiring.

Is not it necessary to acquire image from the camera before writing an attribute to it?

---

-Ideally you write the attributes to the camera before acquiring image.

---

And these cameras are not the same model. The other two are Chameleon 3 and Basler.

---

-So, all cameras are not reflecting parameters or any one?

Ref these links for more : How Do I Programmatically Load or Save a Configuration File with IMAQdx?

Setting My Camera Attributes Programmatically Does Not Permanently Change the Attributes and Changing Camera Configuration Programmatically

[Brad]

You can have the Read/Write Attribute step before any acquisition is called. Some cameras may take an image or two beforew an attribute change is applied to the image when the attribute is set without stopping the acquisition. You can choose to stop or even unconfigure the acquisition before setting the attribute in the Read/Write step if you find this to be a problem. Let us know how this works for you.

Udka's comments about MAX won't apply since it sounds like the camera does not persist the attribute you're interested in.

Thanks,

Brad

[sevincom]

Actually, I can not stop or unconfigure the acquisition because I am using buffering and getting the images all the time. If I unconfigure acquisition, I will lost previous images.

And when I use don't stop acquisition mode, after power cycling the camera, the read/write step gives an error. There are two errors I have encountered until now.

First one is with trigger delay maximum limit. After power cycling the camera, the minimum and maximum delay limits become zero. And read/write step gives an error about limit.

The second error is with the image size of the camera. It gets the image size of the other Basler camera (does not matter if the two cameras are connected to the same host adapter or not.. These problems are solved with using MAX and power cycling the camera again etc. and there is no standard procedure that I can figured out until now. But I can not use this method, since the system should be programmed previously in VBAI or MAX to prevent attribute changes.

[Brad]

So just to be clear...

1. You want to be able to handle the case where the camera is unplugged during the inspection.

 - I would recommend upgrading to VBAI 2015 f1 since we have fixed the camera associating with the wrong configuration when unplug/replug during inspection. In VBAI 2015 a step always stays associated with it's original camera file name to avoid this problem.

2. You can't change the trigger delay while acquiring without stopping the acquisition.

 - I would recommend setting the trigger delay (or any other attributes that aren't persistable) in the Setup state so it is called once and use the flag in the Read/Write Attribute step to stop the acquisition since it sounds like this is required by the camera to set that attribute.

 - If the camera gets unplugged during the inspection, use the state diagram to transistion to a new state that will try to set the trigger delay. If it fails, skip any processing you would do with that camera and go to the a different state that processes images from another camera. Here's a sample state diagram that illustrates what I would recommend for two cameras:

When the Acquisition Fails, a variable is set to indicate acquisition problems. This variable is checked in the Check Cam state and if the camera was disconnected, it should try to reset the trigger delay and if that works, then continue to acquie image, othersie, skip the rest and go to the next camera check.

Hope that helps,

Brad

[sevincom]

Brad, thank you for your detailed explanation.

In our setup, cameras are never disconnected while running an inspection. I can configure the camera attributes manually today. But when we restart the computer at the end of the day, attributes will be changed, and we can not configure these attributes everyday. Even if I accept changing it everytime I restart the computer, the camera does not give permission to me for changing trigger delay value.

I would like to setup an architecture as the below image:

The problems are:

- The camera attributes(the image size) are switching between others. (Using VBAI 2015, not f1, I am downloading it for evaluate)

- Sometimes I can not change the delay parameter even manually. Camera sets its min and max limits to zero by itself and I can not change it.

- I am using Get Every Image mode for syncronization between cameras. And I can only run read/write step with stopping acquisition in the Setup State. If we can solve the problem with switching parameters and parameter limits, read/write step can help the situation

Brad, thank you for your detailed explanation.

[Brad]

- When I was looking at the changes more closely, I think the bug may actually be fixed in the upcoming f2 release of VBAI 2015.

- If the camera is changing it's min/max to 0, this seems like a bug with the camera. I would recommend talking with their support to see if they are aware of this and if there are any workarounds.

To address the switching attributes, a work around you can try involves:

- Don't edit the acquisition step while the inspection has other acquisition steps in it (The Read/Write Attribute step does not have this problem). To accomplish this:

- Remove the acquisition steps from your inspection so no step uses the cameras

- Create a simple inspection that just acquires from 1 camera. Configure the acquisition how you want in this simple inspection. Repeat this for the other cameras.

- Import these individual inspections into your main inspection (right click on the state diagram and choose Import Inspection)

Once you have the three camera acquisitions imported into your inspection, you shouldn't have any trouble any more (assuming you don't edit those steps). If you need to edit an acquisition step, modify the simple inspection and re-import it to replace the old acquisition you don't want any more.

I know this isn't pretty, but it will ensure you don't have mismatched settings with other steps. There are lots of cases where this isn't a problem (which is why we didn't discover it before now), but when it does happen, this procedure will ensure it doesn't mess up your acquisition settings.

Hope this helps,

Brad