Mappatura pezzi su nastro di trasporto

[marco1278]

Ciao a tutti,

Mi trovo a lavorare su un’etichettatrice dotata di plc siemens s7-1200 e driver proprietario per il comando del motore dell’etichettatrice.

Sul nastro di trasporto ho una fotocellula che è elettricamente collegata sia al plc che al driver del motore.

Dopo l’applicazione dell’etichetta sono presenti due soffi ad aria compressa che piegano l’etichetta sul prodotto.

 

Devo far lavorare i soffi a intermittenza, cioè solo quando sta passando il prodotto con l’etichetta.

 

Mi sono creato una FB che richiamo 2 volte… una per ogni soffio.

La FB è composta da:

- 10 variabili booleane

- 10 timer TON

- una variabile INT di conteggio 

- una variabile generale #out

 

Sul fronte di salita della fotocellula vado a settare la varibile booleana corrispondente alla variabile di conteggio e poi incremento la variabile di conteggio. (Se il conteggio è a 5, setto la vatiabile 5 e poi incremento a 6)

Quando arrivo a 10 ricomincio a contare da 1.

Ogni variabile booleana attiva il rispettivo timer che inizia a contate il tempo.

Al raggiungimento del tempo impostato, ogni timer attiva la variabile #out e resetta la propria variabile booleana di attivazione così da disattivarsi.

La variabile #out, una volta attivata, viene disattivata da un altro timer dedicato.

 

 

Questa logica mi consente di tenere memoria dei pezzi che passano perché tra la fotocellula e l’ultimo soffio ci possono essere massimo 3 pezzi. Per evitare problemi ho creato i 10 timer.

 

Il sistema funziona… però fatto così non mi piace molto e non è precisissimo.

Qualcuno ha qualche suggerimento da darmi per fare un sistema più pulito?

 

Ho già provato a fare un ciclo con interrupt da OB30 impostato a 2ms, ma ho notato che non cambia molto sulle performance.

Lo so che ho un PLC poco performante per fare queste cose.

 

I tempi di ritardo variano da 60ms sul primo soffio a 200ms sull’ultimo.

 

Grazie

 

Ciao

[Marco Fornaciari]

Tipicamente questi problemi si risolvono più facilmente con uno shift register con i bit di una o più DB in fila.

Si fa pure il possiile per evitare tempi di ritardo, che con tempi così brevi non sono mai ripetitivi nei confronti del comando dell'uscita: bisogna posizionare correttamente il sensore di lettura e il soffio, quindi utilizzare elettrovalvole rapide.

 

Ma se funziona e ci devi perdere tempo per ricollaudarlo, lascia così e lo rifai solo se ci sono problemi.

La prossima volta lo rifai diverso.

 

Se il tempo di ciclo di tutto il programma è molto breve in rapporto alla velocità delle lavorazioni, usare un interrupt non serve e magari crea solo inutili complicazioni. 

[thinking]

Suggerimento, usa contatori (invece di timer che sono più lenti). Poi dovrai modificare una variable che non sono millisecondi ma che corrisponde ad un tempo.

 

Curiosità mia: non capisco 10 timer per gestire 2 soffi ma se hai fatto così immagino che servono.

ciao

[drn5]

Quindi una macchina a stati.

 

2mSec mi sembrano pochini per un 1200, però c'è anche da capire quanto è il tempo ciclo. Forse bastava un OB30 a 10mSec.

 

Se però usi i timer, per quello che mi pare di capire ne bastava uno solo nelle dichiarazioni static del FB.

 

Alla fin dei conti comunque "software che gira non si tocca" , anchio lascierei stare.

 

[marco1278]

Ciao, il tempo ciclo della CPU varia da 7ms a 13ms.

 

Non potevo usare un solo timer perché tra fotocellula e soffio posso avere 3 pezzi contemporaneamente, per cui devo tenere memoria dei singoli pezzi. 
Ne ho nessi 10 perché se in futuro cambiano i prodotti non devo riscrivere tutto.

7 ore fa, thinking ha scritto:

Poi dovrai modificare una variable che non sono millisecondi ma che corrisponde ad un tempo.

 

Non ho capito?!

 

 

[thinking]

Ti scrivo come usare un contatore come timer secondo la IA:

 

3. Logica nel Segmento (Linguaggio LAD)

Utilizzeremo un blocco CTU (Counter Up). Per farlo funzionare come un timer da 10 secondi, imposteremo il valore di preset (PV) a 10.

Segmento 1: Logica del Contatore

• Ingresso CU (Count Up): Inserisci un contatto normalmente aperto di Clock_1Hz in serie con Start_Timer. In questo modo, il contatore riceve un impulso ogni secondo solo se lo "start" è attivo.

• Ingresso R (Reset): Inserisci il bit Reset_Timer.

• PV (Preset Value): Scrivi 10 (per un ritardo di 10 secondi).

• Uscita Q: Collega Tempo_Raggiunto.

---

Come funziona nella pratica

1. Quando attivi Start_Timer, il contatore inizia a ricevere gli impulsi dal bit %M0.5.

2. Ogni secondo, il valore attuale (CV) aumenta di 1.

3. Al raggiungimento di 10 (dopo 10 secondi), l'uscita Q del contatore e la tua variabile %Q0.0 diventano vere.

4. Se disattivi Start_Timer, il conteggio si ferma (mantenendo il valore raggiunto). Per ricominciare da zero, devi attivare Reset_Timer.

Perché usare un contatore invece di un timer standard?

• Memorizzazione: Se manca la corrente o fermi il segnale, il contatore "ricorda" a che punto era arrivato (se configurato come ritentivo).

• Lunga durata: I timer standard hanno limiti di tempo specifici. Con un contatore e un clock più lento (es. 1 minuto), puoi creare timer che durano giorni o settimane con estrema precisione.

Nota Tecnica: Per una precisione assoluta, è meglio usare i fronti di salita (P) del segnale di clock, anche se con 1 Hz il CTU standard gestisce bene la variazione di stato.

[marco1278]

Ok, adesso ho capito cosa intendevi.

Usare i contatori va bene, ma ho il problema del tempo di incremento.

Il merker clock più veloce è 100ms e nella mia applicazione il primo soffio si attiva dopo 60ms, per cui dovrei gestire i contatori ad interrupt.

Ogni quanto? 10ms? 5ms? 

[Roberto Gioachin]

1 ora fa, marco1278 ha scritto:

Ciao, il tempo ciclo della CPU varia da 7ms a 13ms

La soluzione che hai adottato non è sbagliata, almeno dal punto di vista concettuale, ma con quei tempi ciclo non è che puoi pretendere molta precisione.

Utilizzare un interrupt a tempo può anche migliorare ma rimane l'indeterminazione della lettura della fotocellula che segue il tempo ciclo.

Potresti pensare di usare un interrupt su evento, quello della fotocellula. Poi ti rimane il problema di contare il tempo con precisione, e siamo sempre li.

Se vuoi ottenere risultati più precisi usa un PLC con tempi di scansione che si avvicinino a 1 ms

[marco1278]

Adesso ho spostato tutto su OB ad interrupt impostato a 2ms. Ho cambiato i timer con dei contatori e vado a leggere e scrivere ingresso FTC e le due uscite direttamente senza passare dall’immagine di processo.

 

Sto a vedere se la CPU regge o si schianta 🫣

[Livio Orsini]

2 ore fa, Roberto Gioachin ha scritto:

usare un interrupt su evento, quello della fotocellula.

 

Concordo; anche per me è il modo più affidabile per rilevare il sensore senza ritardi apprezzabili.

[marco1278]

2 ore fa, Livio Orsini ha scritto:

 

Concordo; anche per me è il modo più affidabile per rilevare il sensore senza ritardi apprezzabili.

Ciao Livio,

non è tanto rilevare il sensore… è proprio gestire i conteggi dei temporizzatori dentro al ciclo.

Nei prossimi giorni vedo come si comporta il sistema con l’attuale gestione ad interrupt di 2ms.

Ciao

[84paolo]

Verifica anche i filtri impostati sull'hardware. Non hai specificato se sono I/O a bordo o periferia o altro. 

[marco1278]

3 ore fa, 84paolo ha scritto:

Verifica anche i filtri impostati sull'hardware. Non hai specificato se sono I/O a bordo o periferia o altro. 

Sono tutti I/O a bordo della cpu.

Non mi preoccupa tanto la lettura e scrittura diretta degli I/O che leggo/scrivo direttamente senza passare dall’immagine di processo, quanto il tempo di calcolo e gli interrupt ogni 2ms.

[drn5]

Il tuo trigger è la fotocellula ! O ci agganci un interrupt oppure vai di timer come stai facendo.

Non vedo il motivo di tirare in ballo l'OB a tempo a 2ms.

Già il fatto che il tempo ciclo passa da 7ms a 13ms mi piace poco. Vuol dire che il codice ogni tanto "sonnecchia" da qualche parte. Quei 6ms in più sono numericamente pochi, ma la variazione del 95% è tanto. Io sistemerei quello non l'OB a tempo

 

Ti preoccupi del tempo di calcolo di 3 variabili e un paio di timer? Stai mica comandando "Artemis 2". 😁

[marco1278]

Il programma originale, visto che non l’ho fatta io la macchina, ha OB1 e poi un OB a interrupt ogni 10ms che fa solo un set bit per un block. Quello potrebbe essere il motivo del tempo ciclo che saltella.

Io ci ho aggiunto anche interrupt ogni 2ms. Adesso ho il tempo ciclo che varia da 10ms a 20ms però me lo aspettavo.

 

Devo togliere OB da 10ms che tanto non serve.

 

La CPU gestisce anche comunicazione profinet e scambio dati S7COM con un altro plc.

 

Se metto interrupt sul segnale della fotocellula e poi elaboro in OB1 cosa mi cambia? Rimango sempre vincolato al tempo ciclo di OB1.

[84paolo]

1 ora fa, marco1278 ha scritto:

Non mi preoccupa tanto la lettura e scrittura diretta degli I/O che leggo/scrivo direttamente senza passare dall’immagine di processo, quanto il tempo di calcolo e gli interrupt ogni 2ms.

Se nell'hardware hai il tempo di filtro su ingresso ce lo hai anche se leggi direttamente dalla periferia 

[marco1278]

1 ora fa, 84paolo ha scritto:

Se nell'hardware hai il tempo di filtro su ingresso ce lo hai anche se leggi direttamente dalla periferia 

Giusto hai ragione.

Ho controllato ed è impostato a 6,4ms. Domani lo imposto a 0,4ms.