G120C modbus in Multidrop

[Andrea Staffolani]

Salve,

 

Sono nuovo del forum e non so benissimo come funzioni ne se qualcuno ha già aperto una discussione su tale argomento, perciò mi scuso in anticipo per eventuali errori.

 

Un nostro cliente ci ha commissionato un progetto dove dobbiamo comandare 7 G120C tutti tramite modbus.

Tutti e 7 i G120 sono in serie collegati ad una schedina CM PTP su CPU 1510.

 

Se proviamo a comunicare 1 a 1 con gli azionamenti nessun problema.

Quando iniziamo ad includere più di 2 azionamenti in serie la comunicazione sembra non funzionare, la cosa strana è che sembra freezzarsi anche il DIsplay senza possibilità di premere nulla.

 

Abbiamo provato anche ad alzare la velocità di trasmissione a 38400 senza nessun risultato.

Sul display appare sempre l'errore F01910.

 

A qualcuno è già capitato un comportamento del genere? Cosa posso verificare? dove potrebbe essere il problema

Grazie in anticipo 

[max.riservo]

38 minuti fa, Andrea Staffolani ha scritto:

...Se proviamo a comunicare 1 a 1 con gli azionamenti nessun problema.

Quando iniziamo ad includere più di 2 azionamenti in serie la comunicazione sembra non funzionare, la cosa strana è che sembra freezzarsi anche il DIsplay senza possibilità di premere nulla...

Avete configurato per ogni inverter uno specifico indirizzo?

Avete considerato la resistenza di fine terminazione del bus RS485?

[leleviola]

2 ore fa, Andrea Staffolani ha scritto:

Se proviamo a comunicare 1 a 1 con gli azionamenti nessun problema.

Quando iniziamo ad includere più di 2 azionamenti in serie la comunicazione sembra non funzionare, la cosa strana è che sembra freezzarsi anche il DIsplay senza possibilità di premere nulla.

 

 

è una caratteristica intrinseca del Modbus, comunica con un solo dispositivo per volte, infatti dai l'indirizzo per comunicare con il dispositivo, se nel protocollo Modbus è accettato il comando di numero dispositivo Broadcoast allora puoi cominicare a tutti, in genere tale numero corrisponde a 255 cioè dispositivo 255, altrimenti identifichi uno per volta 1,2,3,....

[Andrea Staffolani]

1 ora fa, max.riservo ha scritto:

Avete configurato per ogni inverter uno specifico indirizzo?

Avete considerato la resistenza di fine terminazione del bus RS485?

Ciao Max, 

Intanto grazie per la risposta, ogni inverter ha un Indirizzo Modbus diverso che va da 1 a 7.

La resistenza di terminazione l'ho considerata sia quando provavo uno per uno gli inverter, sia quando ne proviamo 2 o più.

 

Fino a 2 inverter nessun problema, quando aggiungo il terzo escono i problemi descritti sopra.

[Andrea Staffolani]

Ciao leleviola ,

 

Grazie per la risposta.

Sono consapevole del funzionamento del modbus, infatti il ciclo è fatto in modo da interrogare un dispositivo per volta senza alzare due richieste allo stesso tempo.

Ogni inverter ha un Indirizzo univoco diverso dagli altri.

 

Cosa intendi per "se nel protocollo Modbus è accettato il comando di numero dispositivo Broadcoast allora puoi cominicare a tutti,"?

[Livio Orsini]

3 ore fa, Andrea Staffolani ha scritto:

Cosa intendi per "se nel protocollo Modbus è accettato il comando di numero dispositivo Broadcoast allora puoi cominicare a tutti,"?

 

C'è un partecipante "fantasma", solitamente con indirizzo 255. Se è attiva questa modalità quando il master invia un messaggio al dispositivo 255, questo messaggio viene accettato da tutti i partecipanti come messaggio proprio. E la modalità broadcast, in questo modo il master invia un comando o un messaggio a tutti gli slaves.

 

3 ore fa, Andrea Staffolani ha scritto:

Fino a 2 inverter nessun problema, quando aggiungo il terzo escono i problemi descritti sopra.

 

Hai verificato se i 2 inverters possono avere qualsiasi indirizzo? Se fosse così si tratta di un problema di eccessivo carico

[Andrea Staffolani]

20 minuti fa, Livio Orsini ha scritto:

 

C'è un partecipante "fantasma", solitamente con indirizzo 255. Se è attiva questa modalità quando il master invia un messaggio al dispositivo 255, questo messaggio viene accettato da tutti i partecipanti come messaggio proprio. E la modalità broadcast, in questo modo il master invia un comando o un messaggio a tutti gli slaves.

 

 

Hai verificato se i 2 inverters possono avere qualsiasi indirizzo? Se fosse così si tratta di un problema di eccessivo carico

Ciao, il problema sembra legato al Tempo di sorveglianza interfaccia del bus di campo [ms] (p2040) , alzandolo a 2000 ms sembra funzionare.

[batta]

Una cosa non ho capito. Scrivi nella sezione Siemens - S7-1500, quindi immagino che questo sia il PLC  tua disposizione.
Poi mi parli di inverter Siemens G120C.
Perché comunicare in Modbus, quando tutto il sistema è fatto per comunicare in Profinet?
Da dove viene questa voglia di farsi male?

Modificato: 8 aprile 2022 da Domenico Maschio

[Livio Orsini]

12 ore fa, Andrea Staffolani ha scritto:

alzandolo a 2000 ms sembra funzionare.

 

Allora il problema è che la comunicazione impiega troppo tempo; io controllerei la parte del software che deve eseguire la comunicazione. 2 secondi mi sembran troppi per 7 slaves

[Andrea Staffolani]

Il 8/4/2022 alle 19:20 , batta ha scritto:

Una cosa non ho capito. Scrivi nella sezione Siemens - S7-1500, quindi immagino che questo sia il PLC  tua disposizione.
Poi mi parli di inverter Siemens G120C.
Perché comunicare in Modbus, quando tutto il sistema è fatto per comunicare in Profinet?
Da dove viene questa voglia di farsi male?

Ciao Batta,

Sono completamente d'accordo con te, il problema è che il progetto ci è stato commissionato da un cliente che, pur di risparmiare su tutto, ha voluto riutilizzare questi G120C in modbus che aveva già a disposizione nonostante avessi fatto presente che con il profinet ci impiegavamo si e no mezz ora a farli funzionare.

Non sono così auto lesionista da andarmi a complicare la vita ma capisco il dubbio!

[Andrea Staffolani]

Il 9/4/2022 alle 06:24 , Livio Orsini ha scritto:

 

Allora il problema è che la comunicazione impiega troppo tempo; io controllerei la parte del software che deve eseguire la comunicazione. 2 secondi mi sembran troppi per 7 slaves

Ciao Livio,

Grazie per la risposta.

La parte che deve eseguire la comunicazione non fa altro che richiamare le funzioni Modbus della siemens come Com_Load e Modbus_master.

Visto che non possono essere interpellati tutti insieme per via del modbus ogni comunicazione viene eseguita solo quando ha terminato quella precedente in modo da non darsi fastidio.

Qualche suggerimento su cosa controllare? nel frattempo provo ad allegarvi l fb che fa la comunicazione.

 

[max.riservo]

Io cercherei di separare la parte HW da quella SW.

Quindi :

- test di comunicazione con un solo inverter collegato (da ripetersi per ogni inverter). Ovviamente ogni inverter è già correttamente configurato per la comunicazione (quindi indirizzo modbus univoco). Se tutti gli inverter, collegati singolarmente rispondono, si passa al punto successivo

- test di comunicazione di un solo inverter MA con tutti gli inverter collegati. Se funziona con il primo, si provano singolarmente tutti gli altri. Se non funziona con qualcuno occorre capire dove è l'intoppo HW (resistenza inizio bus, resistenza fine bus, eccessivo carico sul bus, altro da identificare magari con l'ausilio del manuale dell'inverter e del PLC) ...

- test di comunicazione finale : polling di un inverter per volta, ATTESA della risposta o del TIMEOUT della comunicazione, passaggio all'inverter successivo ...

[max.riservo]

Credo che tu abbia comunque seguito quanto consigliato da Mamma Siemens (per S1200) : g120c modbus rtu

Ovviamente parla di un solo inverter ...

 

P.S. - Io non uso Siemens quindi non posso darti dritte sulla parte SW, sicuramente altri sapranno suggeriti meglio cosa controllare lato PLC

Modificato: 11 aprile 2022 da max.riservo

[Andrea Staffolani]

53 minuti fa, max.riservo ha scritto:

Io cercherei di separare la parte HW da quella SW.

Quindi :

- test di comunicazione con un solo inverter collegato (da ripetersi per ogni inverter). Ovviamente ogni inverter è già correttamente configurato per la comunicazione (quindi indirizzo modbus univoco). Se tutti gli inverter, collegati singolarmente rispondono, si passa al punto successivo

- test di comunicazione di un solo inverter MA con tutti gli inverter collegati. Se funziona con il primo, si provano singolarmente tutti gli altri. Se non funziona con qualcuno occorre capire dove è l'intoppo HW (resistenza inizio bus, resistenza fine bus, eccessivo carico sul bus, altro da identificare magari con l'ausilio del manuale dell'inverter e del PLC) ...

- test di comunicazione finale : polling di un inverter per volta, ATTESA della risposta o del TIMEOUT della comunicazione, passaggio all'inverter successivo ...

Ciao Max,

 

Grazie della risposta.

Ogni punto da te segnalato è un punto con cui ho fatto i test.

-Test di comunicazione con un solo inverter ripetuto per ogni inverter e funzionano correttamente.

-Test con un solo inverter ma tutti collegati.

-test con due inverter ma tutti collegati, rispondono correttamente.

-Test con 3 inverter ma tutti collegati, iniziavano i problemi per cui abbiamo dovuto alzare il tempo del p2040.

-con p2040 a 2000ms tutti e 7 gli inverter funzionano ma dopo un pò di minuti vanno in fault nonostante non li stiamo comandando.

 

Il fault che viene fuori è sempre l'F1910.

Volevo provare ad allegare L'FB ma sembra che posso allegare solo immagini.

 

 

Sapete se è possibile mettere dei link per il download tipo da wetransfer? non vorrei violare regole del forum. 

[max.riservo]

Pur non conoscendo la terminologia usata da Siemens ma per analogia credo che tu debba agire su :

P2024 [0] : impostare un tempo tra 1000 e 5000 ms (io interpreto questo parametro come il timeout per il singolo indirizzo modbus)

P2024 [2] : impostare un tempo diverso da 0 (io metterei almeno 100 ms) - io interpreto questo parametro come il tempo di ritardo tra un messaggio e il successivo

P2040 : io lascerei i 10s di default - sinceramente non so se questo possa essere un ulteriore timeout

 

In P2029 dovresti avere i vari contatori degli errori ... prova ad indagare sulle possibili cause di errore

Modificato: 11 aprile 2022 da max.riservo

[Andrea Staffolani]

49 minuti fa, max.riservo ha scritto:

Pur non conoscendo la terminologia usata da Siemens ma per analogia credo che tu debba agire su :

P2024 [0] : impostare un tempo tra 1000 e 5000 ms (io interpreto questo parametro come il timeout per il singolo indirizzo modbus)

P2024 [2] : impostare un tempo diverso da 0 (io metterei almeno 100 ms) - io interpreto questo parametro come il tempo di ritardo tra un messaggio e il successivo

P2040 : io lascerei i 10s di default - sinceramente non so se questo possa essere un ulteriore timeout

 

In P2029 dovresti avere i vari contatori degli errori ... prova ad indagare sulle possibili cause di errore

Sono esattamente i parametri su cui proviamo ad agire, però, 

P2024[0] è impostato a 2000 ms.

P2024[2] non fa inserire 100 ms, da errore valore invalido

 

P2040 su un manuale mi dice che è in ms e di default 100 ms, su un altro manuale mi dice che è in secondi e di default ha 10s, a quale dovrei dare retta? 

 

P2029 invece, come andrebbe interpretato? 

 

Apprezzo molto l aiuto nonostante non lavori con il TIA.

[Andrea Staffolani]

1 ora fa, Andrea Staffolani ha scritto:

Sono esattamente i parametri su cui proviamo ad agire, però, 

P2024[0] è impostato a 2000 ms.

P2024[2] non fa inserire 100 ms, da errore valore invalido

 

P2040 su un manuale mi dice che è in ms e di default 100 ms, su un altro manuale mi dice che è in secondi e di default ha 10s, a quale dovrei dare retta? 

 

P2029 invece, come andrebbe interpretato? 

 

Apprezzo molto l aiuto nonostante non lavori con il TIA.

ULTERIORE AGGIORNAMENTO:

 

Il p2029[0] è l'unico ad assumere un valore diverso da 0, guardando il manuale viene fuori questo : number of error-free telegrams

 

Qualcuno mi saprebbe dire come interpretarlo? 

 

 

Sopra lo screen preso dal manuale per il p2029

 

[max.riservo]

Interessante ... Per me vuol dire che i messaggi modbus sono corretti (direi a livello di implementazione del protocollo - inteso come indirizzi modbus corretti, funzione modbus, word iniziale e n° di word richieste).

Probabilmente devi verificare che errore restituiscono le funzioni MB_Comm_Load e MB_Master. Entrambe hanno un bit di errore e un codice di errore. Attenzione che il bit di errore è attivo solo per un ciclo di programma (così recita il manuale).

 

A sensazione le casistiche sono 2 :

- invii richieste quando non sono ancora giunte risposte

- invii richieste con parametri errati (dal punto di vista del protocollo e quindi non ricevibili dall'inverter)

 

Sinceramente non saprei che altro dirti in quanto uso prevalentemente Schneider (PLC e Inverter) e come potrai ben immaginare i 2 ambienti sono 'leggermente' diversi

 

Nota secondaria (dal mondo Schneider) : per comandare gli inverter SCH tramite un bus di campo è tassativo che la comunicazione sia sempre operativa. Se l'inverter riscontra l'assenza di comunicazione (ovvero banalmente non riceve più il setpoint di frequenza anche se questo non cambia, l'inverter si blocca per errore di comunicazione). Ovviamente questo è valido quando l'inveter è configurato per prendere il riferimento di frequenza e/o di comando tramite bus di campo.

[Andrea Staffolani]

2 minuti fa, max.riservo ha scritto:

Interessante ... Per me vuol dire che i messaggi modbus sono corretti (direi a livello di implementazione del protocollo - inteso come indirizzi modbus corretti, funzione modbus, word iniziale e n° di word richieste).

Probabilmente devi verificare che errore restituiscono le funzioni MB_Comm_Load e MB_Master. Entrambe hanno un bit di errore e un codice di errore. Attenzione che il bit di errore è attivo solo per un ciclo di programma (così recita il manuale).

 

A sensazione le casistiche sono 2 :

- invii richieste quando non sono ancora giunte risposte

- invii richieste con parametri errati (dal punto di vista del protocollo e quindi non ricevibili dall'inverter)

 

Sinceramente non saprei che altro dirti in quanto uso prevalentemente Schneider (PLC e Inverter) e come potrai ben immaginare i 2 ambienti sono 'leggermente' diversi

 

Nota secondaria (dal mondo Schneider) : per comandare gli inverter SCH tramite un bus di campo è tassativo che la comunicazione sia sempre operativa. Se l'inverter riscontra l'assenza di comunicazione (ovvero banalmente non riceve più il setpoint di frequenza anche se questo non cambia, l'inverter si blocca per errore di comunicazione). Ovviamente questo è valido quando l'inveter è configurato per prendere il riferimento di frequenza e/o di comando tramite bus di campo.

Provo a farmi un "trace" degli errori che restituiscono le due funzioni, magari butto tutti gli status in un array giusto per fare questa verifica.

Mi sento di escludere il fatto che invio richieste quando non ho risposte, ho strutturato l'fb proprio per questo, ma verifico se ho fatto eventuali errori.

Il secondo caso idem, non faccio altro che leggere, inviare setpoint o aknowledge degli allarmi, ma in ogni caso verifico che le funzioni non siano ne in busy ne con richieste attive.

 

La nota secondaria invece è interessante, può capitare che io non debba interpellare uno dei nodi, semplicemente una volta impostato il setpoint potrebbe rimanere li fermo per secondi.

 

Il p2040 dovrebbe servire per questo scopo se non sbaglio, da uno dei diversi manuali in rete viene fuori quanto sotto:

 

In un altro di questi famosi manuali invece: 

 

Se ho capito bene mettendo il parametro a 0 questo controllo viene disattivato e l'inverter può rimanere senza "comunicazione" cioè senza leggere o scrivere.

 

Spero in qualcuno che conosca bene siemens e che non mi dica semplicemente che " abbiamo voglia di farci male" .

 

Ti ringrazio comunque davvero tanto per l'aiuto!

[max.riservo]

12 minuti fa, Andrea Staffolani ha scritto:

Il p2040 dovrebbe servire per questo scopo se non sbaglio, da uno dei diversi manuali in rete viene fuori quanto sotto:

 

In un altro di questi famosi manuali invece: 

 

Se ho capito bene mettendo il parametro a 0 questo controllo viene disattivato e l'inverter può rimanere senza "comunicazione" cioè senza leggere o scrivere.

Prova a disattivare il monitoraggio del bus di campo (p2040=0) ... se non altro elimini un'altra possibile fonte di problemi in questa fase di debug.

[Andrea Staffolani]

2 ore fa, max.riservo ha scritto:

Prova a disattivare il monitoraggio del bus di campo (p2040=0) ... se non altro elimini un'altra possibile fonte di problemi in questa fase di debug.

eliminando il monitoraggio vanno che è un amore....

[Livio Orsini]

Mettendo a zero il tempo di sorveglianza, risolveresti il problema degli errori in questa fase, però è pericoloso quando l'impianto lavora normalmente.

SI potrebbe trovare nella condizione, pericolosa, in cui uno slave non viene mai letto/scritto.

Non so come hai organizzato la tua comunicazione, quindi io faccio solo un'ipotesi di studio. Se, ad esempio, comunicassi con un solo slave ad ogni ciclo di programma, fissato il tempo massimo di ciclo in 50ms, con 7 slave dovrei impostare il tempo di sorveglianza a 400 ms; 7 * 50 = 350 ms + 50ms di margine.

[max.riservo]

31 minuti fa, Andrea Staffolani ha scritto:

eliminando il monitoraggio vanno che è un amore....

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?

[batta]

Ma come passi da un nodo al successivo? Solo a tempo oppure attendi il done?
I parametri in scrittura, li scrivi continuamente? Per velocizzare la comunicazione, sarebbe bene scrivere i parametri solo quando vengono modificati. Così facendo, in pratica dovresti solo leggere, mentre le scritture verrebbero fatte solo raramente.

[Andrea Staffolani]

18 ore fa, Livio Orsini ha scritto:

Mettendo a zero il tempo di sorveglianza, risolveresti il problema degli errori in questa fase, però è pericoloso quando l'impianto lavora normalmente.

SI potrebbe trovare nella condizione, pericolosa, in cui uno slave non viene mai letto/scritto.

Non so come hai organizzato la tua comunicazione, quindi io faccio solo un'ipotesi di studio. Se, ad esempio, comunicassi con un solo slave ad ogni ciclo di programma, fissato il tempo massimo di ciclo in 50ms, con 7 slave dovrei impostare il tempo di sorveglianza a 400 ms; 7 * 50 = 350 ms + 50ms di margine.

@Livio Orsini @batta Credo che la risposta a questa domanda valga per Batta.

 

Fino a ieri la comunicazione era organizzata in un FB richiamata dall'OB1 ( la gestione era comunque come descritto sotto), stamattina sto facendo dei test diversamente.

 

Ho organizzato la comunicazione su un OB di CycleInterrupt al momento a 20ms poichè a 100ms gli azionamenti sembrano impiegare troppo a rispondere, all'interno di questa OB viene eseguita prima di tutto la Master_COM_LOAD, una volta ricevuto il Done passo sequenzialmente ad leggere le status word di un azionamento per volta.

Uno per volta intendo che prima di passare ad esempio al Master 2, attendo il done del master 1.

 

In scrittura non scrivo continuamente, ma solo all'occorrenza.

Ad esempio se devo mandare un motore ad un certo setpoint, scrivo il registro, attendo il done, rileggo il registro per verificare che effettivamente il motore giri a quel setpoint.

Dopodiche se non devo fare altri cambi di setpoint non scrivo più.

 

Ora provo a riabilitare il tempo di sorveglianza e ne verifico il comportamente.

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?

Ciao Max, faccio la prova e ti aggiorno.