Basler CameraLink Serial Comm VIs..?

[The_Seeker]

Hello,

I'm using a Basler L101k-2k (CameraLink) camera for my current project. Due to the nature of the project, we would like to make config changes to the camera on the fly. According to the camera's documentation, several functions can be accessed via serial commands over the CameraLink connection.

The Basler web site offers a collection of serial comm VIs for communicating with the camera and setting various parameters via this CameraLInk serial connection. In most cases, the VIs appear to change the camera parameters as expected, but IMAQ generates an error with each comm attempt. The IMAQ error is:

-1074397038

NI-IMAQ:  The requested serial termination string was not found in the returned buffer.

In NI's camera compatibility report for this camera, there is a note indicating that the "Keep Port Open" parameter must be set using the camera's own CCT+ software utilitiy. I have tried this too, with no positive outcome.

Does anyone have experience with this camera and/or the Basler CameraLink serial comm VIs? I've tried everything I can think of, but we are starting to run out of ideas. (I suppose we could simply ignore the errors, but I would like to know if we are doing something wrong first.)

[ryanm]

Based on the error statement, I would guess that the termination string is either not setup correctly or not being received.  After a command is sent, the camera should return termination char.  I think this is \r, but you will want to verify this in the camera's users manual.

I am not familiar with Basler CameraLink serial comm VIs, but as a first guess, I would think the VIs are checking for a termination character other than the one that is returned from the camera.  Try using the IMAQ Serial Write.vi and IMAQ Serial Read.vi.  Do these return the same error?

Regards,

Ryan M.

Applications Engineer

National Instruments

[The_Seeker]

Ryan,

Yes, I've tried the IMAQ Serial Write.vi and IMAQ Serial Read.vi -- same error exactly. 

According to Basler's documentation, they return a value of 0X06 as a positive frame acknowledgement (ACK). (The NAK response is 0x15.) Could this be causing a problem?

Basler support indicated that these values follow the CameraLink specification. What could be going on here? 

- The Dude

[The_Seeker]

Ryan,

Quick Question:

Who developed these VIs:

ftp://ftp.ni.com/support/imaq/camera_support/camera_files/digital/basler/Basler Serial Control.llb

Were these built in-house at NI, or were they contributed by a 3rd-party developer?

If someone at NI worked on these, were they ever actually able to get them working with the Basler camera? I've stripped these down to the bare essentials (i.e. IMAQ Serial Read and Write VIs), but I can't seem to send any message to the camera without an error message. Yet the camera works fine and communicates with MAX (and Basler's own CCT+ utility) with no difficulties. So it's reasonable to assume that the CameraLink connection is fine. What's going on here...?

-- D

[ryanm]

The Basler Serial Control.llb were written by NI and designed for specific Basler cameras.  Since the program is still giving you errors, I am guessing the camera is returning a termination character other than what the VIs in the Basler Serial Control.llb expect.  I recommend using the Camera File Generator to see what the camera is returning.  To do this,

1)  Go to www.ni.com/camera

2)  Select the NI Camera File Generator under Option 3

3)  Click the link to download the NI Camera File Generator

4)  Open the latest version (2.0.1)

5)  Run Setup.exe

6)  Go to Start -> All Programs -> National Instruments -> Vision -> NI Camera File Generator

7)  Select Open Existing Camera File and open the camera file you are using

😎  Go to Settings -> Serial Settings

9)  Click on Test Serial Settings

Now, you can enter commands and see the actual response from the camera.  Typically an attribute would look something like:

Attribute (Exposure Time) {
     Value (Integer) {
          Min (1)
          Max (65535)
          Increment (1)
          Display {
          Multiplier (0.5)
               Offset (0)
               Precision (1)
               Units (us)
               }

          Default (110)
          Current (110)
          Action (Serial) {
               Command (:t%.4x\r)
               Response (\r)
          }

     }

}

In this case the software is expecting a \r.  If this char is not received, you will get the error mentioned above.

Regards,

Ryan M.

Applications Engineer

National Instruments

[The_Seeker]

Thanks Ryan. I'll try the CFG tool and see what I can learn.

Cheers.

[The_Seeker]

Ryan,

Thanks for the link to the CFG utility. Using the utility, I was able to modify the ETX (end of transmission) character in the existing .icd file to 0x03 (as the camera expects). I can now communicate with no problems inside the utility, and using the the IMAQ Serial Write and Read VIs -- with the following caveat:

IMAQ Serial Write operations work perfectly. However, the Read vi returns the response string from the camera without the (expected) 0x03 termination character and generates a timeout error.

This is not unworkable -- in a worst-case scenario, I can simply ignore the timeout error and trap for other errors. However, it would be better if timeout errors were generated for legitimate timeouts, and not as the regular behavior for every serial comm interaction. I'm not familiar with the format of the .icd file, but does this file define different termination characters for read and write strings? It appears the termination character is now correct for write operations, but still incorrect for reading. Any thoughts?

In the meantime, I'll look into the .icd file and see what I can learn...

Thanks again for your help. I think we are getting close to the solution.  

-- D   

[ryanm]

It good to hear everything is in a better state.  My initial thoughts for the timeout error are:

1)  Some cameras return different values for different commands.  This would not be the case if you are using the same command you used in the CFG.

2)  Some cameras return different values based on a command being successful.  Lets say you wish to change the frame rate and this can only be set when the camera is not acquiring.  If you try to set this attribute while the camera is not acquiring, it will return one value.  If we try to set this value during an acquisition another is returned.

Hope this helps.

Ryan M.

Applications Engineer

National Instruments

[The_Seeker]

Hi Ryan,

After more experimentation with the CFG utility, I discovered a peculiar anomaly that may be part of the problem.

In the original NI .icd files, the termination character is \r. Using the Serial Setting dialog in the configuration utility I replaced these \r values with "/x03" in the serial dialog -- and please notice the direction of the slash character. Although this appears to have been a typo on my part, that detail appears to be significant.

When using a forward slash "/" character before the "x03" for the termination character, the serial transcation works, but a timeout error is generated. Regardless of how long or short the timeout period, an error message is always returned.

Now, after looking into the .icd files discovering my apparent typo, I reversed the slash direction, changing "/x03" to "\x03". Based on the Basler documentation, I would have assume this to be the correct format. Oddly, if this reverse slash is used, no error message is returned. However, the returned string is incomplete. Only half of the expected message is returned. For example, if I request the current settings for Timer 1, the camera returns everything up to, but not including, the 3 data bytes. Everything after the data bytes is also missing.

I don't know if this peculiar behavior is specific to the 1426. I will investigate this with the PXI-1428 framegrabber later today to see if both boards respond in the same way. Either way, it appears there may be some discrepancy between Basler's definition of the .icd file and NI's definition -- at least in terms of which direction the slash character should go. Or perhaps it could be something as simple as a programming typo (either in the camera firmware, or in the framegrabber serial spec). I can see that it would be quite easy for a programmer to make the same mistake I did -- typing "/" when they really meant to type this "\". Just a thought...

Anyway, thanks again for your help. I've constructed a LabVIEW VI that filters the timeout errors, and it works fine. If this is the best we can do, that's okay. Ideally, I would still like to find a solution that returns the full camera string WITHOUT the erroneous error message, but we can work with it this way, if necessary.

The next step is to check the 1428 and see how it behaves.

Anyway, thanks again Ryan.

-- D

[Wizbit]

Hi all,

I have a PCI-1428 frame grabber and an L801k linescan camera. I too am experiencing the same problems when trying to programatically set any attribute through the cameralink bus.

I checked the .icd file after reading DAQ Dude's post, but couldnt find any reference to the '\r' to signify the end of string. The .icd file iI'm using came from the ni.com/camera site, so I'm not sure where your looking in the file.

Im using IMAQ 3.1 at the moment, but I've read that 3.1.3 might fix the problem according to other threads on niforum.

Al