I am communicating to a micro controller successfully through RS485 (USB to RS485 adapter over windows COM port). I have written a small program using minimalmodbus to handle the modbus RTU communication and it works perfectly.
The micro controller that I am communicating with ALSO has TTL pins and the manufacturer has done something very strange. They add hex ('FF') x 3 before the response of the unit. As you can imagine this is causing me tons of headaches in trying to sort out how to handle the responses. I am modifying various sections of the minimalmodbus library (local development installed copy) trying to force it to accept the full answer and then strip the first three 'FF' hex characters to get the proper payload. So far I am unsuccessful. I think this manufacturer has done this in order to use the 3 x 'FF' as a timing mechanism and they provide a USB key that has this 'FF' filter available as an option. My program will work using this FF filter through this key. However I wish to use my own devices and minimalmodbus library so I am wondering how to strip these leading 'FF' characters. Anyone have any thoughts? @jonasberg
I am amidst trying to modify sections of a forked minimalmodbus library installed under pip3`` development. The best I have got so far is a response that is kinda strange but worth mentioning. I send a read_register ask of hex(225) and get back decimal value of 2500. Likewise if i do hex(220) i get back 2000 and sending hex(224) gives me 2400 as a response. I thought perhaps the device is echoing the asks so I am now trying options regarding the echo ignore feature in minimalmodbus with no success so far.
My code works fine when used properly so I don't think this will help in this situation. I really need to strip the leading three 'FF' (hex) values by modifying the minimalmodbus package.
I get various errors depending on what I have modified. the original error was a checksum error :
'Checksum error in {} mode: {!r} instead of {!r} . The response is: {!r} (plain response: {!r})'
I commented this section out of the minimalmodbus library as a start to trying to solve my problem. Obviously there is a better way to overcome this hopefully others have had this issue before.
Your question seems to me a bit convoluted so maybe I misunderstood what your device is doing.
To recap: your micro has two ports, on the RS485 everything works as expected but on another UART working with TTL levels you see three leading bytes 0xFF attached to all Modbus responses (you're querying with conventional Modbus though, so in the frames you're sending there are no leading 0xFF bytes).
So far so good I hope. Now, it's not clear to me what you want to do. Do you want to communicate with both ports using the same minimalmodbus library or what you want is just have two separate libraries one for each port.
The former would be somewhat more involved (you'd have to discriminate messages with a simple filter). The latter looks easier but I don't have any way to test it so consider it just a shot in the dark.
I would rather act directly on the part of the library that reads responses from the slave on the serial port (to avoid what you already experienced: having to recalculate CRCs).
This is what I would do: from the original minimalmodbus library change line 909 (under function _communicate) to read:
answer = self.serial.read(number_of_bytes_to_read)[3:]
If I misunderstood and this is not at all what you're after, write a comment and I'll eat my hat.