ascii to I16

[Wayne.C]

RachtheSabu,

What you really need to know is what all is included in the response from the robot.  You know to expect an I16.  Does the response include other things like a termination character?  A null is often used for this.  It really sounds like part of the first response is ending up being read with the second response.

[RachtheSabu]

A sample of the string from the VISA read is : "ÿò"

Sometimes the string read in from the VISA has a space before the characters such as : "_ÿò" (where the '_' represents a space).  I tried replacing the bytes at port with just the constant 2, but doing so I get incorrect values.  Looking at what is being read in from the VISA read with the constant bytes, I typically only receive one character at a time (instead of 2).   I have another way to communicate with the robot (that for a user is much less intuitive) and after writing the Hex commands 8E13, receive 2 Hex values back (i.e. 00 44) everytime.  

[Dennis_Knutson]

When you specify 2 bytes to read, you will either get 2 bytes or an error. You will not get 1 byte unless you've done something silly like enable the the termination character with the VISA Initialize Serial Port.

[ESST]

Hi,
 

Normally when talking about ASCII encoded data, it means that each bytes represents a letter, as in the number 345, being represented by '3', '4', '5' (0x33, 0x34, 0x35).

It sounds like we have binary data, even though its encoded as string when it comes out of the visa VI.

The 255 is (likely) due to the encoding of the I16. Check out Two's complement. With a small negative number, your MSB will be 255. (-1 is 0xFFFF(I think)). As for the space. Are you sure its a space, and not some non print character, like 0x00?. Because if you are getting, for instance, 0 0 -1 0 0 -1. As text that will look like "    ÿÿ    ÿÿ". It sounds like the equipment is continualy streaming. Read two bytes at a time, short timeout (to not get one byte per message), and cast to I16. You should be right.

[RachtheSabu]

I'm pretty sure it's a space and not a non-print character.  Below are examples of what I'm reading in (the first section is using bytes at port, the second section is a 2 bytes constant).  They aren't for the same exact information, but all the info I should be receiving should represent small negative numbers.  (The info is actually in two columns as I'm writing and reading twice on each interation - the first read should be the small negative values and the second read should be zero for the tests I've been performing.)

 ÿþ   
 ÿü   
 ÿø   
ÿû   
 ÿ    ü
 ÿ    ú
 ÿû   
     ÿü

 ÿ    ü
 ÿ    û
 ÿ    ú
 ÿ    ú
ÿú     
 ÿ    ù
 ÿ    ù

As you can see, the format is not constant and has spaces - the root of my problem (I think).  I do have time waits between each write and read.

[altenbach]

Can you set your string to hex display and repost the output?

[Darin.K]

I will also wager that the space is actually \00, either \ code display or hex display will show you.  When I try to communicate with a cantankerous piece of hardware I usually flush the buffer before the query begins to avoid contamination from unread bytes from a previous query.  I always use 'bytes at serial port' to determine how many to read, but I also use it as a sanity check as well.  If you expect 2 and get 2 (after a reasonable delay) you are probably ok.  If you occasionally receive more or less, I would flush and try again when it happens.  If you consistently get more, I would hope that the pattern is consistent and you could extract the two bytes that represent the data.

[RachtheSabu]

Again, the first section is using bytes at port, the second section using the constant 2 bytes.  (The formatting was a little hard to tell, so the '-->' represents a tab - number to the left is from the first read, number to the right is from the second read.)

00FF FE -->
00FF FD -->
00FF FA -->
00FF --> FA
00FF FB --> 0000

00FF --> FA00
FFFB --> 0000
FFFA --> 0000
00FF --> FB00

[Dennis_Knutson]

It appears that either the manual does not adequately explain the communication protocol or you have not totally understood what it says. while it does seem that the data consists of 2 bytes, the robot is actually sending 3 and it is using the null character to separate the data. Wayne mentions this above. In order to synchronize the data being read, you can do a read until you detect a null, discard the null, and then read 2 bytes. After that, you can probably just always read 2 bytes, use that data, read 1 byte and discard.

[Wayne.C]

RachtheSabu,

We seem to be going in circles here.  If you look at the data you posted, a hex FFFE, FFFD, FFFB and a FFFA would all represent small negative numbers when converted to I16.  The zero's are also expected.  The problem is that your reads are not properly synced with the incoming data.  The bit of code you posted shows sending a 4 byte ascii command and that you expect a 2 byte reply.  I understand that.  Where is the data from the other VISA Read coming from?  Did you send a different command?  Is this data continuously streaming from the robot?

If at all possible please post a copy of your vi and copy of communications manual for robot.

Dennis,

I think the tab "-->" characters were added to the post to differentiate first and second read data.