G120C modbus in Multidrop

[Andrea Staffolani]

17 ore fa, max.riservo ha scritto:

Quindi non è un problema HW.

Come detto da Livio dovresti riabilitare questo controllo andando a trovare il giusto valore oltre il quale avere l'errore.

Sinceramente non so come si possa calcolare questo valore in quanto il manuale non è particolarmente chiaro su cosa monitora e come la monitora.

Generalmente la comunicazione è asincrona rispetto al tempo di CPU (poi non so se tu usi un tempo di CPU fisso i.e. 50 ms oppure se un tempo variabile in funzione del tempo di esecuzione del pgm) quindi non so se si possa utilizzare come parametro di calcolo il tempo di esecuzione.

Io nel dubbio partirei con il calcolare il tempo di trasmissione/ricezione di un messaggio Modbus. Sapendo che indicativamente la lunghezza massima di un msg MDB si aggira sulle 120 Words : 120 words x 2 bytes x 10 bits (8 + start e parità) = 2400 bits posso ricavare la durata minima in ms rispetto alla velocità del bus.

Supponendo una velocità di 19200 bps (baudrate) ottengo 125 ms (2400/19200) quindi potrei ragionevolmente impostare un timeout di 200 ms.

Avendo 7 slaves con ciascuno un timeout di 200ms ottengo un tempo ciclo della comunicazione di 1400 ms.

Con questi dati a me sembrerebbe ragionevole impostare un watchdog del bus a 2000 ms ...

I miei calcoli si basano su presupposti che comunque andrebbero verificati. Banalmente io ho supposto che la comunicazione con lo slave sia di un singolo msg ma potrebbe essere di più messaggi ... quindi quanto scritto ma banalmente rivisto con quello che potrebbe (dovrebbe) essere scritto nei manuali.

 

P.S.

Mantenendo disattivato il controllo del bus ma spegnendo o scollegando un inverter tutto continua a funzionare?

Ovvero la comunicazione con i successivi inverter rimane in piedi?

giustamente, essendo collegati tutti in serie, scollegando uno quelli dopo non comunicano.

[max.riservo]

8 minuti fa, Andrea Staffolani ha scritto:

giustamente, essendo collegati tutti in serie, scollegando uno quelli dopo non comunicano.

Non proprio. Devi risolvere il problema della mancata comunicazione con uno (o più)  slave(s) a livello SW ...

Ovviamente l'assenza di uno (o più) slave(s) può determinare miriadi di blocchi a livello di SW (emergenza, allarme) ma non deve nel modo più assoluto (almeno secondo il mio approccio) bloccare la comunicazione con gli altri dispositivi.

[Livio Orsini]

3 minuti fa, max.riservo ha scritto:

Non proprio. Devi risolvere il problema della mancata comunicazione con uno (o più)  slave(s) a livello SW ...

Ovviamente l'assenza di uno (o più) slave(s) può determinare miriadi di blocchi a livello di SW (emergenza, allarme) ma non deve nel modo più assoluto (almeno secondo il mio approccio) bloccare la comunicazione con gli altri dispositivi.

 

Concordo.

l'assenza di uno slaves (mancata risposta) causerà un allarme che deve essere gestito, però la comunicazione tra master e gli altri slaves deve continuare senza problemi.

[Andrea Staffolani]

3 ore fa, Livio Orsini ha scritto:

 

Concordo.

l'assenza di uno slaves (mancata risposta) causerà un allarme che deve essere gestito, però la comunicazione tra master e gli altri slaves deve continuare senza problemi.

@max.riservo @Livio Orsini non ho capito una cosa, i cavi del modbus partono dalla schedina CMPTP e arrivano sui morsetti del primo azionamento, dagli stessi morsetti ripartiamo con il secondo e cosi via, vedi schema sotto

 

 

Per quanto ne so, spegnendo il primo azionamento o scollegando i morsetti, non riusciamo a raggiungere il secondo inverter per come è il cablaggio.

 

Sbaglio? 

[Andrea Staffolani]

20 minuti fa, Andrea Staffolani ha scritto:

@max.riservo @Livio Orsini non ho capito una cosa, i cavi del modbus partono dalla schedina CMPTP e arrivano sui morsetti del primo azionamento, dagli stessi morsetti ripartiamo con il secondo e cosi via, vedi schema sotto

 

 

Per quanto ne so, spegnendo il primo azionamento o scollegando i morsetti, non riusciamo a raggiungere il secondo inverter per come è il cablaggio.

 

Sbaglio? 

Niente, ragionando mi rispondo da solo.

Avete ragione, devo gestire il timeout di comunicazione per dare allarme e passare alla lettura del successivo.

[Livio Orsini]

In genere si calcola un tempo massimo in funzione della velocità di trasmissione e del numero di bytes richiesti. Trascorso il tempo limite senza risposta si da il tentativo fallito.

Dipende poi da come è organizzato il sistema, se ritentare subito o ritentare al giro successivo. In genere al terzo tentativo fallito si dichiara lo slave guasto e si da l'allarme.Se, invece, si tratta di dati particolarmente importanti si da l'allarme al primo fallimento.

[max.riservo]

1 ora fa, Andrea Staffolani ha scritto:

... devo gestire il timeout di comunicazione per dare allarme e passare alla lettura del successivo.

Appunto.

Altra cosa importante : fino a quando hai una lettura/scrittura OK oppure raggiungi il TimeOut NON puoi passare a leggere lo slave successivo.

Di fatto esegui la richiesta e fino a quando non hai il Done o  l'Err del blocco di comunicazione non prosegui con il successivo. Il Busy ti informa che la porta di comunicazione è occupata (e quindi NON puoi lanciare una richiesta di lettura/scrittura). Tendenzialmente il Busy dovrebbe restare attivo fino a che non arriva risposta dallo Slave o subentra il Timeout (sempre ispirandomi al mondo SCH).

[Livio Orsini]

Se si deve leggere il medesimo parametro da tutti gli slaves, ad esempio la velocità attuale, si può inviare un comando broadcast ed attendere le risposte degli slaves, in questo modo si velocizza la comunicazione.