How to configure these parameters in LabVIEW using Call Library Function Node?

[courage]

I'm working on a project to modify a camera's parameter(ie exposure time,contrast etc.)

There's a DLL file that contains all the functions needed to control the camera and modify its parameters, however,while I tried to use LabVIEW's Call Library Function Node to call this dll to control the camera ,I don't quite know how some of the function's C++ parameters(see below) related to LabVIEW's parameters,so I was wondering if some of the more experienced programmer can give me some advice,all response will be greatly appreciated!

    static void StaticPreviewCallback(const void* pData, const BITMAPINFOHEADER* pHeader, void* pCtx)
    {
        CMainWnd* pThis = (CMainWnd*)pCtx;
        pThis->PreviewCallback(pData, pHeader);
    }

                Toupcam_Start(htoupcam_, StaticPreviewCallback, this);

How to configure StaticPreviewCallback and this(a pointer)

typedef struct{
    unsigned    width;
    unsigned    height;
}ToupcamResolution;

typedef struct{
    const wchar_t*        name;        /* model name */
    unsigned            flag;        /* TOUPCAM_FLAG_xxx */
    unsigned            maxspeed;    /* number of speed level, Toupcam_get_MaxSpeed */
    unsigned            preview;    /* number of preview resolution, Toupcam_get_ResolutionNumber */
    unsigned            still;        /* number of still resolution, Toupcam_get_StillResolutionNumber */
    ToupcamResolution    res[TOUPCAM_MAX];
}ToupcamModel;

typedef struct{
    wchar_t                displayname[64];    /* display name */
    wchar_t                id[64];        /* unique id, for Toupcam_Open */
    const ToupcamModel*    model;
}ToupcamInst;

ToupcamInst ti[TOUPCAM_MAX];

Toupcam_Enum(ti);

TOUPCAM_MAX=16,how to cofigure ToupcamInst and ti[0].displayname  ti[0].id

[smercurio_fc]

That's pretty complicated. I think you're really going to need to write a wrapper DLL whereby you provide simple functions for LabVIEW to use to access the various parameters involved.

[rolfk]

This is not only pretty complicated to do with the Call Library Node, but more or less impossible. StaticPreviewCallback is a function pointer and LabVIEW does NOT know any datatype that could directly represent a function pointer. this could be configured as pointer sized integer, but that only is useful if you get this pointer from some other C function and don't need to access any methods or properties from within LabVIEW this object instance may refer too.

The rest could be done in LabVIEW with a lot of diagram voodoo that requires in fact more C compiler detail knowledge than when writing the entire piece in C code.

But because of the callback function pointer it is anyhow an exercise in vain, so go with an external C DLL that provides an easier API to be called with LabVIEW.

[courage]

Dear smercurio_fc:

I see your point,but is there any way other than write a wrapper dll since my C programming is terrible.How about I use the Vision toolkit to open the camera and use several dll's function to control the camera and alter some of the camera's parameters.Is this possible,if so how can I manage to solve the connectivity issue between dll and labview.

BTW,I've found that the IMAQdx's example is able to open the camera and allow the user to alter some parameters,however,the problem is that this can't alter some specific parameter(ie white balance) and it leaks too much information about our camera,I can't figure out what's wrong.

Sorry for my terrible english and if I don't make myself clear,please let me know!

[courage]

Dear roflk:

Thanks for reply!

In your reply,you suggest that ToupcamInst can be configured in LabVIEW however very complicated and requires lots C detail knowledge.Are you saying the configuration of ToupcamInst depends on its C bytes and it should be exactly the same in LabVIEW.

And since the function pointer is impossible to configure in LabVIEW ,I was hoping if you can read my preview reply and see if that's plausible.

Again, thanks for reply!

[rolfk]

---

@courage wrote:

Dear roflk:

Thanks for reply!

In your reply,you suggest that ToupcamInst can be configured in LabVIEW however very complicated and requires lots C detail knowledge.Are you saying the configuration of ToupcamInst depends on its C bytes and it should be exactly the same in LabVIEW.

And since the function pointer is impossible to configure in LabVIEW ,I was hoping if you can read my preview reply and see if that's plausible.

Again, thanks for reply!

---

Well, of course do you have to make sure that a structure that is passed to a Call Library node matches the C memory layout EXACTLY. And this requires more knowledge about how C does these things than using the structure in C, since you make part of the work that the C compiler usually does automatically. You still need to know in both cases things like structure element alignment used when the external DLL was compiled, but you also need to create the LabVIEW cluster that matches this exactly and for embedded arrays this gets a bit cumbersome and for pointers inside a structure even more.

Since the Toupcam driver is a DirectX/DirectShow compatible driver, it's not surprising that it can be used from IMAQdx. Have you read this document as to how properties in IMAQdx devices are accessed (and enumerated)? Since those properties can vary between different camera manufacturers and even between models from the same manufacturer, it's not practical to write a potentially enourmous library to access any of the possible properties under the sun.

[courage]

---

Well, of course do you have to make sure that a structure that is passed to a Call Library node matches the C memory layout EXACTLY. And this requires more knowledge about how C does these things than using the structure in C, since you make part of the work that the C compiler usually does automatically. You still need to know in both cases things like structure element alignment used when the external DLL was compiled, but you also need to create the LabVIEW cluster that matches this exactly and for embedded arrays this gets a bit cumbersome and for pointers inside a structure even more.

Since the Toupcam driver is a DirectX/DirectShow compatible driver, it's not surprising that it can be used from IMAQdx. Have you read this document as to how properties in IMAQdx devices are accessed (and enumerated)? Since those properties can vary between different camera manufacturers and even between models from the same manufacturer, it's not practical to write a potentially enourmous library to access any of the possible properties under the sun.

Rolf Kalbermatter
CIT Engineering Netherlands

---

Dear rolfk

  I've read the document you refered, and I've tried to use this method to alter some of the camera's attributes, most of them worked just fine, but there's one parameter whitebalance that can't work properly,everytime I change its value "NI-IMAQdx: (Hex 0xBFF69010) Unable to set attribute."occurs and automatically terminates VI. However, using the application complied by C++ can enumerate and alter a lot more attributes than the example VI 'Grab and Attributes Setup.VI' some of those attributes like exposure time and frame rate are the ones that we value the most.

It seems some of the camera's attributes are not supported nor can be enumerated using IMAQdx driver.Do you know why.Can IMAQdx be able to enumerate all the attributes and does it mean that the attributes IMAQdx can't enumerate will not be able to altered in LabVIEW?There's a company IDS,the camera they made(uEye series) can be controled by LabVIEW,I just read the example VI they offered, they use their own dll to accomplish this instead of IMAQdx driver,I'd like to do the same using DLL of our own.So the question I asked above is critical.

Thanks for reply and if I don't make myself clear please let me know.

[rolfk]

---

@courage wrote:

It seems some of the camera's attributes are not supported nor can be enumerated using IMAQdx driver.Do you know why.Can IMAQdx be able to enumerate all the attributes and does it mean that the attributes IMAQdx can't enumerate will not be able to altered in LabVIEW?There's a company IDS,the camera they made(uEye series) can be controled by LabVIEW,I just read the example VI they offered, they use their own dll to accomplish this instead of IMAQdx driver,I'd like to do the same using DLL of our own.So the question I asked above is critical.

Thanks for reply and if I don't make myself clear please let me know.

---

If IMAQdx can't enumerate them, then they are either not exposed by the driver through the standard DirectX interface methods, or use rather exotic data types that IMAQdx doesn't support a conversions to and from. And if IMAQdx can't enumerate a property I'm pretty sure that you can't access it either.

In C you can call even special object methods that are not the standard DirectX interface, but LabVIEW can't give you that possibility since it tries to abstract that low level complication away as much as possible. It's the old story about easy to use high level interfaces where you don't have to worry as much about pointers, object interfaces, memory management and such at the cost of advanced flexibility or programming in C(++) and having every possibility to access whatever there is accessible and sometimes even more, but at the cost of having to worry about every single low level detail too.

As to writing your own DLL, sure is it possible, but it is a rather trroublesome path. Not only do you have to deal with C details in general, but image acquisition is an area where you have to deal with pointers a lot and manage them very carefully. One pointer allocated wrong can crash your entire application, and forgetting to release them properly after use causes memory leaks, which for image acquisition is usually a very big leak for each pointer. Unless you have some proficient C programmer at hand I would not recommend to use an image acquisition interface DLL as project to learn doing your own DLL.

[courage]

---

If IMAQdx can't enumerate them, then they are either not exposed by the driver through the standard DirectX interface methods, or use rather exotic data types that IMAQdx doesn't support a conversions to and from. And if IMAQdx can't enumerate a property I'm pretty sure that you can't access it either.

In C you can call even special object methods that are not the standard DirectX interface, but LabVIEW can't give you that possibility since it tries to abstract that low level complication away as much as possible. It's the old story about easy to use high level interfaces where you don't have to worry as much about pointers, object interfaces, memory management and such at the cost of advanced flexibility or programming in C(++) and having every possibility to access whatever there is accessible and sometimes even more, but at the cost of having to worry about every single low level detail too.

As to writing your own DLL, sure is it possible, but it is a rather trroublesome path. Not only do you have to deal with C details in general, but image acquisition is an area where you have to deal with pointers a lot and manage them very carefully. One pointer allocated wrong can crash your entire application, and forgetting to release them properly after use causes memory leaks, which for image acquisition is usually a very big leak for each pointer. Unless you have some proficient C programmer at hand I would not recommend to use an image acquisition interface DLL as project to learn doing your own DLL.

---

I see your point, I just have a couple more questions.In my first reply I metioned a thought that combines IMAQdx driver and CLN to complete the goal: use the IMAQdx driver to open the camera and CLN to configure a specific function to alter the camera's corresponding attribute like exposure time. I was wondering if this is possible and if it is possible then how to make it happen?

About the IMAQdx driver, I absolutely know what you mean, but let me get this straight: if IMAQdx can't enumerate some attributes, does it mean LabVIEW can't alter those attributes whatsoever even using CLN? And would it be enumeratable if the extern C DLL be rewritten to conform to LabVIEW's standard type or rewrite the DirectX's interface? To make myself clear, rewrite the DLL is to use the CLN to do all things(open camera;alter camera's attributes); rewrite the DirectX's interface is to enable the IMAQdx driver to enumerate all the attributes. The difference is the question marked: if IMAQdx can't enumerate some attributes means that those attributes can't be accessed in LabVIEW,then there's no point rewrite DLL, rewrite the DirectX's interface might be more plausible.

Thanks for your help and your patience!And if I don't make myself clear please let me know.

[rolfk]

---

@courage wrote:

I see your point, I just have a couple more questions.In my first reply I metioned a thought that combines IMAQdx driver and CLN to complete the goal: use the IMAQdx driver to open the camera and CLN to configure a specific function to alter the camera's corresponding attribute like exposure time. I was wondering if this is possible and if it is possible then how to make it happen?

About the IMAQdx driver, I absolutely know what you mean, but let me get this straight: if IMAQdx can't enumerate some attributes, does it mean LabVIEW can't alter those attributes whatsoever even using CLN? And would it be enumeratable if the extern C DLL be rewritten to conform to LabVIEW's standard type or rewrite the DirectX's interface? To make myself clear, rewrite the DLL is to use the CLN to do all things(open camera;alter camera's attributes); rewrite the DirectX's interface is to enable the IMAQdx driver to enumerate all the attributes. The difference is the question marked: if IMAQdx can't enumerate some attributes means that those attributes can't be accessed in LabVIEW,then there's no point rewrite DLL, rewrite the DirectX's interface might be more plausible.

Thanks for your help and your patience!And if I don't make myself clear please let me know.

---

I don't think that you can mix IMAQdx and direct access in a CLN together. You most likely don't have any access to the IMAQdx internals that would be necessary to get at the DirectX object references in order to access the DirectX interface to the driver directly. So you may  have to initialize the connection to the driver and access those properties and then access the image retrieval functions all from the same component, unless the properties persist across sessions.

And if IMAQdx can't enumerate certain properties, that doesn't mean that you could not access them otherwise, just most likely not do one thing in IMAQdx and the other in non IMAQdx, unless you could make sure that changes you do in one session do persist over sessions. But that I'm not at all sure. If those properties survive a closing of a session you could first call a CLN function that opens the device, does whatever is necessary to set properties and the like and then closes the device again and after that uses IMAQdx to do the rest. But if properties persist between sessions is likely an implementation detail of the camera driver itself.

You can't rewrite the DirectX interface at all, that is a specification setup by Microsoft and changing that interface means being incompatible with everything. The driver maniufacturer can extend it with his own interfaces but they can't be accessed by software not specifically written for those proprietery interfaces. And changing the driver is most likely not an option since the manufacturer won't give you the source code for it. Besides those drivers are interfacing with Windows kernel components which is an entire world of its own in terms of complexity and challenges.