Attivazione Uscite Su Giro Macchina - ovvero come replicare un programmatore a camme con una CPU 226XM

[alberto rosso]

Gentili frequentatori del forum,

approfitto di questo spazio e della vostra disponibilità per chiarirmi qualche dubbio su una applicazione che cerco di realizzare su una macchina confezionatrice.

La macchina funziona a cicli per cui la fase macchina è prelevata dall'albero motore per cui ogni giro corrisponde un ciclo macchina completo (si lavora con velocità comprese tra i 10 e i 40 cicli/min.)

Ora mitrovo nella condizione di dover inserire dei comandi pneumatici a bordo macchina attivati nel ciclo macchina, ma in maniera flessibile, cosa che prima si faceva con cammes registrabili in ampiezza e con dei proximity.

Al crescere della complessità dei compiti che il cliente vuole realizzare sulla stessa macchina mi vedo costretto ad aumentare il numero di uscite e la flessibilità di regolazione dei punti di intervento per cui mi chiedo se la cosa è fattibile con una CPU.

A bordo macchina è presente una CPU226XM (oppure a seconda dell'età della macchina una 224XP).

Il tutto è accoppiato a un TP177micro che deve poter gestire i punti di attivazione delle uscite. Per semplicità la macchina è dotata di un encoder A+/B+/reset 360 imp./giro.

Io devo poter modificare per ogni uscita (o camma virtuale) un punto di attivazione e un punto di disattivazione all'interno del giro fino a un massimo di 4 camme.

La macchina è dotata di un px che va a leggere un riferimento fisso che possiamo considerare lo zero macchina.

Fino a quando ho una sola camma non è troppo un problema. Con tante camme non riesco a capire bene come implementare la cosa in quanto gli step del contatore prevedono una successione ordinata di set-point, mentre io i valori li devo poter inserire arbitrariamente.

Grazie a chiunque voglia rispondere.

Saluti

[Luca Bab]

Come e' collegato l'encoder ???

Hai disponibile la quota all'interno del PLC ???

Se hai la quota in una variabile , ti puoi fare tutte le camme che vuoi con delle comparazioni

attenzione pero' alla velocita' di risposta.

Ciao

Luca

[carminedivico]

Al posto delle camme e proximity perche non provi ad usare un posizionatore angolare con encoder assoluto?

Con un posizionatore la funzione di cui ha bisogno è gia realizzata;

ti basta una semplice parametrizzazione e puoi gestire tante camme quante sono le uscite a disposizione ed i parametri sono modificabili da tastierino integrato.

Poi se proprio hai bisogno di interagire con il plc ci sono quelli appositi.

[alberto rosso]

X luca bab

"Come e' collegato l'encoder ???"

IN che senso?

Meccanicamente è solidale all'albero di trasmissione della macchina.

Elettricamente è collegato in HSC0/modo10 ovvero A+, B+ e zero.

"Hai disponibile la quota all'interno del PLC ???"

Volendo si. Con un ciclo di zero macchina all'accensione posso stabilire la quota di partenza (o angolo di partenza, se vogliamo).

"Se hai la quota in una variabile , ti puoi fare tutte le camme che vuoi con delle comparazioni

attenzione pero' alla velocita' di risposta."

Si, ma tecnicamente come procedo? Devo definire un interrupt per ogni set point, ma questi mi vengono "legati" secondo la successione numerica crescente, quindi se cambio la configurazione non riesco a visualizzaare come aggiornare gli step.

Mi spiego meglio, che mi sono arrotolato su me stesso.

Pensiamo al ciclo macchina come diviso in 360 step.

Partiamo dal presupposto che so sempre dove sono perchè salvo in una variabile il valore istantaneo del contatore.

Io ho per pura ipotesi

CAMMA 1 ON = 10°

CAMMA 2 ON = 30°

CAMMA 2 OFF= 120°

CAMMA 1 OFF= 195°

Per cui gli interrupt di verifica sono SP=10 che, una volta elaborato mi deve attivare la verifica del SP=30 e via dicendo.

Però la posizione delle "camme" non è rigida, per cui magari l'utente cambia formato e mi configura la macchina con

CAMMA 1 ON = 45°

CAMMA 2 ON = 30°

CAMMA 2 OFF= 120°

CAMMA 1 OFF= 120°

per cui io mi trovo la sequenza di interrupt che non è più corretta, perchè andrei a perdere dei giri macchina in quanto il primo interrupt è definito dalla camma 1 che è dopo la camma 2 rispetto alla configurazione precedente. Questo, a mio avviso, perchè la sequenza degli interrupt è rigida.

In questo caso quindi avrei il primo interrupt SP=45, poi il SP=30 (quindi intanto perdo le verifiche SP=120 dei du passi successivi), quindi il SP=120 e poi dovrei aspettare ancora un giro per rilevare il quarto SP=120.

La cosa funzionerebbe se ogni volta che cambio i parametri di ON e OFF riordinassi la sequenza in ordine crescente per cui avrei comunque sempre gli eventi in sequenza, ma perderei comunque l'associazione con le singole camme che andrebbero anche queste in qualche maniera riordinate secondo la sequenza crescente (array e puntatori?)

Questo mi lascia veramente in tilt.

A questo punto mi viene da pensare che che devo fare una semplice comparazione di variabili fregandomene della funzione di interrupt e sperare che non mi salti qualche uscita se gli step sono molto vicini da saltare magari le linee di programma.

O come suggerisce carminedivico mi compro un OMRON con il suo encoder assoluto e buonanotte ai suonatori. Ma il problema è che costa, e i clienti tendono a mal digerire le modifiche costose. Tendono a dire cose spiacevoli tipo "EH! Ma hai già il PLC montato, possibile dobbiamo montare un altro amennicolo?"

Saluti.

[Luca Bab]

Sicuramente con un programmatore di cam risolvi i problemi ( come dice carmine ) ,

quello che intendevo io era la possibilita' di non attivare degli interupt ,

ma leggendo la quota attuale e comparandola con la fase di inizio e di fine della camma ,

in poche parole hai un bit alto quando la posizione attuale e' compresa all'interno della camma

Ovviamente hai dei tempi di ritardo , quindi non so' se nella tua applicazione sono acettabili o no.

Un'altra funzione che potresti implementare nel programma e' l'anticipo di queste camme in base alla velocita' attuale della macchina.

Un'altro metodo per diminuire i tempi delle camme e' richiamare piu' volte il pezzo del tuo programma che genera le camme e attiva le uscite ( relative alle camme )

Ciao

Luca

[peopeo]

Per gestire diversi profili della camma devi creare delle ricette o programmi ( dipende da quante variabili di lavoro ci sono ) in cui vai a cambiare gli angoli di comparazione. Per esempio con angolo maggiore di 30° e minore si 120° attivi l'uscita 1 e con angolo maggiore di 45° e minore di 90° attivi l'uscita due mentre in un altro programma avrai con angolo maggiore di 15° e minore di 270° attivi l'uscita 1 e con angolo maggiore di 120° e minore di 180° attivi l'uscita 2. Come vedi le possibilità di combinazioni con encoder sono molteplici. L'unico accorgimento è quello della ricerca del punto zero e la conversione del valore encoder in angolo il quale va azzerato ad ogni giro completo dell'encoder per avere una variabile che va da 0° a 360°.

[JumpMan]

Con i dati che hai dato risulta che alla velocità massima l’albero si sposta di 1 grado ogni 4.1ms, non so cosa faccia il tuo plc ma se il tempo di ciclo rimane sotto i 4ms non hai problemi! Se sta tra i 4 e gli 8ms al massimo perdi 1 grado !

- Fai una piccola SBR per la sola gestione delle camme

- Appoggia il valore di conteggio in un altra Word all'inizio della subroutine

- Non usare Set/Reset, fai un confronto del seguente tipo per ogni camma:

----[>=]-----[<=]-------(Camma1)

- Elabora ciclicamente la SBR

Se il tempo di ciclo è troppo alto puoi provare a fare una INT a tempo in luogo della SBR ed elaborarla ogni, diciamo, 3ms riducendo al minimo indispensabile le istruzioni al suo interno.

Un'altra funzione che potresti implementare nel programma e' l'anticipo di queste camme in base alla velocita' attuale della macchina

... una macchinetta a “fasatura variabile” Questo può risolvere anche ulteriori problemi dovuti ai ritardi di eventuali comandi pneumatici ecc.

[Luca Bab]

Per farti le camme non e' cosi' semplice

poiche' la tua camma potrebbe essere anche 340 inizio 20 fine

quindi il segmento che ti hanno postato non e' buono del tutto

Gli interupt a tempo hanno delle latenze che se li stringi troppo ti inchiodano la CPU

quindi se vuoi piu' velocita' richiama piu' volte nel programma il pezzo che fa' le camme ed attiva le uscite ( aggiorna le uscite )

Per farti l'anticipo , la cosa migliore e' spostarti virtualmente la quota encoder in base alla velocita'

e mantenere uguale il prog che fa le camme

Ciao

Luca

[batta]

Per farti l'anticipo , la cosa migliore e' spostarti virtualmente la quota encoder in base alla velocita'

e mantenere uguale il prog che fa le camme

L'idea di base è buona, ma è valida solo se devi correggere ritardi fissi. Il ritardo dovuto alla scansione del plc invece non è fisso, sia perché le scansioni non sono tutte uguali (ma probabilmente si assomigliano), sia perché il raggiungimento della quota per il cambio di stato di una camma può avvenire, in modo del tutto casuale, in qualsiasi punto della scansione. Si dovrebbe quindi prevedere un anticipo calcolato su metà scansione per dividere l'errore. Avresti quindi la possibilità di commettere un errore che varia da +/- metà tempo scansione invece di un errore che va da 0/+ tempo scansione.

Si ottiene un miglioramento con il controllo delle camme a tempo fisso, diciamo di 4 ms. e calcolando un anticipo su 2 ms. In questo modo, alla velocità massima di 40 cicli/secondo, avresti un errore compreso tra +/- 0,5 gradi circa.

Attenzione, la subroutine di controllo quote delle camme, per poter essere richiamata ogni 4 ms, deve ovviamente essere più leggera possibile.

Altra cosa da tenere in considerazione (ma non risolveresti neanche con gli interrupt) è che l'attivazione di un attuatore generico (esempio, elettrovalvola) ha anche dei ritardi fissi, diversi per attuatori diversi, che non puoi quindi correggere in un colpo solo correggendo la lettura della posizione.

Se tutti questi ritardi non sono rilevanti per la tua applicazione, fai le tue brave comparazioni in una normale subroutine richiamata normalmente nel ciclo e sei a posto. Unica attenzione: una camma potrebbe essere attiva tra, poniamo, 300 gradi (attivazione) e 60 gradi (disattivazione). Per evitare doppie comparazioni potresti creare dei fronti di salita al raggiungimento di ogni quota e con tale fronte effettuare il set o reset delle camme, anziché attivare la camma se la posizione è all'interno di un certo range. C'è sempre da stare attenti a non perdere fronti per le quote vicine allo zero dell'encoder.

[Livio Orsini]

Si ottiene un miglioramento con il controllo delle camme a tempo fisso, diciamo di 4 ms. ...

Anche con la 226 timer di 4ms sono "tirati" c'è il rischio di jitter elevati.

Io suggerirei di impostare una quota di comparazione nello HSC; raggiunta la quota si scatena l'interrupt; nell'interupt si richiama l'aggiornamento della configurazione delle uscite legate a quella quota e si imposta la prossima quota e così via.

Bisogna sempre tenere presente che, anche usando la scrittura diretta delle uscite, c'è sempre un ritardo tra comando ed uscita fisica, ritardo che non poi del tutto trascurabile, specialmente se si usa un'uscita a relè

[batta]

Io suggerirei di impostare una quota di comparazione nello HSC; raggiunta la quota si scatena l'interrupt; nell'interupt si richiama l'aggiornamento della configurazione delle uscite legate a quella quota e si imposta la prossima quota e così via.

I 4 ms sono effettivamente un pò troppo tirati, ma la soluzione degli interrupt successivi implica un preordinamento delle quote e diventa difficile da gestire nel caso di quote uguali o molto vicine.

[Gabriele Corrieri]

Ciao

I 4 ms sono effettivamente un pò troppo tirati, ma la soluzione degli interrupt successivi implica un preordinamento delle quote e diventa difficile da gestire nel caso di quote uguali o molto vicine.

io credo che la via interrupt "intelligente" ossia preordinando le quote e gestendo i doppioni sia la via più corretta, rimane il problema delle quote vicine che rimarrebbero da gestire, magari nello stesso INT, in modo da compensare l'elaborazione dell'INT.

Comunque per rimanere con il cuore in pace ci vuole un ciclo di scansione non superiore ai 2mS, che pur potente che sia una 226XM, ma con un discreto carico non so se mantiene ...

Se poi le uscite non sono attivate in modalità immediata senza passare dall'immagine di processo ... tutto il ragionamento INT o multirichiamo in una sola scansione e anche il tempo stesso di scansione sono una pura velleità

Ciao

[JumpMan]

poiche' la tua camma potrebbe essere anche 340 inizio 20 fine

quindi il segmento che ti hanno postato non e' buono del tutto

Hai ragione mi era sfuggito questo particolare, il segmento si complica un pochino ma neanche tantissimo, sono 8 istruzioni per ogni camma:

// Somma anticipo variabile alla quota e 
// appoggia risultato su word Q1
MOVW   Quota, Q1
+I     Anticipo, Q1




// Camma1:
    Q1         Q1      Fine1 
---[>=I]------[<=I]---[>=I]---+---(Camma1)
   Inizio1    Fine1   Inizio1 |
                              |
    Q1                 Fine1  |
---[>=I]----+----------[<I]---+
   Inizio1  |          Inizio1
            |
    Q1      |
---[<=I]----+
   Fine1

Gli interupt a tempo hanno delle latenze che se li stringi troppo ti inchiodano la CPU

Probabile... per questo avevo scritto “puoi provare....” Comunque ci sono 1000 modi di arrivare alla soluzione, per esempio le 8 istruzioni per fare “Camma1” qui sopra possono essere ottimizzate (come tempo di esecuzione) se scritte in AWL appoggiando 3 confronti su altrettanti M:

LDW>=  Q1, Inizio1               
=      M0.0   
LDW<=  Q1, Fine1 
=      M0.1   
LDW>=  Fine1, Inizio1 
=      M0.2   
NOT           
=      M0.3   

LD     M0.0      
A      M0.1      
A      M0.2      
LD     M0.0      
O      M0.1      
A      M0.3      
OLD              
ALD              
=      M10.0

Potrà sembrare strano, le istruzioni sono raddoppiate ma il tempo necessario per eseguirle è poco più che dimezzato !

[carminedivico]

1) DOMANDA

Non capisco perchè :

anche usando contatori veloci che usano ingressi non filtrati,

interrupt ad evento del tipo CV=PV che intervengono in maniera asincrona rispetto al programma principale, aggiornamento immediato delle uscite fisiche senza attendere aggiornamento del registro immagine di processo al completamento del ciclo di scansione

sia importante stare con il tempo di scansione al di sotto di 4ms

Ovviamente anch'essi hanno dei tempi di acquisizione elaborazione e risposta ma dovrebbero essere molto inferiori al ciclo scansione del plc e soprattutto quasi indipendenti da esso.

Giusto o sbaglio/ometto qualcosa?

2) CONSIDERAZIONI

se prima queste funzioni venivano gestite tramite camme meccaniche e proximity,

e la macchina deve svolgere lo stesso lavoro di prima, quindi dette funzioni restano invariate

(ovvero comandi pneumatici tipo elettrovalvole anch'esse con tempi di attivazione/disattivazione piuttosto alti)

probabilmente la risoluzione di +- 1° è anche eccessiva quindi perchè scendere addirittura a +- 0.5° ?

[batta]

io credo che la via interrupt "intelligente" ossia preordinando le quote e gestendo i doppioni sia la via più corretta, rimane il problema delle quote vicine che rimarrebbero da gestire, magari nello stesso INT, in modo da compensare l'elaborazione dell'INT.

La soluzione con interrupt è sicuramente più professionale, ma prima di complicarci la vita, forse inutilmente, ci si deve chiedere qual è la precisione richiesta.

Io considero inutile fare un programma più complicato, solo perché tecnicamente corretto, se non serve.

[alberto rosso]

Grazie a tutti per le risposte.

Esaminando le varie proposte credo che alla fine opterò per la soluzione INTERRUPT FREE, in quanto credo superfluo andare a spaccare il pelo in quattro cercando il ms quando a valle c'è una batteria di valvole e dei pistoni pneumatici.

Non nego che tecnicamente mi intriga il discorso INTERRUPT e se avrò tempo magari mi cimenterò per puro interesse accademico, ma nell'applicazione a bordo macchina con la stessa CPU devo gestire anche tutto il ciclo macchina, l'interfaccia HMI e le sicurezze e vorrei evitare di dedicare una CPU solo alla gestione camme.

Vi ringrazio ancora per il tempo speso e spero di poter un giorno ricambiare.

Saluti a tutti e (per chi ci va) buone ferie.

[walterword]

se vuoi cimentarti nell'automazione industriale non devi avere paura di interrupt o pid o altro .

A tutto c'e' un perche e delle spiegazioni .

Devi avere pazienza , leggere, studiare e provare e poi godrai come un pazzo quando tutto funzionera' come vorresti .

Se i timer sono pochi si puo scrivere una funzione che funziona da timer software , con dei registri

che incrementano su un trigger e comparati con il preset ti danno il done o expired del timer .

Con un clock conosciuto si possono incrementare delle word , e come ben sai , incrementando di 1

una word vuol dire che si ottengono dei clocks "multipli" in base alle regole del digitale.

Per quanto riguarda il sequenziatore esistono diversi metodi.

Anni fa avevo creato un sistema a puntatori , e con un file di excel mettevo degli "1" e degli "0"

nelle colonne relative alle utenze con anche il tempo di pausa tra una sequenza e l'altra .

Excel calcolava il valore delle dword e venivano cosi caricate nella memoria V , nel blocco dati .

La sequenza partiva dalla prima dword e veniva demascherati tutti i bit per pilotare le utenze .

Alla fine di tutto , ho fatto la messa in servizio con un file di excel , incredibile.

Ho utilizzato diverse volte questa tecnica, ma spesso capita che devi rendere il codice leggibile e manutenibile .

Altre tecniche sono tipo quella di utilizzare una word di fase automatico .

Tradotto in linguaggi piu evoluti si tratta di uno switch-case .

ciao

walter

[alberto rosso]

Non ho paura, anzi. Purtroppo il tempo per sperimentare in questo momento non è che abbondi, in quanto devo sostituire delle camme meccaniche alla veloce. A prescindere comunque dal discorso pratico, andando a vedere la tua proposta, onestamente parlando non ho capito mica tanto bene il tuo discorso sulle word.

Comunque, per quel èpoco che ho capito, il problema di fondo nell'applicare il tuo metodo è che è "rigido", ovvero devo ricalcolare con excel le word ogni volta che vario i setpoint, cosa che non posso permettermi.

La mia applicazione prevede che l'utente finale possa modificare i set point "al volo" in maniera autonoma da un TP170.

Comunque grazie.

Saluti