VBAI GigE change attributes on the fly

[Johan]

GigE standard opens up for cable length of up to 100 Meter, and because of this GigE cameras have digital I/O built into the camera. 

VBAI GigE object opens up for changing the attributes (I/O) on the fly, but every time one or more attributes changes the Image acquisition time increases from about 10 ms to 200 ms.

This is not good for our application since we are inspecting 6-7 parts pr.sec.

The camera we are using is Basler scout scA640.

We have migrated the GigE object to labview, and here we can see that if one attributes changes it writes all to the camera.

Is there a fix for this problem?

[Brad]

In VBAI 3.5.1, the step only writes attributes that have changed, but it also stops the acquisition before writing these attributes and then starts it again after it's done writing. This is to fix issues with acquired images not reflecting acquisition attributes that changed. 

http://joule.ni.com/nidu/cds/view/p/id/1062/lang/en

The stopping/starting can take up to 200ms on the Basler cameras because of an issue with the XML file. Basler is looking into fixing this for future firmware updates.

The ability to just read/write specific attributes is a good suggestion that we will investigate.

Thanks,

Brad

[BSoleglad]

Well I it's good that it's just writes the attributes that has been changed.

But I see to ways to solve this problem:

- NI has to have a solution on have too writes attributes without restart the communication to the camera.

- Basler has to solve their problems with their XML fil.

On this discusion forum the problem for NI is known, but for basler not. If you say that the XML file from basler has some fault inside, can you discribe them for me, or show them. I don't understand the XML file when i read them, but i will try too phone Basler and let them work a little. 

[BlueCheese]

Hi Bjørn,

As Brad mentioned we will be looking to see in what ways it may make sense to expand the capabilities of Vision Builder to make better use of available features exposed on GigE cameras. As you can see, the current interface is intended to make acquisition simple and not be needlessly complex. It is designed as an acquisition step, not an I/O step. This was sufficient for previous types of cameras because the actual camera I/O (besides triggering) was generally very limited and instead relied on capabilities in the framegrabber and.or other hardware. We appreciate your suggestions and will be looking to see what improvements we can make. The underlying IMAQdx API does in fact allow full use of this functionality so you may consider as one alternative to write your inspection in LabVIEW (or migrate it from Vision Builder) if you want full use of all the functionality available on the camera at the present time.

We have already discussed the issue with Basler and they have committed to making a change in a future revision of their camera's XML files to improve their behavior in our software. Essentially the XML feature that is used to Start/Stop the image stream never returns that it has completed because of the way the XML is written. Because it never completes on its own we instead hit a 100ms timeout in IMAQdx and return (the error is currently ignored because some other cameras have this subtle issue as well).

As a temporary workaround, you should be able to make the following modification:

Take the section here:

  <Command Name="AcquisitionStart" NameSpace="Standard">
    <ToolTip>Starts the acquisition of images</ToolTip>
    <Description>This command starts the acquisition of images. If the camera is set for single frame acquisition, it will start acquisition of one frame. If the camera is set for continuous frame acquisition, it will start continuous acquisition of frames.</Description>
    <DisplayName>Acquisition Start</DisplayName>
    <pIsLocked>NOT_TLParamsLocked</pIsLocked>
    <pValue>AcquisitionStart_CtrlValueFao</pValue>
    <CommandValue>1</CommandValue>
  </Command>

and modify it like so:

  <Command Name="AcquisitionStart" NameSpace="Standard">
    <ToolTip>Starts the acquisition of images</ToolTip>
    <Description>This command starts the acquisition of images. If the camera is set for single frame acquisition, it will start acquisition of one frame. If the camera is set for continuous frame acquisition, it will start continuous acquisition of frames.</Description>
    <DisplayName>Acquisition Start</DisplayName>
    <pIsLocked>NOT_TLParamsLocked</pIsLocked>
    <ImposedAccessMode>WO</ImposedAccessMode>
    <pValue>AcquisitionStart_CtrlValueFao</pValue>
    <CommandValue>1</CommandValue>
  </Command>

This should make the acquisition Start/Stop on the Basler GigE cameras complete very quickly.

Hope this helps,

Eric

[BlueCheese]

Sorry, you have to do the same thing to the AcquisitionStop feature as well.

-Eric

[Johan]

Ok Eric,

I will try to modify the XML sheet later this evening (we are 6 hours ahead of you), to see if this can be a temporarily workaround as you say.

Because this is going to be a relative dynamic application that needs to be continuously modified over time, we would prefer to use the VBAI interface instead of labview. And also this doesn’t rely so much on just 1 or 2 persons at our company, since the level of skills needed for  VBAI is not so high. 

Regards Johan

[Johan]

Hi Eric,

If I have edited the right XML-file "C:\Documents and Settings\All Users\Documents\National Instruments\NI-IMAQdx\Data\XML\Basler_GigE_Version_2_0.xml", then this did not help us at all, in fact after upgrading with the 3.5.1 patch the acquisition time increased even more.

I also checked the file in the PreprocessedCache folder to see if the file really was modified, which it was.

Please post a working application, so we can see what you see.

Johan

[Brad]

I just tried this in VBAI 3.5.1 and sentting 1 IO attribute went from 350ms to 15ms after modfying the Start and Stop attributes in the XML. I have a newer XML version than you, but feel free to give it a try (make a copy of your current one in case it doesn't work). I'm attaching the xml file I updated, so hopefully you'll see similar benefits.

I had to zip up the XML since the forum didn't let me post a xml file, so unzip this and put the XML in your data directory and move your current XML out of there.

[Drogmiss]

Hello everybody;
Want just to ask a simple question :Is there any XML description file for Sony camera's.?
Regards.

[Johan]

Hi Brad,

The problem remains.

Before we installed the patch for vision builder and modified the XML-file, our acquisition time was 3-4 ms without changing the attributes. When changing the attributes we got up to 80 ms. And now with the 3.5.1 patch we are up to 280 ms without changing the XML-file, when changing the XML-file we get down to 90 ms. The result is the same for the new XML-file. So we actually didn’t gain anything, but there are probably some other important fixes in the new XML-file.

We have received feedback from Basler that the necessary improvement of the XML-file is going to be fixed within 2 weeks, and then sent to NI.

Since Ni probably will need additionally 1-2 weeks, we will again be far behind schedule.

If you have managed to get down to 15 ms, then maybe I am missing something here. It would be interesting to see your application.

Attached is my I/O test application.

Johan