Routine Calcolo Anticipo Cammes

[biros66]

Salve, mi trovo ad affrontare un piccolo problema dal quale vorrei uscirne abbastanza velocemente. In una applicazione ciclica, ho realizzato, su un vecchio TSX47425, un generatore di cammes. Il problema è il seguente:

vorrei evitare che al variare della velocità della macchina, l'operatore debba modificare manualmente i valori di soglia che attivano le cammes. vorrei, in pratica, creare un qualcosa che gestisca automaticamente questa operazione. Non spaventatevi del tipo di HW utilizzato, la macchina non "cicla" oltre 35 c/m.

Mi date una traccia oppure un consiglio, ho provato a cercare, ma sinceramente non sono convinto appieno di quanto trovato.

Grazie

Modificato: 16 luglio 2009 da biros66

[Livio Orsini]

Il problema sta nel sapere come è realizzato il generatore di cammes.

Se è fatto nel modo consueto, cioè facendo concidere la camma al raggiungimento di un certo numero di impulsi, è sufficiente decementare le quote di un valore proporzionale alla velocità.

Cerco di chiarire con un esempio.

Ammettiamo di avere due cammes: una a 500 imp. e l'altra a 1000 imp.

Fai una funzione dove ant = k * v. dove ant è l'anticipo, k una costante e v la velocità della macchina.

Calcolato ant le soglie saranno 500-ant e 1000-ant

[batta]

In un generatore di cammes ci sono fondamentalmente due problemi da risolvere: il tempo di ciclo del plc ed il ritardo degli attuatori.

Il tempo di ciclo del plc, se le cammes non sono gestite tramite routine di interrupt, ha il grosso problema che non è sempre costante e che non si può prevedere a che punto della scansione si verifica l'evento.

Partiamo quindi dal presupposto che le cammes siano gestite con interrupt, oppure che il tempo di ciclo (a proposito, cosa intendi con "35 c/m" ?) sia trascurabile.

Rimane quindi da risolvere solo il problema del il ritardo di intervento degli attuatori, che dovrebbe essere costante, indipendentemente dalla velocità della macchina.

Come soluzione, quoto quella già proposta da Livio, con una precisazione: la costante "k" deve essere diversa per ogni attuatore e, probabilmente, deve essere diversa anche per l'attivazione e la disattivazione.

Solo se tutti gli attuatori hanno un tempo di risposta molto simile tra loro si può utilizzare una sola costante. Ma questo succede abbastanza raramente.

[biros66]

c/m = Colpi al minuto, sorry.

Provo la vostra soluzione lunedì pomeriggio, intanto "softwarizzo". Io mi ero immaginato un qualcosa di enormemente più complicato (poi vi posto la mia routines abbozzata e non collaudata)

P.S. per generare le cammes ho utilizzato una soluzione classica con, dato le poche prestazioni richieste, dei comparatori, gestendo anche il passaggio per lo zero.

Thank's

Modificato: 17 luglio 2009 da biros66

[Livio Orsini]

..dato le poche prestazioni richieste, dei comparatori..

Quindi niente interrupt!

Io, prima di complicarmi la vita con gli anticipi, farei un controllo sui tempi di scansione del ciclo PLC (cfr. post di Batta). Con tempi che abbastanza lunghi, un ritardo di riconoscimento della coincidenza può disturbare notevolmente con velocità di lavoro alta.

Per minimizzare i ritardi dovresti avere l'interrupt sul riconoscimento della coincidenza e l'immediato comando dell'attuatore; in altri termini devi pilotare direttamente l'attuatore senza aspettare il rinfresco delle uscite al termine del ciclo dis cansione.

[JumpMan]

Una piccola dritta:

Invece di sottrarre una costante a tutte le soglie delle cammes, sommala alla quota dell'encoder!

Almeno, io farei così

[batta]

Invece di sottrarre una costante a tutte le soglie delle cammes, sommala alla quota dell'encoder!

In questo modo ti precludi la possibilità di gestire anticipi diversi per ogni attuatore.

P.S. per generare le cammes ho utilizzato una soluzione classica con, dato le poche prestazioni richieste, dei comparatori, gestendo anche il passaggio per lo zero.

Per capire se passare ad una gestione con interrupt (comunque sicuramente più performante) o rimanere alla gestione "normale", devi prima di tutto rilevare i tempi di scansione medi del plc e conoscere l'errore ammesso.

Per capire invece se è necessario gestire gli anticipi, devi conoscere il tempo di reazione degli attuatori e l'errore ammesso.

Modificato: 17 luglio 2009 da batta

[JumpMan]

In questo modo ti precludi la possibilità di gestire anticipi diversi per ogni attuatore.

Oops...té gà rèson !

Modificato: 17 luglio 2009 da JumpMan

[biros66]

Avevo pensato anche io a qualcosa da aggiungere, quindi a creare un asse virtuale in anticpo rispetto al reale, però Batta docet, diventa tutto molto più rigido. In riguardo agli interrupt, il PLC TSX47425 (roba vecchia), forse è un pò tanto limitato. Comunque questo è quanto avevo pensato io

(* Calcolo Anticipo Gradi per variazione di velocità *)

(* Costante calcoli a 25 colpi al minuto *)

Cicli_Secondo := (Cicli_Minuto/60.0);

Ms_Ciclo:= (1000/Cicli_Secondo);

Ms_Grado:=(Ms_Ciclo/360.0);

Tempo_Anticipo:=(Ms_Grado*Ant_Gradi);

Ant_Gradi_Calc:=(Ms_Grado*Tempo_Anticipo);

Val_Anticipo:=Ant_Gradi;

però penso di aver farneticato un pochino.

Adesso provo quanto da voi suggerito

[batta]

In riguardo agli interrupt, il PLC TSX47425 (roba vecchia), forse è un pò tanto limitato.

Prova a reperire documentazione di quel plc.

Non conosco il modello in particolare ma, da quanto ricordo, nei plc serie TSX c'era una task normale ed una task veloce.

Se anche nel tuo modello esiste una task veloce, potresti programmare lì la gestione delle camme.

Guardando i tuoi calcoli mi viene da porre un paio domande:

1) il ciclo macchina è gestito con un encoder o a tempo?

2) come viene impostato il punto di commutazione delle camme?

Forse è meglio se ricominci dall'inizio e descrivi nei dettagli quello che devi realizzare e cosa hai a disposizione per realizzarlo.

[Livio Orsini]

Forse è meglio se ricominci dall'inizio e descrivi nei dettagli quello che devi realizzare e cosa hai a disposizione per realizzarlo.

Sottoscrivo tutto. Se non si hanno tutte le informazioni si rischia di fare inutili giri di pista.

[biros66]

Il TSX47425 ha una task fast che viene gestita con interrupt a tempo, vale a dire che io imposto il tempo di controllo del task fast ed il plc genera ogni tot ms un interrupt per gestire il sottoprogramma.

Torniamo a noi:

ho bisogno di creare delle camme digitali in base alla posizione di un asse rotativo. Il valore dell'angolo è dato da un encoder con risol 360 imp/giro, quindi 1 imp = 1 grado.

Come già accennato ho l'esigenza di gestire un algoritmo di compensazione soglie in funzione della velocità della macchina, che al massimo della prestazione, lavora ad una velocità di 35 cpm (quindi 35 rotazioni dell'asse).

Gli attuatori della macchina sono delle EV pneumatiche festo, con tempo di risposta abbastanza rapido, muovono dei cilindri a corsa breve (max 60 mm).

Io avevo pensato di gestire il tutto in due maniere:

1 - una "sfilza" di comparatori (soluzione "grezza").

2 - un indice che è gestito (come offset) dalla quota encoder.

Secondo la vostra esperienza, io ho utilizzato cammes, ma quasi esclusivamente con moduli dedicati, cosa mi suggerite?

[batta]

Il TSX47425 ha una task fast che viene gestita con interrupt a tempo, vale a dire che io imposto il tempo di controllo del task fast ed il plc genera ogni tot ms un interrupt per gestire il sottoprogramma.

Come ricordavo.

Non ricordo però il tempo minimo impostabile di richiamo della task fast. Se questo tempo è inferiore al tempo di scansione della task mast, ti conviene gestire le camme nella task fast.

Tieni presente che 1 millisecondo alla velocità massima (35 cicli/minuto) corrisponde a 0,21° (0° 12' 36").

Non credo riuscirai a gestire task più veloci di 5ms, che corrispondono ad un errore di circa 1°.

Il punto di attivazione e disattivazione di ogni camma, immagino sarà impostato in gradi.

Per calcolare l'anticipo basta tornare alla formula suggerita da Livio:

ant = k * v

Per quanto riguarda le unità di misura, devi solo scegliere quelle che ti fanno più comodo.

Per esempio: anticipo in gradi e velocità in battute/minuto.

Tutti i calcoli che hai fatto tu per calcolare la durata di un ciclo in millisecondi, per calcolare il tempo di anticipo e quant'altro, sono solo complicazioni in più.

Tutti questi calcoli vengono integrati nella costante k.

Poi, se gli attuatori collegati alle varie camme hanno tempi di risposta molto simili, ti basta una sola costante per tutte le camme; se invece gli attuatori hanno tempi di risposta diversi, dovrai impostare una costante diversa per ogni attuatore.

Per impostare la costante k, puoi procedere come segue:

1) imposti l'angolo di commutazione della camma in modo da ottenere un ciclo corretto alla velocità minima della macchina

2) imposti l'angolo di commutazione della camma in modo da ottenere un ciclo corretto alla velocità massima della macchina

3) calcoli la differenza di velocità e la differenza di angolo impostato

4) calcoli la costante k = DeltaAngolo / DeltaVelocità

Attenzione solo ad una cosa: partendo da una impostazione delle camme fatta alla minima velocità (che non è detto sia bassissima) e non riferita ad un ciclo puramente teorico, la formula iniziale varia come segue:

ant = k * (VelAttuale - VelMinima)

[JumpMan]

Premetto che non ho presente come si programma il tsx, sottrarre una costante a 2 quote per ogni camma, se le camme sono molte, potrebbe risultare lungo, inoltre su ognuno di questi calcoli bisogna controllare di non andare sotto 0...

Io valuterei comunque la soluzione di creare un encoder virtuale per ogni movimento sommando ogni k alla quota encoder (anche qui però bisogna controllare di non superare il 360).

[Livio Orsini]

JumpMan, sottrarre o sommare interi richiede il medesimo tempo macchina, mentre controllare se il risultato della sottrazione è negativo è più veloce che controllare se il risultato della somma è maggiore di "x". Nel primo caso fai il test su di un bit, nel secondo devi controllare il risultato di una comparazione tra due interi.

Però il vero problema di tutta l'operazione non stà in questo particolare. Il vero problema sta nelle condizioni al contorno: variabilità dei ritardi di attuazione, precisione necessaria, tempo di esecuzione del task, etc.

Alla fine potrebbe risultare conveniente impostare 2 o 3 soglie di velocità con due o tre anticipi fissi.

[JumpMan]

nel secondo devi controllare il risultato di una comparazione tra due interi

D'accordo, ma ogni camma ha 2 comparatori, quindi devi mettere il doppio (o più) di istruzioni.

Ripeto che non conosco il plc in questione, e ancora non so se le camme sono 2 o 23, comunque se si vuole tenere basso il tempo di scansione del fast task bisogna inserirci poca roba.

Modificato: 19 luglio 2009 da JumpMan

[Livio Orsini]

D'accordo, ma ogni camma ha 2 comparatori, quindi devi mettere il doppio (o più) di istruzioni.

???

Perchè?

Cam_ant = (Cam-ant) [Camma anticipata = camma - anticipo]

Questa operazione si fa nel task lento ad ogni variazione di velocità maggiore di una certa quantità. Sempre nel task lento verifichi che la camma anticipata sia > 0.

Anzi, molto più correttamente, si dove preparare la tabella o in fase di compilazione o in fase di inizializzazione. La tabella verrebbe aggiornata ad ogni variazione di parametri. All'atto di un comando che effetta una variazione di velocità si andrà a scegliere la colonna più aderente alla velocità di lavoro, sempre nel task lento.

Nel task veloce si compara il valore del contatore con il valore di camma: una comparazione. Se il contatore 0 - 360 è >= al valore di Cam_ant si aziona l'uscita corrispondente.

Questo vale per n camme. Come vedi nel task veloce si esegue la sola comparazione tra il valore reale ed il valore previsto. Se hai 23 camme con 23 anticipi qualunque sia la soluzione scelta dovrai sempre fare 23 confronti.

Nel caso ci siano effetivamente un numero di camme >5 (p.e.) può essere conveniente usare un vettore indicizzato ed effettuare le comparazioni basando il tutto sull'indice. Se la volta precedente si è attivata la camma 3, p.e., poi la comparazione la effettui solo a partire dalla camma 4 e termini alla prima comparazione con risultato falso.

Però bisogna poi verificare se il PLC in uso ti consente simili finezze senza complicarti la vita. Con S7-200 lo puo fare perchè ha istruzioni che trattano agevolmente i puntatori. Con altri può diventare così complicato che il gioco non vale la candela.

Anni fa, con un vecchia S7-216, ho usato una strategia similare. Ho potuto approfittare del registro di comparazione del contatore veloce. Caricavo il primo valore, alla coincidenza il contatore generava l'interrupt e caricavo il valore seguente. Avevo un encoder da 3600 imp/giro con una frequenza di lavoro 500hz <= f <=15.000Hz, 8 camme con precisione +/-3 imp.

Modificato: 19 luglio 2009 da Livio Orsini

[ken]

Penso che JumpMan intendesse due comparatori per camma nel caso sia necessario (come spesso lo è) gestire un angolo di accensione e di spegnimento preciso.

In questo caso poi non è detto che lo stesso anticipo valga per l'attivazione e la disattivazione della camma per le considerazioni che ha fatto batta

[Livio Orsini]

Penso che JumpMan intendesse due comparatori per camma nel caso sia necessario (come spesso lo è) gestire un angolo di accensione e di spegnimento preciso.

Qualunque sia il metodo usato la comparazione la devi fare sempre. Se devi verificare attacco e stacco anche se usi l'encoder virtuale poi la comparazione con l'encoder reale devi comunque farla. Inoltre se hai il preblema della precisione al rilascio, avrai un problema di anticipo variabile anche per il rilascio.

[biros66]

Bene ragazzi, attingo da tutti i vostri consigli, per il momento stò ancora scrivendo l'applicativo.

Domani inizio a provare, partendo dal task fast (5ms) che gestisce le sole cammes. Il resto dovrebbe andare in porto per fine settimana. Sono ben accettai tutte le ulteriori notizie ed idee che vi verranno in mente. Quando la nostra routines funzionerà decentemente, creerò una libreria per codesys.

[ken]

Chiaro Livio, è quello che intendevo e che ho scritto. Era solo una risposta alla tua domanda:

D'accordo, ma ogni camma ha 2 comparatori, quindi devi mettere il doppio (o più) di istruzioni.

Domanda

???

Perchè?

[JumpMan]

Questo vale per n camme. Come vedi nel task veloce si esegue la sola comparazione tra il valore reale ed il valore previsto. Se hai 23 camme con 23 anticipi qualunque sia la soluzione scelta dovrai sempre fare 23 confronti

secondo me devi farne 46 di confronti, le camme devi pure spegnerle no?

[Livio Orsini]

secondo me devi farne 46 di confronti, le camme devi pure spegnerle no?

Non è detto che tudebba fare un confronto, come non è detto che tu debba dare il secondo comando di rilascio. Dipende dall'applicazione. Puoi mettere un tempo fisso di attività dell'attrezzo o adirittura può esserci il fine corsa nell'attrezzo stesso.

Comunque che tu faccia 1 o due comparazioni questo è indipendente dal tipo di metodo usato. Se anche usi un ecoder virtuale dovrai sempre fare il medesimo numero di comparazioni.

[JumpMan]

Ok, la stiamo tirando troppo lunga per delle inutili sottigliezze, sarà che mamma Siemens mi ha sempre abituato a usare tutto con parsimonia e quindi tendo sempre a essere soddisfatto quando riesco a eliminare anche solo un paio di istruzioni da un algoritmo.

Le camme, per come le intendevo io erano tutte a 2 comparatori perchè immaginavo che dovessero attivarsi da angolo x ad angolo y, in quanto sono abituato a vedere questo tipo di macchine costruite con camme meccaniche, molle e bilancieri!

Per questo dicevo che le istruzioni raddoppiano a raddoppiare dei comparatori, perchè devi metterci in ogni comparatore la sottrazione del valore di anticipo (e il controllo di non andare sotto 0), mentre con l'encoder virtuale hai solo una somma (e un controllo di > 360), tutto questo premesso chiaramente che valga lo stesso anticipo per l'accensione e lo spegnimento del movimento e che lo spegnimento sia gestito dalla camma stessa e non da finecorsa o timer come hai detto tu.

Alla fine la soluzione migliore la può ottenere solo chi ha davanti a sè la macchina.

[Livio Orsini]

... perchè devi metterci in ogni comparatore la sottrazione del valore di anticipo (e il controllo di non andare sotto 0), mentre con l'encoder virtuale hai solo una somma (e un controllo di > 360),..

Sto cercando di spiegarti che non risparmi nulla con il coì detto encoder virtuale.

Facciamo l'esempio di una sola camma con medesimo anticipo per l'attacco e lo stacco.

hai due angoli, corrispondenti a due quote di encoder. Che tu sommi una costante all'encoder, spostando in dietro la quota reale, dovrai pur verificare quando questa quota corrisponda alla quota di attacco ed a quella di stacco. Come la verifichi? Non certo per opera dello spirito santo! Dovrai pur farla sta verifica! Se conti in avanti devi usare un comparatore per ogni quota, se conti indietro devi verificare il raggiungimento dello zero e poi caricare il contatore con un nuovo valore. Altri metodi non ce ne sono.

Quello più veloce, se non hai un comparatore interno al contatore con segnalazione di coincidenza ad interrupt é ancora quello di esiguire la sola comparazione nel task veloce.

Può darsi che la vecchiaia e l'alzahimer incipiente non miconsentano di capire la tua invenzione . Prova a spiegare nel dettaglio come fai a rilevare le coincidenze senza far comparazioni. Potrei imparare qualche cosa di nuovo.