Rete RS485 estesa

Il 08/11/2025 10:43, Pier GSi ha scritto:

Cosa hai usato come driver per la rs485? Sono tutti uguali o c'e' un po' di una marca/modello un po' di altra marca/modello? Ma a spanne quanti sono sti errori in percentuale al trasmesso? Quanti dispositivi ci sono collegati in tutto nel bus rs485? Cavo unico e tanti brevi rami oppure topologia diversa? Terminazioni alle estremita'? O sono terminati anche i dispositivi lungo il cavo?

Scrivi 'meno escursione differenziale' ma parlando di V o mV di quanto stai parlando esattamente? Perche' se rientrano nelle specifiche dei chip usati come driver, non mi preoccuperei di quello

Il 08/11/2025 18:03, RobertoA ha scritto:

Quindi quelli vicini non hanno problemi? La distanza interbyte può essere un problema se chi ha scritto il firmware assume un timeout troppo breve(una volta avevo fatto questo errore) e non lo adatta alle varie velocità di comunicazione.

Nel Modbus,come saprai non puoi sapere a priori quanto sarà lungo il pacchetto, lo sai dopo qualche byte ,non è una regola credo,ma tipicamente con un microcontrollore non si analizzano i bytes man mano che arrivano (nulla lo vieta se c'è potenza per farlo e non ci sono altre priorità) ma si assume che quando per un certo tempo non arrivano più bytes il pacchetto sia finito e lo si analizza. Questo potrebbe portare a considerare finiti pacchetti ancora incompleti. Non ricordo se e quali siano le specifiche modbus per il tempo consentito tra un byte e l'altro. Sull'elettrico e livello floating dell'offset non ci ho mai capito,ma varia tra dispositivi master, o chip diversi o rete di resistenza diversa credo

Rispondo ad entrambi :

Un po' di tutto,

ST485, 7LB176, XR3082

Ci sono due casistiche, non sovrapposte, ma alternative in determinati periodi del giorno :

Ci sono una ventina di moduli, il cablaggio è molto esteso realizzato con cavo twistato schermato e corre spesso vicino alla linea elettrica, ci sono anche dei tratti a stella che non sarebbero proprio il massimo per le riflessioni, a quanto so

Ci sono delle R di terminazione da 120 ohm alle estremità e delle reti di bias sul master.

Dipende dal nodo che consideriamo, alcumi meno di 1V.

@blisca

Il timeout è sul pacchetto ricevuto (il master è un rasperry con un applicativo C#) ma viene calcolato in funzione della richiesta del master con un ampio margine, se chiedo 50 bytes il timeout sarà na roba del tipo 50*1mS, di preciso dovrei guardare perchè non ricordo. Tra l'altro, mi pare di avere una soglia di trigger dell'evento ricezione di decine di byte, ed ogni volta azzero il contatore del timeout...

Gli slave sono quasi tutti atmega16, atmega32, atmega324 abbastanza rapidi nel rispondere perchè la seriale è tutta gestita in interrupt, altri interrupt tipo su pin o altri timer a seconda del caso hanno codici velocissimi che impegnano per decine di cicli macchina e poi escono, il resto è dentro a dei task nel main loop.

Ciao! Pier.

Il /08 nov 2025/, *RobertoA* ha scritto:

Statistiche, oggi funziona perfettamente, boh.

STATO MACCHINA : ...POLLING...

mS POLL ROUTINE : 1130 RISPOSTE MANCATE O ERRORI DI VALIDAZIONE : 6 INTERROGAZIONI TOTALI : 36912 BYTES RICEVUTI : 18086880

"Pier GSi" ha scritto nel messaggio news:XnsB3916D0EFAD49magazzinopiercom@157.180.91.226...

immagino che nei singoli moduli, la parte con i transceiver 485 non sia isolata dal resto del circuito. fai una prova mettendo il GND dei transceiver a terra su tutti i moduli, se possibile.

Il 09/11/2025 13:23, Pier GSi ha scritto:

Il punto 2 fa pensare all'algoritomo bacato di attesa prima di entrare in trasmissione Se hai i sorgenti dei moduli slave magari rivedi la modalita' di entrata in trasmissione, puo' essere che entrino prima che il master abbia finito la trasmissione e quindi il master riceve solo la parte finale della risposta dei moduli

Venti moduli sono parecchi ma non abbastanza da giustificare problemi di natura elettrica

Se la differenza tensione e' compresa tra 200mV e qualche volt allora dovrebbe essere tutto ella norma

Anche questo sopra mi fa ipotizzare piu' un problema di logica trasmissione/ricezione che un problema elettrico

Si, diciamo che per i 19200 sono tutte cpu ben in grado di reagire rapidamente e quindi senza problemi lato velocita' di esecuzione del codice

Il /09 nov 2025/, *RobertoA* ha scritto:

Poco fa ha ripreso a notificare migliaia di errori ma forse ho risolto !! Caricando una modifica al FW del modulo più distante (quello rognoso) mi son casualmente accorto che aveva i fuses impostati con oscillatore RC interno 4 Mhz e non crystal (4 MHz sempre). Essendo in un box a temperatura esterna temo che da pieno sole a notte l'oscillatore RC abbia un drift importante il quale influenza ovviamente i tempi dell'usart...rimesso il FW precedente, scegliendo correttamente quarzo, sta funzionando correttamente.

Per gli errori multipli CRC potrebbe essere un bug, ma del rpi e non dei moduli, quando si trova a reiterare migliaia trasmissioni e scrive altrettante righe nei vari log magari capita qualcosa di inaspettato... memory leak? boh. Se ri-capita provo a rivedere il codice.

Ciao grazie.

Pier.

Il 08/11/2025 10:43, Pier GSi ha scritto:

Problemi simili si possono avere nella gestione del cambio direzione, soprattutto su OS completi come un Linux su una RPi.

Molto spesso la direzione viene gestita via sw alla fine della trasmissione dell'ultimo byte (proprio alla fine, quando i bit di stop sono stati trasmessi sul filo). Questo determina un jitter nel cambio di direzione da TX ad RX e se lo slave è troppo veloce a rispondere, potresti perdere il primo byte o interpretare male i dati.

Di quale MCU stai parlando?

Il /12 nov 2025/, *pozz* ha scritto:

Ciao, no, ho messo un micro che riceve-ritrasmette e si occupa di girare il transceiver.

ATMEGA16

Buona serata, Pier.

Il /08 nov 2025/, *Pier GSi* ha scritto:

Uhm, a distanza di qualche tempo faccio il punto della situazione :

Il /09 nov 2025/, *Pier GSi* ha scritto:

RISOLTO con il quarzo esterno

Ho scoperto essere correlato allo scrauso inverter ad onda sinusoidale

Stavolta ho aperto l'apparecchio, ed osservando il circuito interno è saltato all'occhio un condensatore da qualche nF, che credo proprio sia un filtro EMI, posto tra la massa della DC di ingresso, e la massa del bus HV a 400V.

Isolandolo il problema pare scomparso, mi chiedevo se lasciare cosi' o cercare piuttosto una soluzione alternativa. Pensandoci, se noi con l'inverter andiamo ad alimentare un'apparecchiatura con un SMPS dotato anch'esso di soluzione analoga, verosimilmente dovremmo creare un loop.

Gia che c'ero, visti gli IGBT da ben 60A, ho messo qualche R in paralello allo shunt che misura la I del ponte per ritardare l'intervento della protezione a mio avviso troppo conservativa :D

Saluti, Pier.

Il 24/11/2025 22:29, Pier GSi ha scritto:

Eh, ma non è detto che il micro gestisca la direzione in modo hw.

Appunto, non mi risulta che l'ATmega16 gestisca in hw la periferica. Immagino che, alla meglio, tu abbia un ISR che scatta alla *fine* della trasmissione dell'ultimo byte e in quell'ISR tu cambi direzione commutando un GPIO.

Questo determina un ritardo (interrupt latency) dallo stop-bit al cambio direzione che può essere più o meno piccolo (dipende per esempio se "scatta" un altro interrupt prima, chessò io un timer, il cui ISR ha una durata non trascurabile) e più o meno variabile (in funzione di quello che succede intorno a quell'istante, tipo appunto altri interrupt che si "infilano" prima).

Il 27/11/2025 22:44, Pier GSi ha scritto:

Quindi deduci che il baudrate della UART (di un ATmega16, giusto?) con oscillatore interno sia affetto da un errore troppo grande, soprattutto a certe temperature?

Mi sa che stai andando a 19200bps. Interessante che già a questa velocità non funzioni.

Quindi i due problemi erano completamente scorrelati?

Il /01 dic 2025/, *pozz* ha scritto:

No, infatti la gestisco io via SW, il micro è un ATMEGA324 mi pare (2 UART), a fine trasmissione un contatore SW ritarda di qualche centinaio di uS il passaggio da trasmissione a ricezione.

Si esatto, non vedo il problema però. Il master una volta ricevuto l'ultimo byte del pacchetto richiesto processa i dati e, dopo un ritardo dell'ordine dei millisecondi, impegna la linea ed inizia la trasmissione successiva. Se lo slave tiene impegnata la linea per qualche centinaio di uS è indifferente.

Ciao, Pier.

Il /01 dic 2025/, *pozz* ha scritto:

Si, a 19200.

..... cut....

Secondo me si, errore timeout da parte di un unico modulo può significare che non ha ricevuto il pacchetto di richiesta inviato dal master, o non è andata a buon fine la validazione perchè corrotto a causa del suo clock che drifta, e quindi il master non riceve risposta e notifica un erorre di timeout. Errori di validazione in maniera più o meno casuale su tutti i nodi è probabile originino da un disturbo che compromette gli stati logici dei bit che transitano sulla linea; avevo aperto un post tempo fa in merito, ora non ricordo di preciso ma mi pare fosse una spuria ricorrente con frequenza di 100 Hz che campionando con più canali avevo correlato nei dintorni di tempo in cui la sinusoide generata dall'inverter citato nel mex precedente passa per lo zero. Ciò coincide al momento di commutazione del ponte ad H dell'inverter che, a giudicare dalla presenza di un solo induttore di filtro sull'uscita, secondo me sintetizza la sinusoide modulando ad alta frequenza uno dei due lati del ponte e collegando alternativamente a gnd o +VBUS l'opposto (questi igbt switchano a 100Hz quindi).

Ciao, Pier.

Il 04/12/2025 11:28, Pier GSi ha scritto:

Ok, se il successivo trasmettitore sul bus (attenzione, non è detto che debba essere il master, potrebbe essere uno slave che risponde prestissimo ad un master lento a cambiare direzione) attende ms per impegnare il bus, allora dovresti essere a posto (sempre che il caso sfortunato di eventi che ti fanno ritardare il cambio di direzione non arrivi anch'esso ai ms, ma dovrebbe essere meno probabile).