Modbus Siemens invt

[Mister_X_]

Buongiorno, volevo chiedere un consiglio riguardo la comunicazione modbus tra un plc siemens (1200/1500) e degli inverter INVT GD20.
Abitualmente per comandare gli inverter utilizzo bit di comando e riferimento di velocità in analogica, in questo periodo causa mancanza di materiale stavo valutando di comandarli attraverso il modbus integrato.
Ho già scritto una FB con l'aiuto di una guida e sono riuscito a gestire n.3 inverter senza nessun problema (scrivo velocità, comando l'inverter, leggo alcuni valori tipo corrente allarmi ecc) e sono anche abbastanza veloce.
Le mie applicazioni di solito prevedono dai 15 ai 30 inverter, la maggior parte di questi sono nastri quindi non ho bisogno di essere super performante per quanto riguarda la velocità dell comando però volevo capire se l'FB che ho fatto potesse andare bene.
Allego le foto del sw.
Il mio dubbio sta nella prima riga dove ho in contatore per incrementare la variabile che mi attiva la richiesta nelle MB_Master.
E poi sul fatto che se ho x slave dovrò avere x MB_Master per ogni variabile da leggere/scrivere e non mi sembra molto comoda sta cosa.
Avete qualche consiglio da darmi?
Su internet si trovano sempre e solo esempi con uno solo slave..

Grazie.

[ETR]

Ciao Mister X, io ho "discusso" un po' con un 1200 (di solito con GD20 e GD350, non uso Siemens) e ne ho messi in funzione una decina, ma con un piccolo accorgimento :  ho utilizzato un piccolo convertitore cinese da poco pi di 30 euro Modbus RTU-TCP e poi ho passato tutto sulla porta ethernet.

 

Questo, sia per costi, ma anche perché se c'è qualcosa di poco usufruibile con Siemens è il modbus (cosi come la scheda 485 on board) sia HW che SW. Quindi per eliminare problematiche di vario genere, ho uniformato la libreria solo su TCP e gestito tutto da li.

 

Abituato a far gestire il protocollo da liberie aperte, oppure dallo stesso SO del PLC, con Siemens non mi sono mai trovato bene, per cui ho sempre cercato di svicolare.

 

Buona serata, Ennio

 

 

[Mister_X_]

Grazie della risposta.

Perché il modbus Siemens e la scheda in board sono poco affidabili?

Sai darmi il codice del modulo e qualche info riguardo il codice da scrivere per comunicare?

[batta]

44 minuti fa, Mister_X_ ha scritto:

Perché il modbus Siemens e la scheda in board sono poco affidabili?

Si tratta solo di una personale idea di @ETR.
A livello di software, la gestione Modbus RTU e Modbus TCP è quasi identica.
La soluzione del convertitore per passare in Modbus TCP è comunque valida ma, se hai già acquistato il modulo di comunicazione Modbus-RTU, non so se ti convenga.
 

[Mister_X_]

Volevo solo capire se quello che avevo fatto era corretto o se c’erano idee migliori 

Cosa cambia come programmazione tra tcp e rtu su tia?

[batta]

4 ore fa, Mister_X_ ha scritto:

Volevo solo capire se quello che avevo fatto era corretto o se c’erano idee migliori 

 

Non credo possa funzionare.
Nella stessa scansione richiami MB_MASTER, tra l'altro sempre con lo stesso DB di istanza, cambiando solo il nodo di destinazione e l'area da scrivere. Ma non attendi che MB_MASTER abbia finito il suo lavoro.
Io gestirei un indice per cambiare inverter. Organizzerei tutti i dati degli inverter, compreso il nodo. in un array (meglio se ti crei un Tipo di Dati).
Quando MB_MASTER ha terminato il suo lavoro (done) incremento l'indice e, dopo un ciclo con REQ=FALSE, richiamo ancora sempre l'unico MB_MASTER, passando i parametri indicizzati.

 

Inoltre, in scrittura sarebbe buona norma scrivere solo se il parametro viene cambiato.

 

[Mister_X_]

1 hour ago, batta said:

Non credo possa funzionare.
Nella stessa scansione richiami MB_MASTER, tra l'altro sempre con lo stesso DB di istanza, cambiando solo il nodo di destinazione e l'area da scrivere. Ma non attendi che MB_MASTER abbia finito il suo lavoro.
Io gestirei un indice per cambiare inverter. Organizzerei tutti i dati degli inverter, compreso il nodo. in un array (meglio se ti crei un Tipo di Dati).
Quando MB_MASTER ha terminato il suo lavoro (done) incremento l'indice e, dopo un ciclo con REQ=FALSE, richiamo ancora sempre l'unico MB_MASTER, passando i parametri indicizzati.

 

Inoltre, in scrittura sarebbe buona norma scrivere solo se il parametro viene cambiato.

 

Grazie batta.

 

Allora per funzionare funziona, l’ho provato con 3 inverter slave e tutto è ok

Anche la guida che ho utilizzato ha usato ripetutamente lo stesso mb_master

Avevo provato a gestire il tutto diversamente ma l’mb_master richiede sempre un db dove leggere/scrivere i dati quindi mi ero un po’ complicato la vita e mi sono fermato

 

Avresti qualche documento/manuale/foto che mostri ciò che vorresti fare tu?

 

Grazie

[batta]

2 ore fa, Mister_X_ ha scritto:

Anche la guida che ho utilizzato ha usato ripetutamente lo stesso mb_master

 

Ma sempre con lo stesso DB di istanza? Controlla bene.
Per me, è una sorpresa che funzioni.

[Mister_X_]

45 minutes ago, batta said:

Ma sempre con lo stesso DB di istanza? Controlla bene.
Per me, è una sorpresa che funzioni.

Si sì, ma anche l’esempio (che è l’unico che ho trovato per gli INVT) è fatto cosi

Per funzionare funziona perfettamente, ho fatto tantissime prove, scrivo frequenza, marcia/arresto, leggo diversi parametri tranquillamente e in modo molto rapido 

4 hours ago, batta said:

Non credo possa funzionare.
Nella stessa scansione richiami MB_MASTER, tra l'altro sempre con lo stesso DB di istanza, cambiando solo il nodo di destinazione e l'area da scrivere. Ma non attendi che MB_MASTER abbia finito il suo lavoro.
Io gestirei un indice per cambiare inverter. Organizzerei tutti i dati degli inverter, compreso il nodo. in un array (meglio se ti crei un Tipo di Dati).
Quando MB_MASTER ha terminato il suo lavoro (done) incremento l'indice e, dopo un ciclo con REQ=FALSE, richiamo ancora sempre l'unico MB_MASTER, passando i parametri indicizzati.

 

Inoltre, in scrittura sarebbe buona norma scrivere solo se il parametro viene cambiato.

 

Come faccio se devo scrivere sempre e solo sullo stesso db?

 

[batta]

15 ore fa, Mister_X_ ha scritto:

Come faccio se devo scrivere sempre e solo sullo stesso db?

Come dicevo, organizzi i dati in un array, e alla funzione Modbus passi i dati dell'elemento dell'array, puntato da un indice.

 

Dunque, mi sono ripassato il Modbus RTU che non utilizzavo da tempo immemore.
È corretto richiamare MODBUS_MASTER sempre con la stessa istanza. Anzi , deve essere così, perché è l'istanza collegata a Modbus_Comm_Load.

 

Mi pare però sempre strano che funzioni richiamando più funzioni Modbus_Master contemporaneamente, senza attendere il DONE di quella precedente prima di richiamare la successiva.

 

Posteresti il link dell'esempio che hai trovato?

 

 

[Mister_X_]

https://plc247.com/siemens-s7-1200-modbus-rtu-invt-goodrive-20-vfd/

[batta]

Io, nell'esempio, vedo la comunicazione con un solo inverter.
Nello step0 scrive la frequenza, poi passa a step1 e scrive i comandi, poi passa a step2 e legge parametri.
Per l'avanzamento dei passi, viene controllato che Modbus_Master non sia occupato.
Ed è esattamente quello che fai tu, ma con una differenza: in ogni step, attivi Modbus_Master, simultaneamente, per fare le stesse operazioni su tutti gli inverter.
È questo che mi lascia molto perplesso. Trovo davvero molto strano che funzioni.

 

[Mister_X_]

Si è quello che ho fatto

Non so come faccia a funzionare, però va 😅

Ad ogni modo se dovessi implementare più inverter con la tecnica dell’esempio come si potrebbe fare?

[batta]

Seguendo sempre l'esempio dei tre passi (scrittura riferimento velocità, scrittura comandi, lettura parametri), prima di tutto abbandonerei l'uso del counter ed incrementerei una variabile (sempre detestato i counter, ma è una questione mia personale).

All'interno del passo della "scrittura riferimento", gestirei un indice e farei un solo richiamo a Modbus_Master passando i parametri indicizzati. Con il done, incremento l'indice e, quindi, scrivo i parametri del secondo inverter. Con il done della scrittura dell'ultimo inverter reinizializzo l'indice ed incremento lo step, per passare alla scrittura dei comandi. E si ripete lo stesso ciclo.

 

Purtroppo però, quando si gestiscono comunicazioni, finché tutto funziona come dovrebbe, è tutto bello e quasi semplice.
I problemi sorgono quando ci sono errori di comunicazione. Bisogna quindi gestire questi errori di comunicazione, e fare in modo che non rallentino la comunicazione con gli altri dispositivi.
Per esempio, al terzo tentativo fallito di comunicazione con un dispositivo, potresti escludere la comunicazione con quel dispositivo, e tentare nuovamente solo dopo un certo tempo o su richiesta dell'operatore.
Inoltre, sarebbe buona cosa effettuare le scritture solo quando il dato da scrivere viene modificato. Questo per due motivi. Il primo (non in ordine di importanza) è che le scritture inutili portano via tempo alla comunicazione. Il secondo, è che i parametri potrebbero essere scritti su una memoria non volatile del dispositivo. Ma le memorie non volatili hanno un limite del numero di scritture. Il limite è molto alto ma, se si contunua a scrivere ciclicamente, prima o poi si arriva a danneggiare questa memoria.

[ETR]

Il 25/5/2022 alle 09:25 , batta ha scritto:

Si tratta solo di una personale idea di @ETR.

Ciao Batta, senza polemiche, per carità con decine di migliaia di schede io non posso fare testo, ma l'avevo già scritto in un post che al primo INVT con un 1200 e la scheda 485 onboard, sarà quel che sarà, ma l'HW non ha mai funzionato (due schede su due), mentre tutti gli altri componenti del quadro, senza toccare nulla, hanno sempre comunicato con la qualunque scheda seriale (diverse marche, cinesate o no).

 

Altra sudata è stata riuscire quindi a capire dal blocco funzione, quali fossero i problemi, cosa che alla fine ha comportato per ridurre i tempi di svilupppo, il semplice espediente di passare in TCP e poi creare tutta la macchina a stati per gestire correttamente la comunicazione.

 

Se devo fare un paragone con altre case che mi permettono di avere il modbus TCP a disposizione come interfaccia (anche se non di sistema), secondo me è tanto guadagno (a cui aggiungo tutte le funzioni di debug ecc...).

 

Dopo di ché si può fare tutto, ma visto il sudure che si deve spendere sul Modbus in Siemens, conviene farlo solo per TCP e gestire con pochissimo la parte seriale sempre sul medesimo supporto.

 

Sistemati un po' i tempi di sincronizzazione della comunicazione, le cose poi funzionano cosi come ha fatto Mister X e tu hai spiegato.

 

Buona giornata, Ennio

[batta]

54 minuti fa, ETR ha scritto:

la scheda 485 onboard, sarà quel che sarà, ma l'HW non ha mai funzionato (due schede su due)

Io quella scheda non l'ho mai usata, ma mi pare davvero molto strano che due schede su due siano guaste. Altre schede che ho usato non mi hanno mai dato problemi.
Comunque, passare in Modbus TCP può essere una buona mossa, come avevo già detto. Ma non tanto per le differenze di sviluppo software, perché sviluppare una comunicazione in Modbus RTU o in Modbus TCP è quasi la stessa cosa. Cambia solo che non c'è Modbus_Comm_Load, e che si usano MB_Client o MB_Server al posto di Modbus_Master e Modbus_Slave.

[Mister_X_]

Ecco come faceva a funzionare

[ETR]

Il 26/5/2022 alle 16:03 , batta ha scritto:

Io quella scheda non l'ho mai usata, ma mi pare davvero molto strano che due schede su due siano guaste

 

Ciao Batta, guaste presumo proprio di no, ma avere di base il led del RX che si accende quando nemmeno trasmetti (nemmeno implementando la task modbus), facendo fatica a trovare info per la terminazione di linea, cercando di interpretare i codici di errore della funzione (che ti rimanda a probabili errori HW), alla fine mi sono arreso.

 

Per statistica avrebbe potuto anche essere la CPU, ma altrettanto difficilmente sarebbe stato averne riscontro da Siemens.

 

Purtroppo probabilmenet sono molto sfortunato, come mi ripetono spesso le assistenze 😉 

 

Buna giornata, Ennio