How to convert "4 byte, 2's complement, Least significant byte first" number into a decimal number?

[muks]

your vi is missing. Wait your text is missing too

[rosh]

Here's the screenshot of the front panel and the block diagram. For some reason, i can't get he vi upoloaded.

http://www.thinksrs.com/downloads/PDFs/Manuals/RGAm.pdf

According to the user's manual (see the pdf), "The ion current is expressed in the usual format: 4 byte long, 2's complement integer in units of 10-16 A, with Least Significant Byte transmitted first."

[Norbert_B]

Please make a right click on the string indicator in the display array and select "Hex Display".

Thanks,

Norbert

[rosh]

Didn't realize it was that easy.

[JÞB · Accepted solution]

If you take a peak at my previous post there is a driver for that device.  The driver DOES have serious issues and probably should not be used as is.  If It was me, I'd use it to guide me in helping to interperate the poorly worded areas in the manual and redo it as a VISA Plug-n-Play (Project) style driver.  The cast to signed integer makes little sense   The manual and driver as shipped differ in implementation but try  the following

Do not enable the term character in the VISA session properties (the character used for termination is a valid value that will sometimes be seen in the data--a poor choice on the developers part)

Clear buffers

Send measurement request

read the number of characters expected in the response (4 per measurement)

Cast string read to array of U32 (don't bother reversing)  and don't use a signed integer-  It is impossible to get negative absolute pressure. (the universe really does not suck)

Multiply by 1e-16 to get a value in Amps- use the existing driver and maunal as guides on how to convert Amps to the the pressure unit you want. 

[rosh]

This seems to be working. Thanks Jeff and everyone else tried to help.

[crossrulz]

Do make sure you close down that VISA session after your loop.

[JÞB]

No problem.  Once you showed your front panel with the hex values it was a big clue that the values were returned in descending order of significance.  (these 0000's would almost have to be the high order bits right?).

The Handshaking flow control sould work better for read write end of message in this case anyway I can't imagine why they do a CR LF with flow control enabled.  But I've often given up trying to figure out what some firmware engineer was thinking.  Perhaps they all got trained in the 1950s and just keep using the same code over and over.

Now get some proper error handling on your functions and have fun with LabVIEW.  (Sub vi's in a driver should pass any incomming errors unchanged or debugging your vis gets "Painful")