hello, im new with modbus and rs485 but i have to implement this pH and EC sensor to my NORVI (esp32). i have tried using modbus but node.readHoldingRegister keep returning 227. do you have any reference code?

 

I have no idea what "node.readHoldingRegister" actually does but assuming that function reads Holding Register (4)0001, then a valid reply returning the value 227 would be interpreted as a pH of 2.27, as shown in the sample return message on page 7 of the manual, where for Register 0, the integer value is multiplied by 0.01 to provide a reading to two decimal places.

 

I have no idea what "node.readHoldingRegister" actually does but assuming that function reads Holding Register (4)0001, then a valid reply returning the value 227 would be interpreted as a pH of 2.27, as shown in the sample return message on page 7 of the manual, where for Register 0, the integer value is multiplied by 0.01 to provide a reading to two decimal places.

Hi, thankyou for your response. node.readHoldingRegister is supposed to return 0 for success reading but i keep getting 227. here is my full code

result = node.readHoldingRegisters(0x0000, 2);
if (result == node.ku8MBSuccess) {
float pH = node.getResponseBuffer(0); // Retrieve pH value from the buffer
Serial.print("pH Value: ");
Serial.println(pH);
} else {
Serial.print("Error reading pH: ");
Serial.println(result); // return 227
}
i dont think 227 is the value as i have tried changing the register address but all i got just 227.

 

Guessing you're using this library
https://github.com/craftmetrics/esp32-modbusmaster/tree/master/src

If so, a return code of 227 decimal (E3 hexadecimal) is defined as follows

static const uint8_t ku8MBInvalidCRC                 = 0xE3;

So you're getting an invalid CRC. This may be due to incorrect wiring or communication settings.

Make sure you're using 3 signals for your RS-485 wiring: +, -, and reference (e.g. ground, common, 0V). Also, if your equipment uses "A" and "B" labeling, you may need to swap your + and - wires, as there is no standard polarity among vendors for "A" and "B" labeling.

For configuration settings, make sure all devices are configured for the same baud rate and parity and that the slave address on the slave device matches what the master is targeting.

 

The return value 227 indicates a Modbus exception, typically due to incorrect addressing, communication parameters, or other configuration issues. Check the baud rate and slave address.

 

A wrong slave address will not generate a Modbus exception code, because if it did, every non-addressed slave on a multidrop bus would be replying with an exception code, because they would not be the addressee. Chaos.

A wrong polling address on a single slave bus will time out because the only slave on the bus has not been addressed properly and there's no slave at the polled address to reply.

 

hello, im new with modbus and rs485 but i have to implement this pH and EC sensor to my NORVI (esp32). i have tried using modbus but node.readHoldingRegister keep returning 227. do you have any reference code?

I have some good news and some bad news.
Good: Your PH transmitter is almost certainly responding correctly and your RS485 wiring is correct.
Bad: The ESP32 modbus master library is buggy and IMO not well written, though it is at least well commented.

The issue you are seeing is caused by the following if block starting at line 799 in the function ModbusMasterTransaction(), and specifically the condition in the if :

  // verify response is large enough to inspect further
  if (!u8MBStatus && u8ModbusADUSize >= 5)
  {
    // calculate CRC
    u16CRC = 0xFFFF;
    for (i = 0; i < (u8ModbusADUSize - 2); i++)
    {
      u16CRC = crc16_update(u16CRC, u8ModbusADU[i]);
    }
   
    // verify CRC
    if (!u8MBStatus && (lowByte(u16CRC) != u8ModbusADU[u8ModbusADUSize - 2] ||
      highByte(u16CRC) != u8ModbusADU[u8ModbusADUSize - 1]))
    {
      u8MBStatus = ku8MBInvalidCRC;
    }
  }

u8ModbusADUSize holds the number of bytes received from the slave, so this block is hard coded to always calculate the response frame CRC after 5 bytes have been received, which is just plain wrong. The position of the CRC is determined by the amount of data the slave device is sending back, and will never be in bytes 4 and 5 for a frame holding valid data (it would be in this position for an exception frame). This would have immediately failed the most basic of testing, if it had been done.

Fortunately this function does actually track the number of bytes it expects to receive so there may be a simple fix. Try replacing line 799 with the following. Note I have not tested this, I dont have the hardware, and I'm not going to spend time writing a test harness. If it works I suggest you feed this back to the author.

  // verify CRC if the entire response frame has been received, and no
  // other errors detected.
  if (!u8MBStatus && (u8BytesLeft == 0))