Domande S7 1200 e "ciclo" Profinet

[RyanKunzle]

Ciao a tutti, avrei da porre qualche domanda sull'interazione fra Profinet e un PLC S7 1200.

 

La mia configurazione:

• CPU 1212FC
• IM 155-6 PN ST (DI 8x | DI 8x | DQ 8x)
• TP1200 Comfort
• G120C PN #1
• G120C PN #2
• G120C PN #3
• G120C PN #4
• V90 PN #1
• V90 PN #2
• V90 PN #3

 

Ogni dispositivo è connesso via Profinet, i 4 G120C sono connessi pure via Profisafe.
I 3 servo V90 sono configurati come Assi sotto Oggetto Tecnologico
Tutto il programma cicla in OB1 senza OB di interrupt.
In ciclo PLC si aggira intorno ai 60/70 ms con picchi di 80ms.

 

Cose che ho osservato:

2 dei 4 G120C sono ad inizio linea e si occupano dell'inserimento prodotto, per evitare che tutta la linea sbagli i posizionamento devono essere precisi. La fermata dei loro motori è fatta in modo semplice, una fotocellula dice quando i motori devono fermarsi.

 

Se non mi sbaglio se il motore sta girando e facendo andare la linea ad una velocità di 1000 mm/s e il ciclo PLC è di circa 60 ms significa che quando il motore si ferma potrei avere un errore di minimo: 0.06 [s] * 1000 [mm/s] = 60 [mm].

Quindi se in più routine di produzione il mio prodotto si deve fermare sempre nello stesso punto potrei avere delle variazioni nella posizione di 60 mm ad ogni fermata. Se invece di andare a 1000 mm/s andassi a 100 mm/s l'errore in fermata dovrebbe ridursi di 10 volte tanto, passando da 60 mm a 6 mm. 

 

L'esempio fatto è una iperbole rispetto al problema che sto avendo ed è solo per illustrare il ragionamento ed il calcolo fatto, ed in tutti i casi ho cercato di ridurre quanto più la velocità per ridurre l'errore in ingresso.

 

Il problema è che non importa di quanto io riduca la velocità dei due G120C in ingresso, mi trovo sempre lo stesso errore in fermata.

 

Domande:

• L'unica cosa che mi resta da pensare è che sia il profinet che essendo troppo "carico" ci mette una vita a comunicare fra PLC e i drive, essendo una CPU 1200 ed essendo senza Profinet RT/IRT ci potrebbe mettere tanto a passare i telegrammi.
• C'è un modo per monitorare il tempo che ci impiega il Profinet a passare i telegrammi?
• Qual è il tempo massimo di comunicazione Profinet?
• E' possibile che il profisafe carichi la comunicazione Profinet tanto da incidere sul PLC?
• Teoricamente se potessi apportare i seguenti cambiamenti al progetto secondo voi noterei dei visibili cambiamenti positivi?
  • Modificare i 3 assi e rimuoverli come oggetti tecnologici per fare il controllo in posizione/jog internamente al drive comandandolo tramite telegramma libero e librerie SinaPos etc...
  • Rimuovere il Profisave totalmente e cablare i segnali di STO sui drive G120C.
  • Modificare in programma PLC e inserire i calcoli più intensi in SCL sotto blocchi temporizzati a 100ms/500ms.
  • Spostare il controllo assi V90 e G120C sotto OB ad interrupt.
• Oppure sarebbe soltanto meglio cambiare PLC e puntare a qualcosa di più alta gamma come un S7 1500 con capacità Profinet RT/IRT?

 

Grazie mille a chiunque mi volesse rispondere.

Ryan

Modificato: 5 settembre 2023 da RyanKunzle

[drn5]

Non sapendo esattamente cosa c'è dentro il plc, ma vedendo 80 ms di ciclo per quello che dici di voler fare, direi che un 1500 sarebbe più che giustificato.

Poi, detta male, se l'errore è sempre lo stesso perchè non anticiparlo?

Usare gli OB a tempo ti garantirebbe una costanza sui cicli primari, ma scrivere in SCL o in STL non credo faccia la "differenza". Perchè adesso come è scritto?

 

[pigroplc]

Trovare la soluzione di questa situazione così su 2 piedi richiede la sfera di cristallo, per cui io proverei a spostare gli ingressi delle FTC dalla periferia al cestello centrale, così per capire se eventuali ritardi di Profinet ritardano l'acquisizione. Seconda prova: far ciclare solamente l'interfaccia dei G120 e le funzioni che servono in un programma temporaneo ed effettuare le prove 

PS

hai scelto proprio una CPU misera misera, ad oggi 60-70 msec sono proprio tantini da vedere in un applicazione.

 

 

[RyanKunzle]

On 9/5/2023 at 10:32 PM, pigroplc said:

Trovare la soluzione di questa situazione così su 2 piedi richiede la sfera di cristallo, per cui io proverei a spostare gli ingressi delle FTC dalla periferia al cestello centrale, così per capire se eventuali ritardi di Profinet ritardano l'acquisizione. Seconda prova: far ciclare solamente l'interfaccia dei G120 e le funzioni che servono in un programma temporaneo ed effettuare le prove 

PS

hai scelto proprio una CPU misera misera, ad oggi 60-70 msec sono proprio tantini da vedere in un applicazione.

 

 

 

Potrei tenere in considerazione spostare le FTC dalla periferia al PLC, indubbiamente.

Per quanto riguarda il modificare il programma per tenere l'"essenziale" il programma è già ridotto all'osso, non avrei molto da assopire per le prove!

 

Invece per la CPU purtroppo la scelta non è stata mia, fosse stato per me sarei andato subito su una CPU 1500 😁

 

Grazie per la risposta!

[RyanKunzle]

On 9/5/2023 at 10:23 PM, drn5 said:

Non sapendo esattamente cosa c'è dentro il plc, ma vedendo 80 ms di ciclo per quello che dici di voler fare, direi che un 1500 sarebbe più che giustificato.

Poi, detta male, se l'errore è sempre lo stesso perchè non anticiparlo?

Usare gli OB a tempo ti garantirebbe una costanza sui cicli primari, ma scrivere in SCL o in STL non credo faccia la "differenza". Perchè adesso come è scritto?

 

 

L'errore è si sempre lo stesso ma inteso come distanza percorsa dal pezzo, non come cadenza dell'errore, magari un pezzo su tre cade nella sua posizione giusta, mentre gli altri due no.

 

Per quanto riguarda la scriturra ora è un misto fra linguaggio strutturato e ladder, anche se so che poco importa e volevo solo fare una distinzione fra quella che è logica combinatoria e di routine ciclo (ladder) e invece i calcoli più complessi (in strutturato) ed è stato sbagliato da parte mia distinguere non per complessità di codice quanto più per linguaggio.

 

Grazie per la risposta!

[acquaman]

E collegare la fotocellula ad un ingresso del drive programmando il drive come comando di stop, il drive dovrebbe essere molto più veloce a leggere i suoi ingressi ed a reagire di conseguenza.
 

[Livio Orsini]

2 ore fa, RyanKunzle ha scritto:

Potrei tenere in considerazione spostare le FTC dalla periferia al PLC, indubbiamente.

 

Sposti le FTC sulla periferia del PLC.

In OB1 vai a leggere più volte lo stato delle FTC, leggendo direttamente la perifieria, non il registo immagine.

In questo modo ti sganci dal tempo di ciclo e, soprattutto, dall'aggiornamento del registro immagine degli ingressi, aggiortamento che si effettua solo all'inizio ciclo o fine ciclo, dipende da come prendi il riferimento temporale.

[acquaman]

Ma nel tempo ciclo ci rientri quando elabori l'ingresso e comandi l'inverter.
Se lo colleghi direttamente e lo gestisci dall'inverter ti svincoli da tutto il plc.

Lo avevo fatto con un asse come start per far eseguire un inseguimento di un nastro con un discreto risultato.

[batta]

Certo che se con "programma ridotto all'osso" il tempo di ciclo è di 80 ms, significa che la scelta della CPU è completamente sbagliata.
Per il fatto di avere tre assi gestiti con oggetto tecnologico, mai e poi mai mi sarei sognato di prendere una 1212.
Detto questo, il modo migliore per risolvere è gestire il segnale della FTC con un ingresso ad interrupt, e comandare lo stop all'interno dell'OB lanciato dall'interrupt.
Domanda: che tempo hai messo per MC-Servo?

[batta]

7 ore fa, Yiogo ha scritto:

per fare del motion dovresti fare un scan  non sopra gli 8, per cui la cpu deve girare in quell'ordine

La CPU potrebbe anche girare con tempi più elevati (certo che 80 ms sono proprio tanti), importante è che sia su tempi ragionevoli MC_Servo.
Chiaramente, non serve far girare su tempi corretti MC_Servo se, poi, il comando di arresto è gestito nella normale scansione da 80 ms.
Il segnale della FTC deve essere gestito come interrupt o, in alternativa, all'interno di MC_Preservo, avendo l'accortezza di fare la lettura immediata dell'ingresso.

Sul fatto che la CPU sia completamente sbagliata per questa applicazione, credo che siamo tutti d'accordo.

 

 

[pigroplc]

Io proverei a gestire i V90 con il telegramma 111 e libererei la parte motion. In fondo se hai 80 ms di tempo ciclo vuol dire che di movimenti interpolati non ne devi fare ed è tutto punto a punto. 

Quant'è il tempo ciclo a questo punto?

 

 

[beghelli_j]

Entro nella discussione da profano e chiedo a Batta.

Ho visto che quando creo un oggetto tecnologico vengono automaticamente creati nel progetto i 2 OB chiamati MC-Interpolator(OB92) e MC-Servo(OB91).

Nelle applicazioni piccole che ho sempre fatto, in questi 2 OB non ho mai scritto niente, perchè comunque la CPU riusciva a gestire l'asse gestendolo da un blocco FC richiamato in OB1.

Da quel che ho letto sopra, invece andrebbero scritti nell' OB91 i comandi relativi all'oggetto tecnologico ?

Di default OB91 è richiamato ogni 10ms.

grazie per la risposta

[batta]

MC-Servo (OB91) e MC-Interpolator (OB92) sono blocchi di sistema. Non ci devi scrivere proprio nulla. Anzi, anche volendo proprio non ci puoi scrivere nulla, perché sono protetti.
Se devi fare operazioni sincronizzate con questi blocchi, puoi creare MC-PreServo e MC-PostServo che, come dice il nome, verranno elaborati rispettivamente prima e dopo MC-Servo.
Un esempio classico dell'utilizzo di MC-Preservo e MC-Postservo è la gestione di un asse oleodinamico, dove la risposta dell'asse non è lineare come è invece nel caso di un motore elettrico. In questi OB si scrivono le istruzioni per rendere lineare la risposta dell'asse.
La gestione degli assi con le istruzioni MC_xxx però non va assolutamente scritta in questi OB, ma in altri blocchi (FC o FB).