Need .h file for x86 and x64 functions in clsernat.dll

[h9001]

We need to bypass the NI Vision Acquisition/IMAQ serial level and access the CameraLink serial layer directly for a custom baud rate. 

The clsernat.dll is present but cannot locate documentation for the exposed functions in clsernat.dll. NI did not include a .h file or documentation regarding the typedefs for the following functions :

clFlushPort

clGetErrorText

clGetManufacturerInfo

clGetNumBytesAvail

clGetNumSerialPorts

clGetNumSerialPortsAtIP

clGetSupportedBaudRates

clSerialClose

clSerialInit

clSerialRead

clSerialWrite

clSetBaudRate

( Reasoning- IMAQ will occasionally validate the camera file and change the baud rate. The end result is missmatched baud rates corrupting the serial data channel.)

Any assistance would be appreciated.

Steven.

[Joel-P]

Hello Steve,

I have begun looking into documentation regarding the expected parameters for these functions. You mentioned that IMAQ will validate the camera file and change the baud rate, is this because the camera file being used is not configured correctly? If so, you could consider editing the camera file using the NI Camera File Generator.

Cheers,

Joel

[h9001]

Joel,

The baud rate for the camera is supported by the serial UART on the NI board but not by the NI IMAQ. I suspect the UART during design only went up to 56k and that is the information in the IMAQ Driver. You can edit the raw camera file, set it to the baud rate, and it will work fine until the NI performs a validation on the camera file.

The mfg software works fine because it is writting to the clsernat interface. Ours was going through the IMAQ and flakes out when IMAQ decides to change the baud rate. Accessing the imager directly will actuall work better in our setting.

[Joel-P]

Hello Steven,

Unfortunately the only supported method for this communication would be using the NI IMAQ software and using the Baud rates that are configured in the camera file.

The supported baud rates are:

• 9600
• 19200
• 38400
• 56000
• 115200
• 230400
• 460800
• 921600

I will continue to look into this, however I think that it is unlikely that I will be able to provide any additional information regarding this communication.

Cheers,

Joel

[h9001]

Joel, you information is incomplete. The clsetnat does pass through the imaq.dll at a vety low level but bypasses the camera file. This is required by the Camerlink specification. There are more baud rates that are available, again refer to the CameraLink specification. In this particular case the target baud rate is 56.7k. The NI 1430 boards list this as available for the camera file but when the older 1428s are used the only way is through the CameraLink API. ( NI support acknowledges that this is a valid speed for the later 1428 boards)

Steven

[h9001]

Joel,

Appologize for the earlier typos. (Was responding through a browser on a touchscreen phone.) 

The baud rate in this particular case is 57.6K. 

The camera link cl serial interface will work fine all day communication at 57.6K using the MFG's test utility (when the camera file has the default baud rate of 9.6K.) The NI document which also confirms this is a viable speed for the 1428 is http://digital.ni.com/public.nsf/allkb/359CC1956ABBB6F3862575A500674FEC and 57.6K is a listed speed for the 1433 board.

What is strange is other manufacturers provide the c++ header files, libs, and the required dll but NI only includes the dll in the IMAQ package. (Especially since NI provided an early implementation to the Camera Link working group with these files.)

Thank you,

Steven.

[h9001]

Joel,

Could you provide an update on your progress? 

Thank you,

Steven.

[h9001]

Still waiting on a response...

[Joel-P]

Hello Steven,

The only additional information that I have found regarding calling into this dll is a community example which implements some of the functionality that you are looking for.

Send Serial Command To Fram Grabbers in VBAI

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

cheers,

Joel

[h9001]

I had asked the author since they had used the same interface I am trying to access when they wrote their dll but I have not received a response yet.

Steven.