41 minutes ago, Rozsda said:

I implemented the SOLTARO protocol.
Communicates on the SOLTARO CAN bus!

Would you share your code?

8 hours ago, pongo said:

So, my assumption that this is modbus was wrong.

yes , you are correct . I myself referred to this implementation before as being Modbus RTU compliant , which it is not . Its not unlike Modbus , actually only subtle differences, but different nonetheless.

 

8 hours ago, pongo said:

My conclusions are:  I cannot use modbus, I have to implement directly LIB serial protocol on my own.

Correct , I have implemented this protocol directly from the EASUN protocol document which is referred to elsewhere in the thread. For the record , the EASON document also actually does not claim it to be Modbus.

Just a random though, I had issues with asserting the read write pins on the 485 transciever. I would set it high to write my data then set it low after the serial.write.  Problem is that serial.write is non blocking and buffered so I was asserting the read write pin before all the data got out. one easy thing to do was a stream.flush() or Serial.flush() just to test. This is a blocking call and only returns once all the data is gone. I don't like blocking code so after that I implemented a buffer check to see if the buffer is empty before switching the transciever back to read mode. Even then it seems bits were still in flight so I still issue a flush but at least this way it keeps the blocking time to a minimum.

8 hours ago, Enrico Zanolin said:

Just a random though, I had issues with asserting the read write pins on the 485 transciever. I would set it high to write my data then set it low after the serial.write.  Problem is that serial.write is non blocking and buffered so I was asserting the read write pin before all the data got out. one easy thing to do was a stream.flush() or Serial.flush() just to test. This is a blocking call and only returns once all the data is gone. I don't like blocking code so after that I implemented a buffer check to see if the buffer is empty before switching the transciever back to read mode. Even then it seems bits were still in flight so I still issue a flush but at least this way it keeps the blocking time to a minimum.

A very simple hardware hack, if hardware mod is feasible, is to assert the control line when the TX line goes low.  

One transistor is used to do required level inversion.

5 hours ago, BritishRacingGreen said:

A very simple hardware hack, if hardware mod is feasible, is to assert the control line when the TX line goes low.  

One transistor is used to do required level inversion.

That's a great suggestion. I had toyed with that idea but stupidly worried about "what if you are sending a low bit, then the transceiver is not active" but upon reflection now, deactivating the transceiver would be equivalent to sending a low bit.

Thank you.