03-25-2023 11:06 AM - edited 03-25-2023 11:09 AM
The radix is hex, so these integers are entered/displayed in hexadecimal (see also). There are five cases, one for 0x1 and 0x11, one for 0x2 and 0x12, etc. and a default case for anything not mentioned.
Since I don't know how the received string looks like and no instrument documentation has been posted, I have no idea if these cases are even reasonable.
Since your question has nothing do do with the current discussion, I would recommend not to side-track this thread, but start a new one instead.
03-27-2023 10:08 AM
Thanks Mr. Altenbach for the explanation. I understood it now. For next time, I will make sure I start a new thread.
04-05-2023 10:33 AM
Hi thanks for the response and apologies for the slow reply. I spent a little bit more time studying the basics of LabVIEW before attempting to reply.
I have attached my current VI and the manufacturer manual for the RS 1384 Temperature data logger, as well as an image of my front panel.
Again I am quite new to LabVIEW and the process of getting data from instruments in general. I appreciate the input so far, and the patience going forward 😅
Lets ignore my initial question (I have increased my understanding of the program and used the index array function to analyse and and focus on just one of the channels of data).
However, looking at the "Temps" array indicator on the front panel. Notice that there are values in three of the array elements. Unfortunately, element 0 is showing the changing value of the thermocouple attached to channel 2. I would like to resolve this and be able to read all 4 of the channels. I assume the wrong bytes are being looked at, but I'm not sure where to change this.
How does the raw string look like?
I attached an indicator to the "read buffer" terminal of the visa READ, how ever it does not display a string. Do I need to manipulate this in some way?
Do you have documentation?
Attached
Are you sure the unflatten operation uses the correct datatypes?
To be honest, no.
*see below
I believe I have done this.
04-05-2023 10:49 AM
Please see my reply above, including down versioned VI to 2021.
04-05-2023 11:03 AM
Please go down to 2020 (also make sure that the VI has typical default data as received from the instrument).
(I can look at 2021 later on a different computer, but not now)
04-05-2023 07:40 PM
@JDSuper wrote:
How does the raw string look like?
I attached an indicator to the "read buffer" terminal of the visa READ, how ever it does not display a string. Do I need to manipulate this in some way
On your picture, it does display a string (mostly nonprintable characters, but that not important).
After you run your VI and see that data in the string, stop the VI and select the "read buffer" string indicator and go to "menu...edit...make selected values default". Save the VI under a new name and attach it again.
04-07-2023 03:30 AM
@altenbach wrote:
Please go down to 2020 (also make sure that the VI has typical default data as received from the instrument).
(I can look at 2021 later on a different computer, but not now)
Hi, I have reattached the VI saved in 2020 format, renamed after making the read buffer values default, but I am not sure how to include typical data.
Thanks,
04-07-2023 09:31 AM
Hi, I have reattached the VI saved in 2020 format, renamed after making the read buffer values default, but I am not sure how to include typical data.
Well, that Is typical data. At this point I can turn it into a control and do some testing:
Assuming this is good data, obviously we don't get reasonable results:
Obviously data=0 seems quite specific. If we treat it as I16, you would get T ~ -17.8. I really doubt it should be U16, because it needs to deal with negative values (Subtracting U16=32 from 0 gives you a gigantic number due to the magic of integer math).
A better idea would be to either read the data as I16 or at least subtract a DBL=32 as shown.
In a second step, you could accumulate an array of typical strings in a shift register, so we can test with varying data.
04-07-2023 09:41 AM - edited 04-07-2023 09:46 AM
OK, I noticed that you attached your manual, and it is quite clear:
You need to read eight bytes and the temperature is encoded in three bytes. The first two are the U16 integer value and the following byte encodes sign and decimals. Would be easy to implement.
Also note that if you mask off two bytes from the "status1", you no longer even need the case structure. (i.e. status1 AND 3 )
04-26-2023 09:48 AM
@altenbach wrote:
OK, I noticed that you attached your manual, and it is quite clear:
You need to read eight bytes and the temperature is encoded in three bytes. The first two are the U16 integer value and the following byte encodes sign and decimals. Would be easy to implement.
Also note that if you mask off two bytes from the "status1", you no longer even need the case structure. (i.e. status1 AND 3 )
Hi, thanks for the previous input. I am trying my best to learn rather than ask for the answers.... but..
I have managed to extract the integer and decimal values and display/calculate the correct temp according to the device display. But I am unsure of how to obtain/make use of the sign?
I have stripped the vi back to just focus on this component for now.