Commuincating with Laser Caliper (Laser Online LST-25)

The Chinese brand LX-25 laser caliper has one RS485 serial port, and two synchronized ports. One synchronized port is connected to a programmer/display board, and the other to just a display board. Each display board shows in real-time the diameter (both x and y) of 3D printer filament passing through the laser.

I don't have any experience with MODBUS and wondering if anyone can recommend a Window's utility that will allow me to read the laser's real-time data.

What do I need to specifically define when trying to read data with the MODBUS RTU protocol?

Is the master the actual laser instrument, and the two display boards slaves? Would the laptop become a slave if trying to communicate over the RS485 serial port?

Thanks for any help you might be able to provide. It's greatly appreciated!
Just because there's an RS-485 port doesn't mean that the port supports the Modbus protocol. The laser caliper handles Modbus only if it says it does (uses the word Modbus) and has some supporting Modbus documentation.

If it does support Modbus, then it is highly likely that the laser caliper is a Modbus RTU slave. If the documentation has a Modbus register table or map, then it's a slave.

The display boards might or might not use the Modbus protocol to communicate; the display board protocol might be something else altogether. It doesn't really matter because if/when the caliper is a Modbus slave, it presumably has the X and Y data in Modbus registers that the Modbus master 'reads' by sending the appropriate command to which the slave will reply.

Your laptop would be the Modbus RTU master.

There are several generic Windows Modbus master applications that are used for testing that you can use to read a couple values, like Chipkin's CAS Modbus Scanner

If you want to continuously display the data or save it, that's the realm of HMI or data acquisition software that uses Modbus as the communications link.

To do anything, you'll need a USB/RS-485 converter (get one with the FTDI chipset for Windows compatability) And remember that it installs on a 'virtual' COM port reported in Windows's Device Manager under 'Ports'.

One of the unwritten Gotchas of RS-485 is that the labeling of the driver lines is not standardized. The labels are something like A/B or (+)/(-). The connection between master and slave is supposed to be (+) to (+), (-) to (-), but some vendors label the opposite of others. So when you're pulling hair out because "it just won't communicate", try swapping the A/B lines on one end.

Serial settings have to be identical on both ends. For testing purposes at 9600 or 19.2K baud with a short cable, you can probably skip the terminating resistors. Many field devices do not recognize serial port or slave address changes until the power is cycled off, then back on.

Documentation is normally obtuse, arcane, and vague.

It takes patience and persistence to work through the weirdness of Modbus. As I like to say, it's a project.
The great thing about standards is: There are so many to choose from.

And probably never moreso than with MODBUS.

Just about EVERY MODBUS application between two or more different manufacturers has some kind of unique differences (plural).

You're so right, David_2; virtually each and every application is it's own project. And about the only thing you can count on to be consistent is: No two problems will be the same for the first six years you are (fortunate enough to be) working on MODBUS applications. So if you don't have occasion to work on MODBUS applications very often, expect to have steep learning curves on just about every application.

Sorry, but that's the truth.

And the other truth is: Most MODBUS documentation is poor to extremely vague or just plain bad--as David_2 has also said.
Thanks so much for the reply. I greatly appreciate it! As for the laser supporting MODBUS, the manual does indicate that MODBUS RTU is supported. The laser has been configured for MODBUS RTU and no parity. set at 9600 baud rate.

The cable I'm using to connect my laptop to the laser's RS-485 serial port is a "DTECH USB to RS422 RS485 Serial Port Converter Adapter Cable with FTDI Chip". The length of the cable is 15 feet. I wonder at 9600 baud, the length is too long. I've tried the Chipkin MODBUS scanner and just can't seem to establish any communication between my laptop and the laser.

I will try reducing the length of the cable and see if that makes a difference. I will verify what pins are assigned to 485-A and 485-B.

As for the MODBUS RTU related data capturing, I'm having a difficult time understanding how to "talk" to the laser. The manual I have isn't very informative, but my guess is, someone who works with MODBUS and understands how it works, would be able to figure out easily.

Below is some information in the manual. Are you able to provide a layman's version? <b>It's a lot of info, so no worries if you can't.</b>

<b>MODBUS RTU communication format</b>
Asynchronous serial port is adopted for bus of controller and RS232/485 of remote controller. For communication, the master device on the bus of RS-485 firstly sends out order. When the communication order is sent to the instrument, the equipment meeting corresponding address code will receive the communication order. If there is no error, it will execute the corresponding task and send the execution result to the sender. The returned information includes: address code, function codes of execution action, the data and wrong check code (CRC) after execution action. If there is no error, it will not send any information.

<b>Initial and end structure</b>
Initial structure symbolizes the beginning of a data frame while the end structure symbolizes the ending of a data frame, generated by the sender of data frame. The method: reduce the bus of RS-485 to the transmission time with 3.5 bytes. All data bytes of a data frame should be sent continuously. If the interval with transmission time of 1.5 bytes emerges in certain data frame, it will be abandoned as invalid frame.
At receiving terminal, once the bus idle of 3.5-byte transmission time is detected, it assumes that a new data frame begins. However, during receiving data frame, once the bus idle of 3.5-byte transmission time is detected, it assumes that the data frame is received. If the bus idle of transmission time with byte larger than 1.5 and smaller than 3.5 during receiving the data frame is detected, the data frame will be abandoned as invalid frame. Then, the next initial structure will restart.

<b>Address code</b>
Address code is the first data byte in information frame sent by the communication every time. Standard Modbus RTU protocol supports slave address code 1-247. Allowable address code range of LST-XXJ outer diameter measuring instrument is 01-6F. It can be set through panel of instrument.

<b>Data area</b>
(1) 03 function (read holding register) data area of request frame includes four bytes: Byte 3: initial address of register (high byte) Byte 4: initial address of register (low byte) Byte 5: quantity of register (high byte) Byte 6: quantity of register (low byte) After request order is normally executed, the returned response frame data area includes 2N+1 bytes (N: quantity of register) Byte 3: number of bytes of follow-up data ( =2N) Byte 4~3+2N: N registers’ value (high byte comes first, followed by the low byte) (2)06 function (write single register) data area of request frame includes four bytes Byte 3: register address (high byte) Byte 4: register address (low byte) Byte 5: Register value to write (high byte) Byte 6: Register value to write (low byte) After the request order is normally executed, the returned response frame data area is completely the same with the request frame.

<b>Exceptional response frame</b>
If the abnormality occurs to the slave when executing request order, an exceptional response frame will be returned. Its structure is: START initial structure delay (transmission time with ≥3.5 bytes) ADDR address code 1 byte, the address of slave ES poor & error code 1 byte, = original function code +128 (decimal system) or +80h (hexadecimal) EC exception code 1 byte CRC error checkout 2 bytes (16 bits) END end structure delay (transmission time with ≥3.5 bytes) In which poor & error code=original function code = original function code +128 (decimal system) or +80h (hexadecimal). For example, for function request 03, its poor & error code= 83h (hexadecimal). The definition of exception code: 01= function code that is not supported; 02=wrong address of register; 03=data error; 04=execution failure

<b>CRC check</b>
Modbus RTU communication protocol, CRC is used to control transmission error. Sender calculate CRC codes including address code, function code and data area and sent them by attaching them to the data (CRC code contains two bytes. The low byte shall be firstly sent). The receiver shall recalculate CRC check code after receiving the data frame, and compare it with the received one. If equivalent, the data frame is valid. Conversely, if not equivalent, it assumes that the data frame is invalid. Calculation method of CRC: preset 1 16-bit register, and then calculate continuous 8 bytes in the message. Note: only 8 data bits in character participates in calculation of generated CRC. Start bit, stop bit and odd-even check bit don’t participate in calculation of CRC. During generation of CRC, every 8-bit character is different from the value in register, then move the result to the direction of LSB by one bit while MSB position is zeroed. Then, extract and check LSB: if LSB=1, conduct exclusive-or calculation of value in register with a fixed prevalue (binary system 1010 0000 0000 0001 or hexadecimal: A001h). If LSB=0, don’t conduct it. This process will be repeated until 8 times’ shift is executed (one byte). After last times’ (8th times) shift and related operations are completed, the next exclusive-or calculation of 8-bit byte with the current value of register will be implemented. Then, repeat it for 8 consecutive times like the abovementioned content. When bytes in message are calculated, the final value in register is obtained, namely CRC code. That is, the process of CRC generation is:

(1) Load 1 16-bit register into hexadecimal FFFFh (1), called CRC register.

(2) Conduct exclusive-or calculation of the first 8-bit byte of the message with low byte of 16-bit CRC register. The result shall be put into CRC register.

(3) Shift CRC register towards right (towards direction of LSB), MSB shall be zeroed. Extract and detect LSB.

(4) If LSB=0: repeat step (3) and begin shift for another times.
If LSB=1, conduct exclusive-or calculation of CRC register and constant value A001h (1010 0000 0000 0001)

(5) Repeat step 3 and 4, until 8th times’ shift is finished. By then, the operation of the byte is finished.

(6) Repeat step 2-5 for the next byte in message; continue the operation until all messages are processed.

(7) Final content in CRC register is CRC check code.
>just can't seem to establish any communication between my laptop
and the laser.

Don't feel bad. I hate serial connections. Welcome to the club, it happens to everyone.

1. Can you provide a link to the laser's manual?

2. Did you check the COM port for your converter in Device Manager? COM port is ____ ?

3. Have you ever used that converter before? Do you know that it actually works?

4. Is CAS set at 9600 baud rate? (Add Task > Add connection)

5. 15 feet of cable is short in the 422/485 world. Skip the termination resistors.

6. How did you set/configure a Modbus Slave ID on the laser?

7. Most of the Modbus stuff you posted was intended for someone coding a Modbus app, but was too truncated to be of value for that. It has almost nothing you need to know (what do you care how a Function Code 03 message is formatted? You don't. You do need to know how the data in register (4)xxxx is formatted.)

What's needed here is how the laser sets up its serial connections, how it assigns a Modbus Slave ID (many times slave 1, but it an be any number from 1 to 247), and which data you need to read - which is the slave register table/map.

8. Just for my own benefit, would you look up what the funny extended ASCII characters are in that Modbus Ya-da Ya-da (primarily in the data area)? characters that produced things like âÂÂ¥ or ïÅ or âÂÂ

<b>Moderator's Note:</b> Not sure if âÂÂ¥ and other characters in this line are what was meant. Sometimes special characters don't translate well in the UI.

I'm curious because it's a character conversion problem on the web in general, and I try to track those errors so I can figure out what the original intended character was.
Hey, did you get any further with the RS485 connection?
We have the same Laser Caliper and we want to talk with it. I tried several thinks but i was not succesful.
I only get a 0x20 0x00 as response from any message sent regardless of the slave address.

I found these two manuals:

They are not for the LST-25 but they have some information about the protocoll.
0x20 0x00 is not a valid Modbus message, but it is ASCII space NUL which sounds like a proprietary ASCII reply. The last page of the 75363 manual is an ASCII table.

The slave map on page 2, section 4.4 of the 97519 manual says that starting at register 0041 (hex, zero based; 66 decimal, one based) there are 6 registers each with a 16 bit data value.

If I poke the Chinese characters at the end of the first line, 读直径 with the word translate into Google, Google replies with 'Read Diameter', probably a reasonable value for a laser.

A row of characters is an RTU master polling message (FC is function code)

01 03 0041 0001 d41e
slave #1, FC 03 (read holding register) starting at register 0041 hex, read 1 register, CRC error check

01 03 0041 0002 941f
slave #1, Function Code 03 (read holding registers) starting at registger 0041 hex, read 2 registers, CRC error check

and so on, reading 3, 4, 5, or 6 registers at a time.

0106 0051 1770 d60f (the 4th paragraph, a single line) makes no sense because it attempts to read 1770 (hex; 6000 decimal) registers - which is impossible with standard Modbus, due to the Modbus standard limit on the number of registers transferred in a single message. They might have implemented a special function with some proprietary application they provide.

But it appears that the valid registers are overlapped somehow, with valid registers at
0041-0046 hex
0044-0049 hex
0051-0056 hex
0052-0057 hex
0058-005d hex
Sorry i made a mistake. The 0x20 0x00 are not a response of my messages. Those were some codes sent by my arduino which i use to look for the laser caliper. :(

So i got it a working connection. I had flipped the two RS485 wires :/ After reversing them i cycled through all possible slave id and the common baudrates.

At a baudrate of 19200 and a slave id of 3 i got a response :)

After that i cycled through the registers to find the measured diameter.

first diameter is stored in register 0x63 and the second measurment is stored in 0x64 and the average is stored at 0x61.

Here are the messages that i send:
SlaveID 2B, Func 2B, Addr 4B, CRC 2B

03 03 00 5F 00 01 B4 42

03 03 00 61 00 01 B4 42

03 03 00 62 00 01 D5 8E

03 03 00 63 00 01 74 4E

03 03 00 64 00 01 C5 8F

03 03 00 65 00 01 94 4F

03 03 00 66 00 01 64 4F

That's all i need. Thanks for your help! Have a nice weekend