As per your suggestion, I had re-configure configuration, However my configuration is still faulty.
I am trying to read after many attempt it able to read after than it is again fail to read.
Note: I am using single function.
Yes, I am able to read data using Radzio Modbus & Modbus Poll modbus master simulator.
their communication’s configuration parameter also i had posted in forum.
This might be a bit far fetched but still worth a try. You have flow control defined in the windows software. Should you define it in the binding as well?
Could you try with different flow control settings? I am sorry but not too familiar what the alternatives actually mean in practice and what would correspond to the windows application…
Maybe it is not that far fetched. hitesh.patel didn’t mention what kind of RS485 converter is used. Nowadays one would use something like an ftdi chip (ft232 or similiar) + RS485 transceiver. The transmit enable signal for the RS485 transceiver is automatically generated by the ftdi chip and there is no need to take care of that in software. BUT some rather simple RS232 to RS485 converters just use the RTS line of the RS232 interface as a transmit enable signal for the RS485 transceiver. In that case you need to enable that in the software you are using - just like it’s done in the screenshot…
I don’t have any datasheet to share but i am using USB to Rs485 converter same as above.
I haven’t done any flow control in both software. It is default software’s configuration. If it necessary to configure, I will configure it and respond back.
How ever my understating of configuration require is as follows
modbus:serial.onoffcmdstat.connection=COM4:19200:8:even:1:rtu:500:3000:rts/cts in:rts/cts out
Working some suggests you don’t have anything fundamental wrong. Are you really sure you are using twisted pair for RS485 bus, really sure it is terminated properly?
He is reportedly able to poll data with OH as well, albeit with some communication errors. It’s something marginal - timing or line quality. Crappy wiring really does show up in this kind of way.
Sami will tell us, but I don’t think the binding currently reports CRC errors, which could be helpful in this situation.
EDIT - thinking on it, in this case noisy data incoming would be more likely to give parity errors at the serial level.
Outgoing noisy data would return a NACK or simply nothing/timeout, depending what the slave feels like. A NACK could itself get garbled of course,
The EOF exception in this thread means that the message could not be read fully, and the underlying serial library reported end-of-stream. Thus, the binding does not even check the CRC in this case…
How often does the read fail, and how often does it succeed?
