I POUs e gli INTERRUPTs di un Programma

[photomass]

Buonasera a tutti. Vorrei capire, attraverso qualche esperto, che tipo di funzione hanno i POUs con i quali divido un programma per gli FP?

Posso dividere un ciclo complesso su più POUs, o devo metterlo tutto sullo stesso? Se posso dividerlo, come viene gestita la priorità?

E gli INTERRUPTs? Forse devo usare quelli per sezionare un ciclo e poterne gestire la priorità?

Mi potete spiegare per favore?

Grazie infinite.

Buona serata.

Massimo

[Roberto Gioachin]

Ciao Massimo,

Il programma che stai usando è fatto secondo lo standard IEC61131 e quindi quello che vale per questo vale anche per altri.

I POU (Program Organisation Unit) hanno proprio lo scopo di organizzare in modo strutturato i vari "pezzi" di programma in modo da rendere tutto il progetto più facile da interpretare.

Come POU puoi creare diversi PRG ognuno con uno scopo ben preciso, ad esempio puoi utilizzarne uno per ogni parte di macchina, oppure uno per ogni motore ecc, in modo da strutturare il progetto, questi POU sono poi esportabili ed importabili in modo che ti puoi creare delle librerie da riutilizzare in altri progetti.

Oltre ai PRG puoi creare anche delle FUN (Funzioni) o delle  FB (Blocchi funzione), questi POU servono a racchiudere al loro interno delle funzioni che realizzi per scopi specifici e di utilizzo abbastanza generico (ma non solo). Naturalmente non è facile spiegare tutto in poche righe.

Posso dividere un ciclo complesso su più POUs, o devo metterlo tutto sullo stesso? Se posso dividerlo, come viene gestita la priorità?

Per dare una risposta si dovrebbe capire cosa intendi per Ciclo complesso e Priorità, ci sono molti modi per realizzare cicli, ma normalmente una stessa sequenza va messa in uno stesso POU, dico normalmente perché non è obbligatorio.

Tutti i PRG che hai creato vengono eseguiti con una sequenza che viene determinata all'interno della finestra dei Task, nella quale puoi spostare a piacimento tutti i PRG che hai creato, la sequenza di elaborazione del plc prevede che vengano eseguiti dall'alto verso il basso.

Per quanto riguarda gli INTERRUPT, il loro utilizzo è ben diverso da quello che pensi, al livello di conoscenza che hai di sicuro non ti servono e io lascerei stare, il loro scopo è quello di interrompere il programma principale sulla base di un evento, per eseguire il programma di INTERRUPT specifico, al termine viene ripreso il programma principale da dove era stato interrotto.

 

Roberto

 

[photomass]

Grazie Roberto, già così hai chiarito molte lacune che avevo. Diciamo che le mie domande sono volte a comprendere come è meglio strutturare un programma per una macchina che ha una tavola girevole con dodici stazioni. Ogni stazione presenta il carico di un componente o una lavorazione di assemblaggio. Le singole operazioni su ogni stazione sono chiaramente cicliche e scollegate tra loro. Da qui nasceva la domanda su come sezionare il programma e come dargli delle priorità. E' chiaro che concettualmente i cicli avvengono simultaneamente ma nella realtà cosa accade veramente? Il principio di funzionamento di un PLC lo conosco grossolanamente e finora le macchine che ho realizzato non avevano particolari esigenze di cicli simultanei a velocità spaziali. Ora invece vorrei approfondire meglio il concetto per vedere se la performance della macchina può essere migliorata sulla base di una miglior strutturazione del programma. Grazie per ciò che hai già fatto e in anticipo per ciò che vorrai e potrai dirmi a riguardo.

Saluti a te e a tutti gli utenti.

Massimo 

[Roberto Gioachin]

Da come dici, la tua macchina deve avere un ciclo diverso per ogni stazione, ma alla fine tutti questi cicli devono essere sincronizzati prima di far ruotare la tavola.

Devi sempre considerare che il plc lavora con il metodo delle scansioni cicliche, quindi esegue in modo ciclico e continuativo tutte le istruzioni dall'alto verso il basso, il tempo di scansione può durare qualche mili-secondo, questo dipende dal tipo di plc, da quanto programma inserisci, dal tipo di istruzioni che utilizzi e da come gestisci il programma stesso. Questo significa che i tuoi cicli possono girare tutti contemporaneamente ed indipendentemente l'uno dall'altro.

Ci sono diversi modi per realizzare cicli ed ognuno ha il suo preferito. Io ti consiglio di affronterei il problema in questo modo:

Realizza 12 cicli indipendenti uno per ogni stazione e mettili a punto in modo che possano realizzare il lavoro in modo corretto, realizza poi un ciclo "Master" (diciamo) che controlli il movimento della tavola, questo ciclo deve avere le informazioni dello stato di tutti gli altri cicli, e deve poter attivare lo start di tutti i cicli. Questo "Master" permetterà di sincronizzare la macchina aspettando il termine di tutte le operazioni prima di passare alla fase successiva. Una tecnica di questo tipo ti permette anche di decidere se tutte le stazioni devono lavorare o se alcune devono rimanere ferme, non so se questo è il tuo caso, il mio è un concetto generale.

Strutturare il programma significa anche non mettere tutti i cicli in un unico POU, ma crearne uno per ogni una di queste funzioni, e poi altri ancora per le singole parti di macchina. Usa le istruzioni giuste per fare in modo che tutto quello che non serve non venga elaborato (come i salti di programma) in modo da ridurre il carico del processore e quindi ridurre i tempi ciclo, per esempio se usi un FPSigma dovresti cercare di ottenere tempi di scansione non superiori ai 10 15 mili-secondi anche con programmi complessi.

Roberto

[photomass]

Infiniti grazie... scusa per il ritardo ma non mi sono collegato per diversi giorni. Penso proprio che strutturerò il programma come hai detto tu. Per ragioni di bus di campo userò proprio un FPSigma. Non mi è molto chiaro cosa significhi "dovresti cercare di ottenere tempi di scansione non superiori ai 10 15 mili-secondi anche con programmi complessi."

In programmi, sotto tasks, devo ordinare i vari pous in maniera specifica o fa lo stesso, essendo tutti pous indipendenti?

Un'ultima domanda per risolvere un problema che ho. C'è un modo affinché si possa tenere in memoria ritentiva lo stato di una booleana, un marker o R ad esempio? Ho provato a dichiararla come variabile retain sul pou head, in locale, ma mi pare che non funzioni. Probabilmente sbaglio qualcosa. Finora utilizzavo il metodo di muovere in una dt retain un int pari a 0 o pari a 1 a seconda dello stato del marker e di andare poi a leggere da quella dt quando si riaccendeva la macchina. Certo funziona ma mi sembra un sistema arcaico e impegna quasi certamente più passi di quanti ne impegnerebbe una network banale in cui si usa in uscita, una variabile ritentiva. Per i tempi di scansione non saprei poi cosa sia meglio ma immagino la soluzione con meno passi.

Grazie Roberto 

Ciao 

[Roberto Gioachin]

Eccomi di nuovo...

Tempi di scansione: se il programma è ben fatto il PLC dovrebbe eseguire le sue scansioni cicliche in tempi abbastanza rapidi, nell'ordine appunto di circa 15 mili-secondi. Questo dato lo vedi da FPWin pro monitorando lo stato del plc. Se ottieni tempi maggiori potrebbe significare che hai realizzato un programma pesante o poco ottimizzato. Per ottimizzare un programma potrebbe essere necessario realizzare dei salti di programma, oppure realizzare le sequenze con SFC al posto di atri tipi di istruzione.

Nei tasks puoi mettere l'ordine che vuoi, l'unica precauzione è quella di mettere (se li usi) tutti i POU in SFC consecutivi, questo significa che fra due o più POU in linguaggio SFC non ci devi mettere altri tipi di programmi in Ladder o ST o altro, ma se cerchi di farlo il compilatore ti darà un messaggio di errore.

Ho provato a dichiararla come variabile retain sul pou head, in locale, ma mi pare che non funzioni. Probabilmente sbaglio qualcosa.

Se ti serve una variabile ritentiva, ti conviene dichiararla come globale. Questo PLC ha diverse aree di memoria ritentive senza l'utilizzo della batteria, da WR248 a WR256 per le variabili utilizzabili anche come singolo booleano, da DT32710 a DT32765 per la variabili Word. Se utilizzi la batteria tampone puoi avere tutta la memoria del plc ritentiva. Inoltre senza l'uso della batteria puoi salvare (con un istruzione) tutta l'area dati DT in blocchi di memoria flash (32766 Wodd), quindi mi pare che di memoria ritentiva ce ne sia a sufficienza.

Per il tuo problema ti conviene utilizzare la memoria ritentiva di tipo WR utilizzando il singolo bit (dovresti sapere che una WR248 contiene i bit da R2480 a R248F), fai in modo che questi siano nell'area ritentiva su "Altro" "Opzioni" "Intervalli di indirizzi", e fai in modo che in dichiarazione non siano inizializzati su "FALSE", anzi, che non siano inizializzati proprio. Fatto questo vedrai che puoi salvare tutti i bit che ti servono.

[photomass]

A rigrazie...  . Ma il tempo di scansione sarà influenzato dal numero di passi di programma o no? Cioè, se ho compilato un programma di 3000 passi avrò tempi di scansione più bassi rispetto a un programma che ha 30000 passi? Oppure si da per assunto che pur sfruttando tutta la capacità del PLC il tempo di scansione, se il programma è ben fatto, deve aggirarsi sui 15ms?

Ciao.

Massimo

[Roberto Gioachin]

Mi sono spiegato male, probabilmente molto male.

Il tempo di scansione del plc dipende sicuramente dalla dimensione del programma, ma non solo. Per esempio istruzioni di tipo booleano impegnano il processore molto meno di istruzioni di tipo matematico, poi istruzioni in virgola mobile impegnano un tempo maggiore rispetto ad istruzioni in intero o doppio intero. Questo vuol dire che se si programma utilizzando istruzioni in virgola mobile per fare calcoli che potrebbero essere fatti con interi, si ottiene lo stesso risultato ma con un impegno maggiore del plc. Stessa cosa vale se si utilizzano istruzioni matematiche per fare quello che potrebbe essere fatto con logica booleana.

Detto questo si capisce come due programmi entrambi ben funzionanti possano impegnare in modo diverso il processore.

La mia considerazione inoltre andava anche un po' oltre, infatti normalmente in un programma medio non è necessario che tutto il codice sia elaborato ad ogni scansione, eseguire quindi salti di programma può ridurre ulteriormente il tempo di scansione. Il tuo programma per esempio contiene dei cicli (sequenze), normalmente in un ciclo macchina solo poche istruzioni entrano in gioco contemporaneamente, le altre possono rimanere congelate fino a che la sequenza non arriva al punto in cui devono lavorare, utilizzare salti di programma o meglio il linguaggio SFC permette di ridurre i tempi di scansione.

Naturalmente puoi anche non preoccuparti di problemi di questo tipo, il mio è solo un consiglio.

[photomass]

Assolutamente ben accetti i consigli. Solo che credo di essere ad un livello infimo x apprezzare le finezze di cui mi parli. Oggi ho verificato i tempi di scansione.  Ho compilato circa un terzo del programma e sono  a poco meno di 8000 passi. Ancora non ho programmato i tre assi elettrici che sono presenti ma il tempo di scansione si aggirava tra i 4 e i 5 ms. Può essere accettabile? Speriamo che la proiezione finale sia più o meno proporzionale. Io scrivo il programma in ld.Non sapevo che anche il linguaggio può migliorare le prestazioni del plc. Terrò bene a mente che dove possibile è meglio usare booleane. Tenpo fa durante un corso mi fecero vedere un sacco di belle istruzioni che semplificavano la vita di chi programma. Mi resi poi conto grazie a un consiglio di un tecnico Panasonic che si trattava di FB. Lui mi consigliò di usarle meno possibile xe' in genere impegnano molti più passi di programma. Impegnano maggiormente anche il processore???

Grazie ancora.  Alla prossima.

A dimenticavo... grazie per la dritta sulle wr retain.... ora funzionano come volevo. Grazie.

 

Ciao

Massimo

[lelos]

Tenpo fa durante un corso mi fecero vedere un sacco di belle istruzioni che semplificavano la vita di chi programma. Mi resi poi conto grazie a un consiglio di un tecnico Panasonic che si trattava di FB. Lui mi consigliò di usarle meno possibile xe' in genere impegnano molti più passi di programma. Impegnano maggiormente anche il processore???

SI , perché il compilatore non ottimizza bene le FB (è una pecca del compilatore)

Ancora non ho programmato i tre assi elettrici che sono presenti ma il tempo di scansione si aggirava tra i 4 e i 5 ms. Può essere accettabile?

il tempo di scansione è influenzato anche dal tipo di cpu che usi ,io ho un prg da  circa 9000 passi e scansiono in 1,5 ms.

[photomass]

Ciao Ielos, ma stiamo parlando di un Pana FP Sigma?

Ciao

[lelos]

certamente no , a uno superiore , intendevo che plc più potente = scansione più veloce a parità di programma

[photomass]

Ahhh ok adesso è più chiaro.

 

Ho un quesito x Roberto che penso sia pratico di Panasonic. Sto scrivendo i vari prg suddivisi in pou, uno per ogni stazione della macchina. Nei miei programmi di solito inserisco una variabile (contatto aperto) in ogni singola network che da luogo a un set o reset di uscite che eseguono movimenti. Questa variabile viene usata x l'esecuzione step by step. In un pou separato attivo questa variabile con uno schema di autoritenuta  per eseguire il ciclo automatico oppure l'attivo attraverso il fronte di salita di un " pulsante" x eseguire il ciclo a step. Oggi mi è successa una cosa strana; nei primi tre prg delle prime tre stazioni cliccando a video sulla variabile le prime tre stazioni funzionavano perfettamente in step, l'ultimo programma invece no. Anche cliccando direttamente sulla variabile all'interno delle network l'uscita non si attiva in quel pou  mentre tutte gli altri pou eseguono le networks regolarmente.

È possibile che essendo usata molte volte in più pou ed essendo attivata sul fronte di salita di un "pulsante" la scansione non riesca a trovarla chiusa nell'ultimo pou? O quello che scrivo è totale eresia?

Ciao e grazie.

Massimo

 

[lelos]

ciao

controlla come sono messi i programmi nel plc, nel senso chi è il primo che viene scansionato e chi è l'ultimo .

[Roberto Gioachin]

Non importa quante volte leggi una variabile, puoi leggerla anche in ogni network del programma.

La sequenza di esecuzione dei vari POU viene definita su "Task", verifica che dentro ci siano tutti i tuoi POU, inoltre il POU con la variabile di cui fai cenno vedi che sia posizionato prima degli altri, vedi che la variabile sia Globale e che per errore non ci sia un doppione di questa dichiarata come locale nel POU che non va.

Verifica poi come viene assegnata la variabile, se questa viene assegnata in un POU di tipo PRG non ci sono problemi, se invece è una variabile di uscita di una Funzione allora bisogna vedere bene come è stata utilizzata.

Verifica inoltre che non sia stata assegnata più di una volta, dopodichè bisogna vedere il programma come è stato fatto per capire meglio.

Roberto

Modificato: 16 dicembre 2015 da Roberto Gioachin

[photomass]

Dunque, intanto grazie dell'aiuto. Ieri dopo avervi scritto, ho verificato con quale sequenza il PLC scansionava i vari POU. Il POU che non andava era all'ultimo posto dopo svariati POU (circa una dozzina), che sono vuoti o che contengono pochi passi di programma. Tra questi POU ce ne uno che contiene le funzioni di Data Exchange della FMU Profibus DP, e uno che ho chiamato "Indirizzamento" in cui sono indirizzate tutte le variabili booleane collegate, attraverso funzioni "Word to Bools" o "Bools to Word"  agli indirizzi dei vari device sul campo che gestiscono per la maggior parte I/O. Poi c'è il ciclo Master che gestisce i movimenti della tavola sulla base dello stato dei cicli sulle stazioni. Ai primi tre posti c'erano invece i POU relativi ai PRG dei cicli delle prime tre stazioni, più o meno articolati e complessi.

Sulla base della mia supposizione di cui vi ho parlato ieri, ho provato a spostare il POU non funzionante, relativo al ciclo della quarta stazione, al quarto posto nei task. La variabile ha continuato a non funzionare.

A quel punto l'ho spostata al primo posto, convinto che il POU che stava al terzo e diveniva quarto, non funzionasse più. Invece inspiegabilmente la variabile ha cominciato a funzionare indistintamente su tutti e quattro i POU, quindi cliccando a video tutti i quattro cicli funzionano contemporaneamente, naturalmente step by step.

Cosa può essere accaduto? Oggi proverò nuovamente a spostarlo al quarto posto e vedere cosa accade... poi vi aggiorno. 

Grazie e ciao.

Massimo