12-06-2021 09:17 AM
Hi All,
I am new in LabVIEW.
Recently, I make program to read measurement result from Power Meter of VDI PM5B.
The equipment quite uniqe because the the results are in ASCII and binary.
The response from the PM5B has a six byte message format. Byte 1 is an ASCII character. Byte 2 can be an ASCII character or straight binary depending on Byte 1. Bytes 4 through 6 are straight binary. In the returned response, Bytes 2 and 3 together constitute the data in 16 bit integer format (short integer). These two bytes should be unpacked as a 16-bit integer. In addition, these are 16-bit 2's complement numbers, which will need to be converted from 16 bit 2's complement to decimal.
How to convert the 16 bit 2's complement to decimal?
I attach my program. it is not work well, because the result is diference with the reading of the power meter.
I also attach the explanation from the manual.
Hopefully, you can help me.
Thank you.
Solved! Go to Solution.
12-06-2021 02:03 PM - edited 12-06-2021 02:05 PM
Hi kurnwin,
when you want to parse 6 bytes/chars then you should do that:
Maybe you need to insert a "ToI16" conversion after the JoinNumbers function, I'm not quite clear on all those "2's complement numbers"…
(There exists a lot of other ways to do that conversion from string to numeric values, like UnflattenFromString…)
12-07-2021 02:47 AM
Dear GerdW,
Thank you for your reply.
I see the picture of your program. Would you like to give me the VI version of the program?
Or maybe you can mention the name all drivers in the program that you have made.
I try to edit my program based on your suggestion, but I do not know the name of each function/driver.
Thank you.
Best regards,
Windi
12-07-2021 03:18 AM
12-07-2021 09:19 AM
Hi GerdW,
I laready found all the drivers. Howerver, the measurement result in labview is still different with power meter display (the right one).
Only byte 3 are continuously change from the measurement. Sometime byte 4 is changed. The others byte did not change.
Here, I attach the front panel result and the program.
The dislay in labview is -0.0401638, Hower the right reading id power meter' display is -0.3438. The both display should be same.
Thank you.
Best regards,
Windi
12-07-2021 12:29 PM
Hi kurnwin,
@kurnwin9 wrote:
The dislay in labview is -0.0401638, Hower the right reading id power meter' display is -0.3438. The both display should be same.
A value of -0.3438 is not possible with your current conversion formula!
0.3438*59576/0.2~=102411
This value would be out of range for an I16 value…
Please check your formula!
Which measurement range do you use? Which factor does apply for that range? Please doublecheck each setting!
12-08-2021 03:21 AM
Hi GerdW,
Do you mean the value is out of range of I16 because the formula is wrong?
I think the formula aready right. I use the measurement range 4. So the multiplier is 200.E-3 (0.2), and I did not use the calibration factor or it is 0.
The formula in the manual is:
reading = countvalue*2.*rangemax(rangeval)/59576.
It is stated that Bytes 2 and 3 together constitute the data in 16 bit integer format (short integer). However Byte 2 never change.
Best regards,
Windi
12-08-2021 05:35 AM - edited 12-08-2021 05:50 AM
@kurnwin9 wrote:
It is stated that Bytes 2 and 3 together constitute the data in 16 bit integer format (short integer). However Byte 2 never change.
That's because something is fishy. According to the document the first byte should be a 'D'. This is ASCII code 68 (or 0x44). That seems to be your byte 2. So one possible explanation:
Your response protocol is in fact more complex and you failed to post that section of the specification. It may contain an extra character in front of the message. 06 as ASCII code is very unusual as it corresponds to the <ACK> command, but hey your data portion seems to consist of 6 bytes. Could it be that that is not coincidental?
Since you fail to show the entire string that is received currently, we can not really tell you what is the proper configuration.
Either there is also a character 13 at the end of the received string, then you should use the VISA Configure Serial Port and change the termination character to character 0xD in hexadecimal or 13 in decimal.
If there is a value 10 at the end of the message (would be strange considering you send a 13 at the end of your command), you would also use the VISA Configure Serial Port and leave its termination character settings.
If there is no 13 or 10 at the end of the received byte stream you should also use VISA Configure Serial Port but disable the termination character handling and then first read one byte and treat it as the number of bytes that you need to read.
All this is highly speculative though and based on the data observed in your front panel and the lack of any further detailed documentation of the full protocol frames.
12-08-2021 05:46 AM - edited 12-08-2021 06:06 AM
Hi Rolf,
Yes, you are right. There is a different between the explanation in manual with the fact.
The respond from the power meter: Byte 1 is always 6 <ACK>, and byte 2 is always 68 (D).
Every send a command to the power meter, it should be terminatied with a carriage return (x0d) as expalined in the manual.
There is not character 13 at the end of the received string.
I attch the reading in string.
Therefore, I confuse which are of the bytes that contains 16 bit integer format for the reading of power meter.
Best regrads,
Windi
12-08-2021 01:29 PM
Hi kurnwin,
@kurnwin9 wrote:
The respond from the power meter: Byte 1 is always 6 <ACK>, and byte 2 is always 68 (D).
…Therefore, I confuse which are of the bytes that contains 16 bit integer format for the reading of power meter.
Then you should try to use Byte 3&4…
With the values from your last image you get:
3*256+174 = 942
942 * 2.0 * 0.2 / 59576 = 0.00632469
Does that make sense to you?