[specific model: S6-GR1P2K-M]
I’ve been attempting to extract data from the inverter using its RS485 interface, having purchased a “proper” plug. There seems to be an issue (at least one!) which I cannot find discussed so far, and I’m wondering whether the S6 has some quirk, or that I’m missing something.
Measuring the voltages on the “COM” connector of the inverter suggests that it is expecting signals with a +/- range of 3.3V; the A/B pins are about +/-1.6V with respect to the GND pin.
I’ve consulted the BA Coghlan document - from which I take it as a given that I should use 9600 baud 8N1 MODBUS RTU - and played around with transposing A and B.
I’m using Termite (with the Hex plugin) to send plain bytes, using an example from the Coghlan document (0x010480e8000c59fb).
I have a cheap 2-wire USB device from which I can get nothing in response from the inverter. Connecting my Picoscope (PC USB oscilloscope) and using its MODBUS decoder, I CAN decode a valid MODBUS message, although I have to set Termite to use “mark” parity and the Picoscope decoder set to “none” parity (I suspect the decode may be at fault). The USB stick is: https://kunkune.co.uk/shop/communication-boards/usb-to-rs485-485-converter-adapter-linux-mac-os/
I have a FT232R USB-Serial board (previously used with ATMega 328 home-brew projects) and a TTL-RS485 adapter (Ttl Turn To Rs485 Module Hardware Automatic Flow Control Module Serial Uart Level Mutual Conversion Power Supply Module 3.3v 5v - Integrated Circuits - AliExpress, which appears to be hardware other people have had success with). The FT232 board has a 3.3V/5V jumper which controls the signal levels and the voltage supplied to the RS485 adapter. With 5V selected, I receive loads of gibberish without sending any message. I assume this is noise over the quiescent state +/-1.6V on the A/B pins. With 3.3V selected I can get a response, but it is not valid, as it does not start “0x0104” or “0x0184”. My hunch is there is a framing error, with something weird happening with a different parity, stop-bit length, or baud rate in the response. The response is always the same; this is NOT noise! Unfortunately, I’ve not been able to decode the response with my Picoscope because noise causes false triggers and its grounding is not independent.
Anyone got any clues???