RTU Framer - server Multipoint rs485 line

[ArFe]

Hi,

I need to expand the functionality of the RTU framer and notice this warning
"Danger:: Current framerRTU does not support running the server on a multipoint rs485 line."

Can someone expand on that? What is the challenge on using it as a server in a multipoint line and is there any proposed solution?
I won't need this function for myself, as I'm using it just as a client, but I'm willing to help sort this issue out.

[janiversen]

The problem is identifying the packets. RTU framer do not have distinct prefix/suffix nor does it have a length field...the only detection is a pause of 3.5 chars between each packet.

[janiversen]

You can find several PRs trying to solve the issue as well as plenty of discussion not only with pymodbus but other projects as well.

[janiversen]

Please be aware that framers are not part of the API, and thus can change between releases without warning. Instead Pymodbus provide trace calls to allow modification of packets/pdus.

What is wrong with the current RTU framer ?

[ArFe]

Thank you Jan.

There's nothing wrong with the current RTU framer (apart from the limitation you mentioned above).
I need to expand it because there are some devices I'm working with that can have an unit ID of 2 bytes.

The way it works is starting with an "id" of 250, and then 2 bytes of actual id. Changes are simple, I'm just adding another framer on my fork. (dev...ArFe:pymodbus:dev). I'm ok with updating it if necessary (if you change how the framers work).

I love how this is separate from the PDU, so the changes are much simpler. I had to do the same for JS, and the changes were much more extensive and spread throughout the code.

On my question, I'm assuming that the best approach to solve the problem would be providing unit id to the framer, and then using info on function code and number of registers to determine the size of the frame. I don't have all the details figure out, but I could try something like that if you think it would worth it.

[janiversen]

It sounds to me that the easiest and most future proof solution is to add a trace function for the incoming/outgoing packets and convert the non standard packet to a standard packet.

This is a good example as to why pymodbus provided the possibility to trace and modify incoming/outgoing packets and pdus.

And to your question not all requests have a count or length some have variable size with no indication of the size. You need to study the modbus standard.

[ArFe]

Maybe I do have to study it more, because I could not find a function code other than "43 / 13 (0x2B / 0x0D) CANopen General Reference Request and Response PDU" that would not be possible to determine the size of the frame given the function code.

In any case, I was not aware of the trace calls. Thank you for pointing that out.
However, I does not seem to work in my case because the id is 2 bytes, and it is returned by the decode function, in between the trace_packet and trace_pdu. There is no trick I can do on the packet that would make the RTU framer to pick 2 bytes instead of one. Hence why I created my own encode/decode functions in a new Framer.

If you have a suggestion on how I would accomplish that with the trace functions, that would be great.

Thank you

[janiversen]

easy convert the 2 bytes to one byte e.g. using a map. A serial line with 100 devices is slow so 255 is a very theoretical limit for serial lines.

1 message that you cannot detect is all it takes to make a problem, but I think you missed the most obvious one, have you considered that a multiline is a mix of requests and responses. Requests and responses use the same function code, so it's quite interesting to detect (remember the client can resend the request and the device can make a late response, so there are no fix traffic pattern)

And not to forget the collisions on the line causing malicious messages, which happens quite often.

[ArFe]

Thank you Jan. This option could indeed work, but there are a couple of considerations on my project that make it hard to implement.

1. The ids are not know ahead of time and can change on the fly
2. The ids can be both single byte (using the regular RTU) and double bytes (using the updated scheme).

Further, it seems way more work and more complexity over the only benefit of not having to change it in case the internal decode/encode call changes...
For using the trace calls, I'd have to write my own encoder/decoder anyways, but then re-encode the message I just decoded to send it down to the RTU decoder.

Lastly, I agree with you that the big problem is knowing when/how to discard bytes (a response is something the server will not be interested anyways). So, if I would tackle this problem, that would be the angle I'd take it.

[janiversen]

If the ids are not known in advance your client will have a problem requesting data from the device.....anyhow it's your code.

Feel free to try to implement multidrop, you might have more luck than the rest of us.