Let the user decide which parity/stop bit configuration is used eg. even/odd parity and one stop bit or just two stop bits.
(like the async serial analyzer does)
[Admin Edit: Already Implemented]
Support extended 16-bit slave addresses
(Yes, it's not a de facto standard, but it's still widely used in bigger modbus networks. Also it should be easy to implement)
Admin EDIT: Idea - Need to decode both Master/Slave, RX/TX on the same line, to make the MODBUS analyzer useful.
klaas Jul 11, 2018
I agree to Mark Garrisson. If you are on RS-485, TX and RX are on the same wire. The slave has to reply to each master command. The current decoder will see the slave answer as a new master command and will decode rubbish.
Saleae's Modbus RTU decoding support on RS-485 thus is unusable: we need a new option that master and slave are intermixed.
Mark Garrison Jul 11, 2018
The analyzer should also support decoding master and slave messages from the same input, at the same time.
Currently the analyzer requires TX and RX signals to be recorded separately on different inputs before they reach a RS-485 transceiver.
This would allow the analyzer to decode all traffic on the bus by directly probing the bus.
Jamie Jul 11, 2018
I purchased the Saleae Logic because it was one of the few low cost analyses that supported the modbus protocol which is used in several of our products. Unfortunately not being able to set the parity/stop bit configuration make the current implementation practically useless.
As Lars suggests if the same settings as the async serial could be applied to the modbus protocol, it would make it infinitely more usable.
Guest Jun 7, 2019
I have to agree with Klaas and Mark Garrison.. The MODBUS analyser as it stands is next to useless.
The most common MODBUS you are likely to come across is RS485, with a differential signal, so the analyser making you pick RTU/Master or RTU/Slave is no good, it needs to actually make the decision itself based on the message, and to decode both at once as both will be on the same line.
While not the main focus of this ticket.. since the first item of this is done (you can already pick parity and stop bits in the 1.2.29 beta MODBUS decoder), could we substitute making it actually work for MODBUS as the main issue here?
I might get round to trying to fix it in the MODDBUS decoder once I have built a custom decoder for our protocol based on MODBUS (which i'm basing off the available MODBUS source)
Tim Reyes Jun 13, 2019
Thanks for sharing your requirements. The need for decoding both Master/Slave on a single channel seems to be universally agreed upon.
I have updated the original idea notes to include this.