It looks like your string to write should be :010310000001EB
It would be really better if you used a modbus library. It takes care of the checksum for you. I'm attaching a VI snippet of the older library I generally use. I was able to get the string by digging into it deeper and seeing the end result of what is written out. (Newer modbus libraries seemed to be locked from getting into the more detailed subVI's.
Note that I made the constant for the address set for hex display radix. The manual says you are looking for 1000H address (seems like they've already dropped the 4 and made it a 0-based index. Actually, the only time I see an address with a 4 in front is if they are writing it in decimal. So holding register 1000H would show up as 404097 in other manuals.) If the address was listed in the manual as a decimal number, it would have been 4096 in a decimal display of that constant.
Make sure your device is in ASCII mode. But I would make it RTU mode and use that in my LabVIEW code as well. It is a little more efficient (half the bytes need to be transmitted) and mainly all of the devices I've worked with were set for RTU mode. The advantage of ASCII mode is that the strings being written and read when you drill down into the communication are all human readable.
Also be sure about your serial parameters. Page 24 of the manual you attached says :
"2. Non-supported formats: 7, N, 1 or 8, O, 2 or 8, E, 2."
I wonder if that is poorly written because I think it should be saying what formats are "supported."
I changed my program as you proposed. The error seems to be solved. I get different answers, which depend on the temperature of my process value. I do not know how to interpret them. The answers were for example:
:01030200C733 at temperature of circa 20,1 °C.
:01030200CD2D at temperature of circa 20,5°C
:01030200F505 at temperature of circa 24,5 °C
:0103020122D7 at temperature of circa 29°C
Can you explain me, if this is a correct answer respectively which bits give me the temperature?
I will also try a new Labviewprogram with your proposal shown on the png.
I tried some combinations...
Is it possible, that bit 10 und bit 11 stand for the temperature, but I have to divide them by 100?
Are the last two bits again a LRC Checksum? Is it normal, that they do not accord with the LRC of my input (EB).
To read data now works pretty well. Thanks a lot!!!
So far I write the input-string myself, which is permanently annoying.
Is there a function in Labview which calculates the LRC of a string? Or does someone has any idea how to program such a function?
The LRC of the command and the reply are each based on the contents of their respective commands or replies, so you wouldn't expect the two to match. The functions in LabVIEW for calculating the LRC are in the Modbus libraries that we keep suggesting you should use instead of doing it by hand. It's worthwhile to understand how the protocol works, but there's no need to start from scratch when good libraries are already available.
Do you recall the snippet of the documentation that you posted? It says about the value read from address 1000H: "Measuring unit is 0.1", meaning that the result is in tenths of a degree, so dividing the read value by 10 will give you the value in degrees. The read value is 16 bits, so it'll be four hex digits, not just two. In this case it's bytes 8 through 11. But again, there's no need to worry about these details if you use an existing library.
Don't typecast to double. You have a string of hex characters, you need to convert that string to an integer, then divide by 10.
You need to parse out 4 characters. For the last one, 0122 Read that as hex and that is 290.
The LRC calculations are done within the modbus library.
Here is the full program that would do it for you.