How to Read Data from BLH Vishay Nobel Transmitter via Modbus ASCII by RS485 to USB Converter Connected to Laptop Windows 11?

I connected my laptop to BLH Vishay Nobel Transmitter by using RS485 to USB Converter cable. I tried using PUTTY software to read calibration data from BLH Vishay Nobel Weight Transmitter (Model LCP-100) Serial Ports via Modbus ASCII but nothing worked. There were many dark rectangular blocks appeared in the PUTTY software screen instead of any data.

I need help....Can someone please help to guide me. What and how or is there any method can I do in order to read data from BLH Vishay Nobel Transmitter via Modbus ASCII by RS485 to USB Converter Connected to Laptop (using Windows 11OS) ?????

Please help me.
 
I connected my laptop to BLH Vishay Nobel Transmitter by using RS485 to USB Converter cable. I tried using PUTTY software to read calibration data from BLH Vishay Nobel Weight Transmitter (Model LCP-100) Serial Ports via Modbus ASCII but nothing worked. There were many dark rectangular blocks appeared in the PUTTY software screen instead of any data.

I need help....Can someone please help to guide me. What and how or is there any method can I do in order to read data from BLH Vishay Nobel Transmitter via Modbus ASCII by RS485 to USB Converter Connected to Laptop (using Windows 11OS) ?????

Please help me.
I attached the manual from BLH Vishay Nobel Weight Transmitter (Model LCP-100) for your information.
 

Attachments

The protocol on the first couple pages is a proprietary ASCII protocol; it is NOT the Modbus ASCII protocol.

page 6-5 in section 6.2.3 states that Modbus RTU is documented in Section X (10). Note that on many devices, Modbus in any form might well be an option that has be purchased, it might not be a standard feature.

The attached pages seem to have instructions for the proprietary protocol.

The transmitter would be a Modbus RTU slave/server, so you could use a generic Windows Modbus Master/client to communicate with the device. The link to a freeware, open source RTU master/client is at this link:

https://github.com/sanny32/OpenModScan/releases/tag/1.6.1
 
The protocol on the first couple pages is a proprietary ASCII protocol; it is NOT the Modbus ASCII protocol.

page 6-5 in section 6.2.3 states that Modbus RTU is documented in Section X (10). Note that on many devices, Modbus in any form might well be an option that has be purchased, it might not be a standard feature.

The attached pages seem to have instructions for the proprietary protocol.

The transmitter would be a Modbus RTU slave/server, so you could use a generic Windows Modbus Master/client to communicate with the device. The link to a freeware, open source RTU master/client is at this link:

https://github.com/sanny32/OpenModScan/releases/tag/1.6.1
Thanks David_2 for reply. May I know whether the free software that you mentioned (OpenModScan app in the link provided) can be used to read data and retrieve parameter from our transmitter setting via Modbus RTU?

BLH Nobel vendor told me that our current BLH Nobel weight transmitters do not have the Modbus RTU and vendor advised us to use Hyperterminal to access the transmitters vis Modbus ASCII. If we want to use the Modbus RTU function, then we have to send back all our weight transmitters (which have around 80 pcs plus installed in the field) to factory to activate or install something like that.
 
So you've confirmed that the transmitters do not support Modbus RTU in their current configuration. If you installed Modbus RTU on the transmitters, then yes, the open source app would communicate with the transmitters.

But. There's a big But. Whether that open source app will be of any value to your company in terms of utilizing the data that Modbus handles is yet another aspect. Modbus is responsible for moving data words from one end to the other; Modbus is not responsible for doing anything with the data or making decisions based on data: start, stop, to slow down or speed up or to alarm, none of those or Modbus functions. Those are application functions that use Modbus to send the appropriate messages back and forth to accomplish the task. PLCs, HMI's, SCADA and customized software all use Modbus to communicate with field devices but all are tasked with "dealing" with the Modbus data.

Also, bear in mind that RS-485 networks generally max out at about 32 nodes for one 'network', if everything (wiring, shielding, grounding) is in good shape. So if you have 80 odd transmitters, then even with Modbus RTU, you're probaby looking at three separate RS-485 networks. There is also the issue of throughput, since Modbus is a poll/response protocol, Modbus communications is read station 1, wait for a reply, once the reply is received, poll station #2, wait for a reply, once the reply is received poll station #3, etc, etc, etc. Polling 30 odd transmitters might well take 6-10 seconds to get all the replies back. It depends in large part on who quickly the devices reply to the Master's poll.

I suspect your vendor has in incomplete understanding of communications protocols and is confusing "ASCII" communications, of which there literally tens of thousands of proprietary ASCII protocols, with a specific protocol, Modbus ASCII, because BLH Nobel does not have Modbus ASCII, they have proprietary ASCII.

In the absence of any Modbus protocol, using the transmitters as-is means engaging in the learning curve and doing the grunt work of using a serial program to figure out how to execute the needed communications using the ASCII protocol provided. Start on page 6.6 with a serial terminal program and get a response to the one or several of the command codes.

There are systems integrators in the automation field that can provide their services to provide turn-key software or systems that can customized to do what you're probably looking to do, beyond reading a cal zero value.
 
Top