characters from VISA not in ascii

[fhs_dur]

I am using ARM Cortex Microcontroller. I am sending the numbers into lab view through usb port.

In such case, the strings obtained from VISA Read are not ascii but i can convert them into unsigned int with the help of string to uint premitive.

The numbers to be sent are continuous and they consist of u8, u16 and also float values.

So the problem here is the conversion. only those value which are defined as u8 are displayed correctly.

How do i convert into appropriate values.

E.g. if the value is integer but greater than 255 i should be able to read and display.

If the value is float i should be able to display the proper float number.

I also tried with scan string premitive, also string to number premitive. They can only read ascii and convert, but the characters i am converting are not ascii.

The characters i am receiving look like boxes and for a value of 0 they are empty space.

To convert a number into ASCII in my microcontroller could also be possible but the requirement here is with lab view. Microcontroller currently has huge load of programs.

I would be happy if someone whould help me in this.

Thanks in advance.

[johnsold]

Do you have some means of determining which bytes are U8, which are U16 and which are floating point (and are they Single, Double, or Extended)? Do you nkow the byte order for the multi-byte values?

You can use String to Byte Array and then Join Numbers to combine two U8 into one U16.  Type Cast and the various String to Number conversion functions can be used to convert to any of the LV numeric data types.

Lynn

[fhs_dur]

Yes i know the data because the data type are known.

E.g. if i have to sent three numbers that are as follows:

1, 300, 2.34.

Then when i convert the string output from VISA Read with string to uint8 premitive, i will get the following:

1, 45, 2.

So what i need is as the data 1, 300 and 2.34.

I tried string to uint8 premitive and also type cast (may be i was wrong) but once we use uint8, all data are converted to integers with maximum 255. If the data increases beyond 255 then it starts again from 1 (because of type uint8 ).

Hope to hear futher,

[johnsold]

What bytes are transmitted for 1, 300, 2.34. ?

Lynn

[Dennis_Knutson]

What is the exact name of the function you are calling the 'string to uint8' because there is no function of that name? I really think you need to post a VI with some actual data saved in the string. It's very unclear what you are receiving. For example, a numeric value of 300 would need multiple U8 bytes so I don't see how you are getting a value of 45. As mentioned before, you would typically need to use String to Byte Array, combine x number of bytes, and then do a typecast.

[fhs_dur]

Sorry for the mistake to write it is string to byte.

The necessary clippings are as below. The second clipping 'read buffer' is from a series of transformation where, first data is 300, second is 1 and third is 1.23. The output for these as seen in the third picture is 44, 1 and 1. Yes, 300-256 = 44, previously i wrote 45.

According to you, do you mean that the first two byte should correspond to 300 ? and also similar for the float (not only one byte value but with several values in consecutive elements of the array)?

I would be happy if similar clips would be avialable.

[GerdW · Accepted solution]

Hi fhs,

- "300" is stored in two bytes with LSB first: 44 + 1*256 = 300. As said before you could use "join numbers" to get the desired output.

- "1" is maybe stored in just one byte, but that's not clear from your picture.

- "1.23" is probably stored in 4 bytes (or 8?), but that's also not clear from your picture...

You have to show more data. And switch the string display to "hex display" before making the "clippings"!

[Dennis_Knutson]

Posting that image is next to worthless.Postin the actual VI with the read buffer indicator contents saved as default would allow someone to look at the actual data.

You are the one that understands the micro and yes, in order to represent a floating point number or something greater than 255, you would of course need multiple bytes. If your micro is not, then you are discarding the necessary information there.

[johnsold]

Change the "read buffer" display style to Hex Display.  Then run the VI and show us what is there.  That will tell us the actual hexadecimal values of the bytes received.  Also show all of the results for one data set, not just part.

Lynn