How to Connect Digital pH Meter with PLC?

Hello! We have an ATO digital pH meter ATO-PHCON-PH8, and we are working to connect it with our PLC. However, the pH meter is unresponsive despite trying different avenues to connect. Additionally, we checked the pH meter's circuit board, and its RS485 components seem insufficient. Could you tell me how to get the meter to communicate with our PLC?

Randolph wrote:
Hi! Please reply to my questions below.
1. Our digital pH meter supports Modbus-RTU communication. May I ask what model of PLC controller you are using? Does it also support Modbus-RTU communication?
2. After confirming that the wiring is correct, you need to set the baud rate, check digit (no check, odd check, even check), stop bit (1 bit, 2 bit), floating point format (4321, 3412, 2143, 1234) and local addresses of the pH meter. Please refer to the attached manual (P14, P17). The command for reading the pH value is 01 03 00 01 00 02.
3. You need to refer to the use cases of PLC for 485 communication to verify whether the communication is successful. You can also use the serial port debugging tools for verifying.

ATO wrote:
1. The PLC is an Automation Direct Productivity2000. This PLC supports Modbus RTU Communications and it is communicating with other Modbus RTU devices on the RS-485 bus.
We also attempted direct communication with a computer using an RS232 to RS485 converter proven to communicate with other Modbus RTU devices. The software used was MDBUS.
2. We confirmed the ATO controller settings for serial communication (9600 baud, 1 Stop bit, No parity, and various Slave Address settings).
The MDBUS software was used to confirm the command was per above (01 03 00 01 00 02 + 2xCRC Bytes).
We attempted to swap A+ & B- wiring to no avail.
We added terminating resistors to ensure signal quality (though the cable run was direct and only about 10 feet long).
We tied the signal grounds together to ensure a common ground potential.
No response was received from the controller during any of the various test scenarios above.
3. Please advise which serial port debugging tools you are referring to.

Ok, what are the Slave Address settings that the PH meter sets? Is this slave address the same as the address set in PLC communication? Will this address conflict with other devices on the 485 bus? Please confirm.

ATO wrote:
We tried various addresses - 1, 10 and 2 for the pH Meter. This was matched by our commands. No other Modbus devices were on the network, it was direct connected.

Please follow the steps below and use the serial tool to test:
1. First check whether the RS485 communication wiring is correct. You can swap the RS485 A+ and RS485 B- wires when testing.
2. Check again whether the parameter settings of the PLC and the PH meter are consistent: 9600 baud, 1 stop bit, no parity, local address 1, floating-point number format 3421 (corresponding to 32-bit floating-point numbers, high byte first, low byte last).
3. Install the serial debugging tool Commix software (attachment) on the computer, and then connect your computer with a USB to 485 communication cable. Open the Commix software, set the communication port parameters, and then send the command 01 03 00 01 00 02 and check if there is a return: 01 03 00 01 00 02 95 CB, and please send us a screenshot for confirmation.

ATO wrote:
I am using Modbus for software testing and monitoring. Here is a successful poll of a Modbus Slave address 1.
Serial port settings: 9600 Baud, No Parity, 1 Stop bit.

Here is an attempt to poll the ATO pH Controller. The same result is shown when swapping A & B wires:

There is no response. The Controller is configured as default 9600, No Parity, 1 Stop bit, Slave Address 1.

Randolph wrote:
Okay, we noticed an error in your command. Please send this command: 01 03 00 01 00 02 95 CB, and test again if the polling is successful.

ATO wrote:
I started receiving responses from the unit, but they appeared to be cut-off and not valid. I’ve since reduced the baud rate to 4800 and added parity (Even) to help avoid the bad responses. I seem to be getting consistent responses since making these changes.

Randolph wrote:
Ok, you can try to modify the communication parameters of the port and check if the RS485 communication can now read the value normally.