Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem reading serial port on PCI-1422

Ah, I think the Read/Write (no "Bytes" suffix) are meant for ASCII-string commands with certain termination. If you are sending binary command strings you are probably much better off with the "Bytes" variants.

 

Eric

Message 21 of 27
(1,638 Views)

Also, I was having a little trouble with my checksum algorithm...

 

since the serial write/read functions use char instead of unsigned char, any value over 127 (0x7F) results in the sum no longer acting correctly...   should I work with an unsigned char array and then cast it as a signed char array before passing it to the function?

0 Kudos
Message 22 of 27
(1,637 Views)

 


vs3@tamu wrote:

Also, I was having a little trouble with my checksum algorithm...

 

since the serial write/read functions use char instead of unsigned char, any value over 127 (0x7F) results in the sum no longer acting correctly...   should I work with an unsigned char array and then cast it as a signed char array before passing it to the function?


 

If you are working with binary data it is arbitrary whether the data is signed or unsigned. IMAQ chose to describe it as signed, although it doesn't really matter as it looks the same either way. So yes, you would cast the data between signed and unsigned as you move it between your code and the function.

 

Eric

0 Kudos
Message 23 of 27
(1,635 Views)

right, but unfortunately unsigned 0xFF is 255, and signed 0xFF is -1...  so the function (x + 0xFF) turns out different when signed and unsigned.   (x - 1) or (x + 255) respectively...

 

and there is no built in conversion between char* and unsigned char*...  drat.  My plan now is to work with unsigned char arrays and just cast them to char arrays before passing them into the function...   that way during my sumation I can just use sum += buffer[i] in a for loop  before using (sum / 0x100) and (sum % 0x100) as my checksum bytes.

0 Kudos
Message 24 of 27
(1,630 Views)

Sure, I meant that IMAQ did not touch the data in any ways that depended on the signed-ness. You can do just what you are describing and cast the arrays. You could also cast the data within the arrays as you use it, but the way below means all the data is always accessed in your own code as unsigned.

 

 

unsigned char myDataBuffer[64];
// set myDataBuffer contents for command
uInt32 bufSize = commandSize;

err = imgSessionSerialWrite(sid, reinterpret_cast<Int8*>(myDataBuffer), &bufSize, timeout);
bufSize = expectedCammandResponseSize;
err = imgSessionSerialReadBytes(sid, reinterpret_cast<Int8*>(myDataBuffer), &bufSize, timeout);

If you are using a C-only compiler, you'd replace reinterpret_cast with (int8*)(myDataBuffer). Eric

Message 25 of 27
(1,623 Views)

Be aware that the checksum itself is a 16-bit value.  If you try to store it in a char, it will overflow.  I found this out the hard way.

Message 26 of 27
(1,621 Views)

Alright everything works now!  Thanks, you two.

 

for the record, the order that I'm calling the commands is 0300, 0303, 8101, then 0101

 

this sets LONG_INT to 0, then sets the INT_TIMER to my desired value, before changing the INT_MODE to 0...

 

i can now adjust the integration time with a constant array of integers according to the needs of each of my 5 optical filters.

0 Kudos
Message 27 of 27
(1,591 Views)