Le notizie di CAN arrivano in ritardo

Ciao forum,

Ho un sistema di accumulo batterie Pylontech con un BMS. Leggo i dati del BMS tramite un Raspberry PI3b e un adattatore CAN. Finora funziona bene. Invio un segnale di watchdog ogni secondo e ricevo "una" risposta. Purtroppo, i valori correnti del BMS vengono visualizzati sempre con un ritardo. A cosa potrebbe essere dovuto?

Certo, ecco la traduzione:

"Rispondo con una citazione presa da un altro sito web."

Formato del messaggio:
La batteria principale invia 6 pacchetti di messaggi diversi. Ognuno di essi viene trasmesso tramite TCP e ha una lunghezza di 13 byte, ma nel complesso, e quindi nella maggior parte dei casi, si osservano buffer di 78 byte in arrivo. Gli altri buffer rilevati hanno una dimensione di 13 byte (un messaggio di risposta "heartbeat" dall'inverter) o valori intermedi, che in realtà sono solo porzioni di buffer incomplete o troncate all'inizio, quindi li ignoro.

Analisi del buffer:
Nel convertitore che utilizzo, ogni blocco di dati di 13 byte (un messaggio CAN di "lunghezza standard") è composto da un campo di lunghezza (1 byte), l'identificativo del frame CAN (2 byte, a partire dall'offset 3) e un pacchetto dati di 8 byte (a partire dall'offset 5). Ho bisogno solo dell'identificativo del frame e del pacchetto dati. Dopo di ciò, ogni tipo di frame viene decodificato per estrarre i campi dati.

L'ID 0x355 è il messaggio che contiene i caratteri SOH e SOC, in formato esadecimale a 2 byte. In genere, il carattere SOH (Start of Header) verrà visualizzato come 0x6400, un intero senza segno a 2 byte, in formato little-endian, mentre gli altri 2 byte rappresentano il carattere SOC (Start of Control). Si noti che in questo caso viene utilizzata solo metà del buffer dati CAN da 8 byte, un effetto collaterale dovuto al fatto che il convertitore inserisce messaggi CAN di lunghezza variabile in pacchetti TCP di lunghezza fissa.

In questo forum si discute principalmente del CAN classico, così come viene utilizzato nell'industria automobilistica. Oltre a queste, esistono molti altri ambiti di applicazione, come il SafetyCAN, il TT-CAN, ecc.

Sembra che tu abbia un sistema CAN configurato in modalità "triggered". Almeno, questo è quello che si legge in altri forum dedicati a Pylontech. Funziona in modo simile a un protocollo RS (con handshake, gestione centralizzata del bus, ecc.). È sicuramente una cosa interessante, ma temo che tu non troverai molto supporto in merito. Il tipo di protocollo è troppo specifico.

Ok, grazie per la risposta.