Problem reading serial port on PCI-1422

[MG]

Running LabVIEW 8.0,

IMAQ from the VisionAcquisitionSoftware800 (downloaded from ni.com),

PCI-1422 card,

Indigo Alpha-NIR camera

I am trying to read (and write) to the serial port on the PCI-1422 card.

The hardware (1422 card, cable, camera) works, because the app that shipped with the

camera can adjust the integration time via this port........on another PC that has LV 7.1.1 installed.

(To get that app working, their intalllation instruction asked me to install IMAQ 2.5.1 and replace some DLLs with new ones).

I want to write my own application in LabVIEW 8.

I can not communicate with the camera uisng LabVIEW 8 and IMAQ 3

MAX shows the device, and I can grab or snap images.

There are no camera parameters accessable from MAX.

The camera uses "binary" not ASCII command strings, and most every command or response includes a NULL (00) character.

The error I'm getting is -1074397038 The requested serial termination string was not found in the return buffer

If I examine the Alpha-NIR.ICD file, I see termchar()   (which looks like "no termination string" to me).

How can I tell IMAQ to just give me the characters and not look for a termination string?

[DaveCT]

Reading the Indigo Alpha NIR.icd camera file in Program Files/National instruments/NIIMAQ/Data,

you can see that there are no references to camera commands.

There are two ways to send commands to your camera. with the file as is, you can use imgSessionSeriaWrite.vi

(or equivalent named vi in LabView). You need to know from the camera manufacturer, what the protocol it is

expecting.  Another way to communicate with the camera, would be to edit and therefore create a new cameraname.icd file.  that adds the communication. then those commands would appear in MAX.  Here is a small portion of one for a

camera to show you the idea ;

Attribute (Camera Settings) {
      Value (List) {
         Name (Default) {
            Action (Serial) {
               Command (\x02\xffcD\x80\x03)
               Response ()
            }

            Action (Serial) {
               Command (\x02\xffcT0\x80\x03)
               Response ()
            }
         }

         Name (User) {
            Attribute (Capture Mode) {
               Value (List) {
                  Name (Continuous) {
                     Action (Serial) {
                        Command (\x02\xffcC0\x80\x03)
                        Response ()
                     }

                                               END OF SMALL EXAMPLE   my termination character is 0x03

A CAVEAT:  THE STRUCTURE OF THIS SECTION IS VERY IMPORTANT WITH THE PAIRING OF {   }

otherwise, it will show in MAX as a damaged camera file.  a very good way around this is to use the NI Camera File Generator. If you are prepared to answer the questions about the cameras protocol.

[RyanF]

Hi MG,

First, you will need IMAQ 3.5.1 in order to write this program in LabVIEW 8.  This download is free on the NI site. 

Have you tried the NI Camera File Generator? It will allow you to test serial communication with your camera.  If you open your existing camera file (or simply create a new default camera file) and then go to Settings->Serial Settings, you will be able to test the serial commands and responses of your camera.  For more information please refer to the NI Camera File Generator Online Help (Ctrl+H).

As I understand it, the main issue here is an inability to specifiy what type of data LabVIEW is "listening" for on the serial port.  That said, LabVIEW does not directly expose the functionality to read serial data that is not null terminated.  There is a function in the API that will read a user-specified number of bytes from the serial port.  Attached to this post is a custom LabVIEW VI that calls the function imgSessionSerialReadBytes.  Using this VI in place of the IMAQ Serial Read should allow you to specify how many bytes to read from the serial port and parse it from there.  Let me know if this fixes your issue or you have further questions.

Regards,

RyanF

Message Edited by RyanF on 01-25-2006 02:35 PM

[MG]

To DaveCT:

I should have stated in my original post - I am usig imgSerialWrite and imgSerialRead vi

There are no references to camerra commands in the .icd file becasue the camera does not use ASCII for the commands, and there is no "termination string". 

It uses a binary protocol with a counter that increments everytime I send a command, and a CRC so the last byte is almost never the same, and it can vary even for the same command.

For example, if I ask for the camera's serial nnumber.......since the final byte is the CRC it will change according to what the counter is, even though the serial number is the same every time.  It gets worse for values such as integration time that can change.

To RyanF:

NI CameraFileGenerator installer tells me I need IMAQ 3.0 or greater to install it (even though I have IMAQ 3.5.1 installed).

Even if I could install it though, I would not be able to build an .icd file because of the protocol issues.  The camera outputs a counter (for diagnostic purposes) that increments with every command/reponse.  No matter what "termination" character I choose, I can be assured that this counter will output that value (once very 256 times).

Since I understand the protocol, and can decode it properly with LV 7.1 and IMAQ 2.5.1......I simply need to be able to call imgSerialRead.vi and get the raw string. 

When I call imgSerialRead.vi, it times out giving the error described in the original post.

I simply need to read the raw string, even if it includes \00 bytes, and decode it myself.

[RyanF]

Hey MG,

The reason that the Serial Read is timing out is because it is waiting for a termination character.  Did you try replacing your Serial Read with the Serial Read Bytes that I provided?  If you know or can guess the number of bytes in the response string then the function should return a string of the size you defined.  This string should include any /00 bytes which you can then decode yourself.  Was this not the case?

Regards,

RyanF 

[MG]

Yes, your VI lead me to a solution.  Thanks

[vs3@tamu]

MG,

you stated that you understand the binary packet protocol of the Alpha?  So far the way I understand it each packet must begin with an "I" (0x49) and be 8 bytes long.  I cannot find an example of a valid packet anywhere, and have not been able to read a response from my camera.

I am programming in C++ using MSVS 2008.  I can read and save images from the camera, and I'm trying to use the imgSessionSerialWrite(...) and the imgSessionSerialRead(...) functions to change the integration time and gain while also rotating a filter wheel and snapping, and saving images.

What would a valid packet to change integration time look like?

[MG]

If you don't already have it, you need to get a copy of the interface control document for your version of the camera.  For ours, integration time was the most complicated thing of all.  It is much easier to read the serial number (for example). 

For our version of the firmware, to set integration time, you first have to decide if it is a "short", "normal" or "extended" integration time....keeping in mind some integrations times are not legal. 

1 to 17.9us is "short", 17.9us to 0.0333ms is "normal", 0.065ms to 8.5s is "extended". 

The command for each mode is different.  Let's assume you want a "normal" integration time of 0.03s. 

The packet would be formed as follows:

4903 03FF 0000 0214 EB02 4F  (obviously HEX)  

The 14EB pair of bytes is the TIMER count for 30 milliseconds of integration time. 

Another example is 10 milliseconds   

4903 03FF 0000 028C C502 A1 

This time the timer is 8CC5. 

Remember you also have to set the FPA mode register (which is command 0300 I think), and the order in which you set the registers is important too. 

It's been a while since I've seen our ICD but I think Indigo will email you a copy if you ask.

[vs3@tamu]

Just to see if I'm understanding:

Process: 49 - Required

Function: 0303 - normal integration timer

FF00 - unread by Slave

Byte Count: 0002 - # of bytes used for Data

Data: 8CC5 - Integration timer setting.

Checksum: 02A1 - why is this not just 0009?

to send this command to the camera through my PCI 1422 framegrabber, is the code something like:

int buffer_size = 11;

char * buffer = new char[buffer_size];

buffer[0] = 0x49;

buffer[1] = 0x03;

buffer[2] = 0x03;

buffer[3] = 0xFF;

buffer[4] = 0x00;

buffer[5] = 0x00;

buffer[6] = 0x02;

buffer[7] = 0x8C;

buffer[8] = 0xC5;

buffer[9] = 0x02;

buffer[10] = 0xA1;

imgSessionSerialWrite(sid, buffer, &buffer_size);

Then wait for a response?

[MG]

looks correct to me.  As for the checksum, it is a sum of the first 9 bytes.

don't forget to send the 0300 command, with data byte of 00 (to set the LONG INTEGRATION MODE to "INT MODE") then send the 0101 command with data byte = previous FPA mode bit-ored with binary 100.  (or hex 04).  Not real sure what these commands do for you, but I have it in my code that sets integration time and it wouldn't be there if we didn't need it.

Again, this is for our version of the firmware.  Your mileage may vary.