Need help preventing VISA Read from interpreting value at port

[am0n]

So, are you saying that when you convert '\n' you now get the Hex value for '\' followed by the Hex value for 'n'?  Or do you still get 0x0A?

[billko]

if i translate \n i get the ascii 10 errr... 0A hex

Message Edited by billko on 08-26-2009 05:46 PM

[billko]

You'll have to split up the characters then xlate separately

Message Edited by billko on 08-26-2009 05:49 PM

[billko]

I think ORIGINALLY the problem was the termination character thing.  Once you fixed that, the two characters came through okay, but then the string-to-U8 function said, "oh, I see the return character /n" and proceded to translate it, mimicing the original problem!

[am0n]

Bill, Ben,

Resolved the issue.  Turned out it was not LabView, but my microcontroller and the example code used for UART transmission.

Even though I was stating that I thought LabView was 'ignoring' one of the bytes, this did not completely make sense.  If LabView was told to read two bytes and ignored one, it would think it had only read one byte.  Since the microcontroller would only send two more bytes when the command was sent to it, the VI would continue to wait until a second(technically third) byte was available, but it would never come.  This would cause the VI to get stuff in a loop, which was not occuring.

My next thought was that instead of only one byte being sent, more than two, possibly three, were being sent.  This would cause something like:

[MSByte, Junk, LSByte] [MSByte, LSByte] [MSByte, LSByte] 'or' [Junk, MSByte, LSByte] [MSByte, LSByte] [MSByte, LSByte] which after a few cycle would start returning [LSByte, MSByte].

When Bill showed the example of LabView interpreting '\n' as 0x0A, I thought about the UART transmission code that I was using (pulled from an example for this particular microcontroller).  What the code did was if it saw the character '\n' it would first send the Carriage Return character (0x0D) and then the actual character it was supposed to transmit.  I thought that maybe the microcontroller, like LabView, was converting '\n' to 0x0A.  I wrote up something quick that basically did:

if( 0x0A == '\n' )

 send 'T'

else

 send 'F'

Sure enough, I got 'T.'  What was happening was when the character 0x0A was to be sent, it made it to the if( ch == '\n' ) and since '\n' == 0x0A, it would first send 0x0D and then 0x0A.  So, instead of one byte, it was sending two.  So, instead of sending the two bytes I was expecting to send, if one byte was 0x0A it would send three bytes total, causing one of the bytes, the LSByte, to be read on the following transmission and causing what appeared to be the 'reversal' in the data.  I eliminated that aspect of the code and now it works fine.

[billko]

am0n:

Yay!  Good work!  Glad you got it sorted out.  🙂

Bill

[rolfk]

---

billko wrote:
I think ORIGINALLY the problem was the termination character thing.  Once you fixed that, the two characters came through okay, but then the string-to-U8 function said, "oh, I see the return character /n" and proceded to translate it, mimicing the original problem!

---

The String to Byte Array function does not do any string code interpretation. If you disable the Backslash code display in the string constant AND enter "\n" you will get two bytes with the values 0x5C and 0x6E.

Rolf Kalbermatter 

Message Edited by rolfk on 08-27-2009 04:38 PM