I think that in some ways what you described defines a close form of "canonical" modbus. We know that modbus uses PDU and A(P)DU with some info about function code and data blocks. We could simply update protocol logic to rely on these *without* relying on specific encoding. Then each driver flavor of modbus (rtu, ascii, tcp) would simply need to wrap and unwrap structures coming from an transport. Please have a look on stack configurer changes (currently stuck in can-stack-tunning feature branch): https://github.com/apache/plc4x/blob/2530287ec3982bb685700e76e956a0141ebc45cd/plc4j/drivers/canopen/src/main/java/org/apache/plc4x/java/canopen/CANOpenPlcDriver.java#L126L139 Changes which Sebastian helped me with in May this year will allow you to customize protocol instantiation. Effectively it opens a path to chain or wrap protocol logic needed by driver.
I believe that it is essential to keep protocol logic unified and encoding/decoding separated. If we will need to copy logic for each modbus flavor then very soon we will have more than 3 drivers only for that. Not that I am against of supporting all of them. I am just afraid that we might get into trouble making them consistent. Cheers, Łukasz On 15.08.2021 22:04, Ben Hutcheson wrote: > Just looking at implementing Modbus RTU and have a couple of options around > it's structure, that I wanted to get opinions on. > > The protocol uses two main data structures, an ADU and a PDU. The PDU is > the main part of modbus and has all the function codes and data included in > it. This is the same for modbus tcp and rtu. The ADU wraps the PDU to > provide additional data such as address and CRC fields. > > RTU is very similar to modbus TCP with only the ADU format changing that > wraps the PDU. As it is very similar it could be possible to reuse the > existing mspec with the addition of an RTU ADU. And then use this ADU in > the RTU protocol logic. > > The protocol logic I think is going to be different enough to warrant an > entirely new version as opposed to implementing switches in the current > logic, which I think could get confusing very quickly. It also has the > added benefit of allowing odd specs like Modbus RTU over TCP trivially. > > The protocol identifier I'm looking at using is modbus-rtu. I dislike it as > the original modbus tcp one is just modbus and not modbus-tcp. But figured > it's the better option. > > Ben >
