Tweet
Salve,
sto tentando di dialogare con il mio inverter ABB. Sono riuscito a leggere varie misure con un dongle USB che traduce da UART a RS485. Attualmente sto tentando di passare ad una maggiore integrazione dell'hardware, attraverso una RS485 Breakout board di cui il link di seguito:
RS-485 Breakout - BOB-09823 - SparkFun Electronics
Il chip in questione non gestisce autonomente il duplexing quindi ha un pin dedicato alla commutazione da trasmissione a ricezione. Dopo vari tentativi sono riuscito ad effettuare delle letture (Vgrid e Pout) commutando manualmente con un GPIO tale pin. In pseudocodice:
Ciò che osservo è che a volte la lettura ha successo mentre altre volte no. Apparentemente in molti casi di insuccesso il motivo è che quando vado a leggere il risultato sulla seriale, i bit che leggo sono shiftati in su o in giù di svariate posizioni e conseguentemente, il checksum fallisce diciamo 9 volte su 10.
Analizzando con un oscilloscopio le linee A-B vedo la richiesta e la risposta:
Quando la risposta è campionata correttamente sulla seriale, vedo le immagini che vi riporto sull'oscilloscopio, e la response (che si caratterizza da un fronte di segnale con ampiezza maggiore rispetto alla richiesta, sulla destra nelle immagini) che leggo è per esempio:
La response qui riportata ha il checksum corretto e il risultato è nel caso specifico una Vgrid di 242V (ed è uguale a quello che leggo sul display dell'inverter.. quindi non è decisamente un caso).
Nella maggioranza dei casi tuttavia i valori letti sono senza senso e il CRC fallisce.
Noto che la parte iniziale (000643) è invariata quando il reading è corretto e il checksum ha successo.
Noto anche che capita spesso di leggere 00000..643.. oppure 00..C86., ovvero valori corretti ma shiftati in su o in giù di N-bit posizioni.
Altre volte leggo semplicemente garbage (o per lo meno roba che non ha un pattern riconoscibile).
Una cosa importante che osservo è che il ritardo tra la fine della richiesta e l'inizio della risposta dall'inverter sulle linee A-B cambia di molto, e che quando ho successo nella lettura è sempre uguale e minimo, come nelle immagini riportate. Quando fallisco invece, la risposta può trovarsi anche più di una dozzina di divisioni (deltaT dell'oscilloscopio) ritardata rispetto alla richiesta: per capirci nelle immagini riportate, la finestra temporale potrebbe non catturare la response.
L'idea che mi son fatto è che l'inverter risponda a intervalli periodici regolari, quindi, quando io mando la richiesta di misura, lui la tenga in coda finchè non scatta il momento in cui è cadenzato l'eventuale invio di una risposta. Se la richiesta arriva proprio appena prima che tale intervallo scada, il risultato è che richiesta e risposta sono sufficientemente vicine da permettere di leggere il valore al momento in cui leggo la seriale. Se la richiesta è mandata troppo in anticipo rispetto a tale intervallo la lettura dalla seriale legge garbage.
Stranamente questo fenomeno era gestito perfettamente dal dongle USB (che credo usi un MAX232 qualcosa)..
Tenete presente che a inverter spento, se faccio una lettura leggo garbage.. quindi nono ho niente se non quella iniziale sequenza di 000643 ed il checksum finale, per determinare l'inizio della risposta..
Avete suggerimenti su come rilevare correttamente l'inizio della risposta ?
Grazie,
R
sto tentando di dialogare con il mio inverter ABB. Sono riuscito a leggere varie misure con un dongle USB che traduce da UART a RS485. Attualmente sto tentando di passare ad una maggiore integrazione dell'hardware, attraverso una RS485 Breakout board di cui il link di seguito:
RS-485 Breakout - BOB-09823 - SparkFun Electronics
Il chip in questione non gestisce autonomente il duplexing quindi ha un pin dedicato alla commutazione da trasmissione a ricezione. Dopo vari tentativi sono riuscito ad effettuare delle letture (Vgrid e Pout) commutando manualmente con un GPIO tale pin. In pseudocodice:
codice:
GPIO.SET(1)
SERIAL.WRITE(REQUEST, 10) //Len 10 as per (http://www.drhack.it/images/PDF/AuroraCommunicationProtocol_4_2.pdf)
SLEEP((10+2 /* GUARD */) * 8.0 / 19200) // keep the GPIO high for the time of the request to be sent
GPIO.SET(0)
WHILE (RES.len < 8)
RES+=SERIAL.READ()
//... checksum + decode...
Analizzando con un oscilloscopio le linee A-B vedo la richiesta e la risposta:
Quando la risposta è campionata correttamente sulla seriale, vedo le immagini che vi riporto sull'oscilloscopio, e la response (che si caratterizza da un fronte di segnale con ampiezza maggiore rispetto alla richiesta, sulla destra nelle immagini) che leggo è per esempio:
codice:
00064372ccea53e1
Nella maggioranza dei casi tuttavia i valori letti sono senza senso e il CRC fallisce.
Noto che la parte iniziale (000643) è invariata quando il reading è corretto e il checksum ha successo.
Noto anche che capita spesso di leggere 00000..643.. oppure 00..C86., ovvero valori corretti ma shiftati in su o in giù di N-bit posizioni.
Altre volte leggo semplicemente garbage (o per lo meno roba che non ha un pattern riconoscibile).
Una cosa importante che osservo è che il ritardo tra la fine della richiesta e l'inizio della risposta dall'inverter sulle linee A-B cambia di molto, e che quando ho successo nella lettura è sempre uguale e minimo, come nelle immagini riportate. Quando fallisco invece, la risposta può trovarsi anche più di una dozzina di divisioni (deltaT dell'oscilloscopio) ritardata rispetto alla richiesta: per capirci nelle immagini riportate, la finestra temporale potrebbe non catturare la response.
L'idea che mi son fatto è che l'inverter risponda a intervalli periodici regolari, quindi, quando io mando la richiesta di misura, lui la tenga in coda finchè non scatta il momento in cui è cadenzato l'eventuale invio di una risposta. Se la richiesta arriva proprio appena prima che tale intervallo scada, il risultato è che richiesta e risposta sono sufficientemente vicine da permettere di leggere il valore al momento in cui leggo la seriale. Se la richiesta è mandata troppo in anticipo rispetto a tale intervallo la lettura dalla seriale legge garbage.
Stranamente questo fenomeno era gestito perfettamente dal dongle USB (che credo usi un MAX232 qualcosa)..
Tenete presente che a inverter spento, se faccio una lettura leggo garbage.. quindi nono ho niente se non quella iniziale sequenza di 000643 ed il checksum finale, per determinare l'inizio della risposta..
Avete suggerimenti su come rilevare correttamente l'inizio della risposta ?
Grazie,
R
Commenta