Camme Encoder Con S7-300

[cmcg]

Ciao a tutti,

ho una CPU 315-2DP e un encoder incrementale che leggo via Profibus.

Devo realizzare alcune camme, ovvero a determinati valori di conteggio devo eseguire delle operazioni.

Normalmente verifico nel programma, una volta arrivato a conteggio, quando attivare le camme, ma così facendo sono soggetto al tempo di ciclo ed ogni singola camme non capita sempre nel medesimo momento.

Mi chiedo se esista un metodo più preciso, magari sfruttando un interrupt.

Ma non so se si possono generare interrupt lanciati da confronti su lettura via Profibus.

Spero di essermi spiegato

Ringrazio fin d'ora per ogni risposta.

[mubeta]

Non credo si possa generare un interrupt.

Semplicemente, ti crei, possibilmente nell'area M, una tabella compilata, (ti farai una idonea funzione di compilazione), che per ogni byte, word o dword della tabella, (a tua libera scelta), contiene i valori delle camme; quindi per ogni valore letto dall'ecoder il programma pesca dalla tabella l'area relativa e la trasferisce in un byte/word/dword di lavoro, dove ti trovi i bit settati a dovere. E' un programmino leggero e veloce se usi l'area M.

Ad esempio, ti occorrono non più di otto camme, allora ti basta il byte come word di riferimento. Poi diciamo che sul giro di bastano 256 punti, allro dedichi dell'area M, ad esempio, il MB125 come word di lavoro, mentre dal MB126 al MB382 li usi come area delle word di camme.

Dovrai scrive una funzione che, per ognuna delle otto camme, dato il punto di ON ed in punto di OFF come parametri esterni (magari da pannello), mette a 0 od a 1 i bit di ciascuno dei merker nell'area. (Parte di programma che richiami solo all'atto della compilazione e quindi non pesa sul tempo ciclo).

Ora, a tabella copilata, per ogni ciclo programma, dato il valore letto dall'encoder, sommato all'offset di 126 per puntare al MB corretto, si trasferisce il byte in MB125, ed ecco che i bit da M125.0 ad M125.7 corrispondono alle camme da te desiderate.

mubeta.

[Livio Orsini]

Normalmente verifico nel programma, una volta arrivato a conteggio, quando attivare le camme, ma così facendo sono soggetto al tempo di ciclo ed ogni singola camme non capita sempre nel medesimo momento.

Ci sono differenti metodi per saltare la dipendenza dal tempo di ciclo.

Il più semplice è quello di inserire in OB1 parecchi richiami alla funzione che compara il valore di encoder con la tabella delle camme. Ovviamente anche la lettera della periferica profibus deve essere effettuata indipendentemente dal ciclo di programma; ora non ricordo se è possibile, bisognerebbe verificare sul manuale.

Altro metodo potrebbe essere quello di generarare un interrupt a tempo, 10 ms p.e., tramite OB35 ed effettuar il confronto encoder-tabella; ovviamente sempre leggendo direttamente la periferia profibus.

[mubeta]

Generare delle camme con degli OB a tempo è rischioso, essendo questi "asincroni" rispetto al resto del programma, rischi di trovarti condizioni che cambiano nel mezzo del ciclo di scansione. Questa tecnica ha sempre dato risultati deludenti con camme che comportano l'interazione col resto della logica.

Un programma scritto bene, leggero e veloce, è sempre la soluzione più migliore.

Per il tipo di CPU che citi, un tempo ciclo di 5 ms è tanto, e le camme risultanti sono soddisfacenti e precise.

Il consiglio di Orsini non è da scartare, ma, generata la camma, attui una uscita dallo stesso OB a tempo, senza logica da essa dipendente nel ciclo dell'OB1.

[cmcg]

Dovrai scrive una funzione che, per ognuna delle otto camme, dato il punto di ON ed in punto di OFF come parametri esterni (magari da pannello), mette a 0 od a 1 i bit di ciascuno dei merker nell'area. (Parte di programma che richiami solo all'atto della compilazione e quindi non pesa sul tempo ciclo).

Per mubeta: Non capisco "richiamo solo all'atto della compilazione e quindi non pesi sul tempo di ciclo" .

La funzione che mi genera le camme l'ho fatta con un FC al quale passo la misura attuale dell'encoder, la quota di ON e la quota di OFF. Dove mi serve una camme nel programma semplicemente lo richiamo e lui mi restituisce il bit di risultato.

In ogni caso è vero che si possono trovare scorciatoie o modi per alleggerire il programma, ma in ogni caso la mia camme è soggetta al tempo di ciclo.

Forse avrei dovuto non andare via Profibus ma usare un FM350 per sfruttare i suoi interrupt? (Limitato a 8 camme ovviamente)

[Livio Orsini]

Generare delle camme con degli OB a tempo è rischioso,...

No se si fanno bene i conti e si determina a priori se è possibile o no. Dipende dalla frequenza di conteggio e dal tempo di campionamento. Per esempio con campionamento a 5ms ho la sicurezza di poter individuare le transizioni provocate da un clock a 100Hz; per frequnze maggiori non ho la sicurezza di individuare la transizione. Poi dipende dall'erore che mi ammette la camma. Se ad esempio la camma ammettesse la possibilità di errore di 10 impulsi potrei salire con la frequenza di clock e rimanere entro i limiti.

cmcg Devi farti i conti considerando quello che ho scritto prima. Questo vale sia per tempi fissi e precisi, sia per tempi legati al ciclo di programma. Anche se tu riuscissi a far campionare, per esempio, il tuo contatore ogni 0.5 ms avresti un limite di 1 kHz di frequenza massima di clock, a meno di ammettere alcuni clock di errore.

Se non riesci a rientrare in queste specifiche l'unica soluzione è un conteggio con FM350 o altre periferiche simili. In questo caso la comparazione la fa direttamente la periferica generando un interrupt.

Potresti pensare all'uso di ST22x collegati in profibus con la CPU master; però il discorso diventa complesso.

[mubeta]

Non capisco "richiamo solo all'atto della compilazione e quindi non pesi sul tempo di ciclo"

La mia opinione si riassume così: un programma scritto bene, leggero e veloce, è sempre meglio di un programma "disturbato" da degli interrupt.

Come ci si arriva?

- meno uso possibile delle DB, e massimo sfruttamento dell'area M;

- meno uso possibile di accessi alla periferia P, e mappatura di tutti gli I/O in memoria immagine;

- meno uso possibile di istruzioni a parola, se possibile uso di singoli bit.

(con tutti i contro del caso, sto ragionando sui tempi).

Da qui il mio suggerimento: tu hai un programma che ad ogni ciclo di OB1 fà dei confronti su WORD o DWORD per stabilire se si è o meno in zona camma. Io ti suggerivo invece di compilare una tabella, (o array di merker se preferisci), con tutte le camme già scritte in una word dedicata per ciascuno dei punti elementari del giro macchina, (o ruota se preferisci). In questo modo, nel tuo programma, invece di fare due confronti, (considera da te quante sono le operazoini a parola), devi "solo" puntare alla word relativa al valore encoder e trasferirla nella word di lavoro. E' un suggerimento che rende già se hai una sola camma; se ne hai più di una è un suggerimento indubbiamente valido.

No se si fanno bene i conti e si determina a priori se è possibile o no.

Se il tempo ciclo OB1 è molto più lento dell'OB a tempo, ti ritroverai degli eventi che mutano con OB1 in corso; cose del tipo M12.1 (esempio), che era inizialmente a 0, va poi ad 1 per via dell'OB a tempo, in chissa quale punto del programma OB1, per, magari tornare a 0 nello stesso ciclo di OB1. Nel frattempo l'uso dell'interrupt ha certamente rallentato ulteriormente OB1;

Se il tempo ciclo OB1 è poco più lento del tempo di campionamento richiesto, vale la pena migliorare e snellire il programma piuttosto che aggiungere ulteriori ritardi;

Ma se i problemi della camma elettronica sorgono per un tempo di scansione variabile di qualche millisecondo, forse è da rivedere anche il sistema macchina.

Non conosco l'applicazione specifica, ma una camma, in fin dei conti, controlla poi un attuatore, o un sensore per controlli incrociati; conosciamo i tempi ciclo di una 315, e, se non si riesce a fare una camma simile io vedo tre ragioni:

- tempi ciclo OB1 che si allungano troppo;

- si richiede un lavoro non adatto alla CPU;

- il sistema non è progettato bene.

Aggiungo una ultima osservazione in merito all'encoder: tipicamente per queste applicazioni ho fatto usare encoder gray con i singoli bit collegati ad I/O del PLC; l'encoder profibus, (provato solo uno Siemens, abbandonando subito la strada), fatte alcune prove, (senza esami approfonditi), mi è sembrato lento, non tanto per la lettura immediata con PEW rispetto all'immagine EW, piuttosto che il valore da esso restituito non sembrava essere immediatamente aggiornato, ma sempre in ritardo. Fatti tutti i conti, tempi elaborazione programma, mi sarei dovuto trovare un errore, nel mio caso di 6 mm massimi, ma ne trovaso sempre 15 mm / 20 mm. Problema risolto appunto passando ad un encoder gray con uscita a singoli bit. La logica non l'ho cambiata; la meccanica era quella... evidentemente l'encoder profibus ha una sua eletronica che aggiunge ulteriori ritardi non valutabili.

[Livio Orsini]

Se il tempo ciclo OB1 è molto più lento dell'OB a tempo, ti ritroverai degli eventi che mutano con OB1 in corso; cose del tipo M12.1 (esempio),..

Forse c'è un poco di confusione.

Se si usa un interrupt a tempo, che l'intero tempo di ciclo aumenti è di evidenza solare; questo fatto non ifluenza il processo che si vuol controllare a tempo fisso, tramite in iterrupt temporizzato. Che poi si riesca ad ottenere, o meno, il controllo voluto dipende esclusivamente dai tempi necessari.

La mia opinione si riassume così: un programma scritto bene, leggero e veloce, è sempre meglio di un programma "disturbato" da degli interrupt.

Anche qui mi permetto di dissentire.

Per prima cosa un programma deve (dovrebbe) esssere sempre ben fatto! Un programma progettato e scritto a "regola d'arte" è, per difinizione, ottimizzato o per lunghezza di codice, o per velocità di esecuzione. La scelta del tipo di ottimizzazione dipenderà dai vincoli di sistema. Oggi giorno, stante la quantità di memoria disponibile, si ottimizza quasi esclusivamente per velocità di esecuzione.

Purtroppo molto, troppo, spesso i programmi dei PLC assomigliano più ad un ammasso informe di istruzioni, gettate a casaccio ed adattate a martellate al problema chi si sta tentando di risolvere. Questo perchè molti programmatori di PLC non hanno basi teoriche di programmazione.

Un interrupt non è un disturbo! Un interrupt, se usato correttamente ed a proposito, è una funzione specificamente prevista per risolvere determinati problemi. E' talmente vero che, anche se non sono stati usati nell'applicativo, di interruzioni di programma ce ne sono parecchie durante il ciclo dell'applicazione. l'applicazione è solo una parte, visibile, di tutto quanto "gira" sulla CPU. Basti solo pensare alla comunicazione con il bus di campo, alla comuniczione con i dispositivi HMI e via elencando.

In conclusione un programma per essere scritto bene deve prima essere progettato bene. Se questa sequenza è rispettata si otterrà, seil progettista ne è capace, un programma ottimizzato, comprensibile ed esportabile, con o senza l'eventuale necessità di usare interruzioni.

Modificato: 28 aprile 2010 da Livio Orsini

[mubeta]

Orsini, sono ormai OT, ma concedimi una ultima replica, visto che l'attacco è stato abbastanza diretto.

Quello che scrivi ha tutto senso, è vero... sappiamo come funziona una CPU, ecc.

A mio avviso ti sei però allontanato da quanto ho affermato:

essendo questi "asincroni" rispetto al resto del programma, rischi di trovarti condizioni che cambiano nel mezzo del ciclo di scansione.

Non voglio fare teoria dei microprocessori e dei segnali periodici. Stavo dicendo: attenzione ad usare l'interrupt, può dare più problemi che benefini.

Se il tempo ciclo OB1 è molto più lento dell'OB a tempo, ti ritroverai degli eventi che mutano con OB1 in corso; ...

Se il tempo ciclo OB1 è poco più lento del tempo di campionamento richiesto ...

Facevo osservare che bisogna indubbiamente fare delle valutazioni.

L'intrerrupt "diventa" un disturbo se usato male, poi, come scrivi tu: i programmi dei PLC assomigliano più ad un ammasso informe di istruzioni, gettate a casaccio ed adattate a martellate al problema chi si sta tentando di risolvere infatti si vedono qua e la nei programmi istruzioni di disabilitazione e ribilitazione interrupt per ovviare ai problemi che citavo più sopra ed in altri post, in questo thread.

Chiudo con quanto ho già detto: se delle camme elettroniche, che comandano tipicamente attuatori o fanno dei controlli, non si riescono a gestire con una 315, nel ciclo OB1, bisogna analizzare più a fondo il sistema. Ci sarebbe parecchio altro da dire, ma troveremo il thread più opportuno.

[cmcg]

Non voglio entrare nel merito della discussione sugli interrupt, ma torno al mio problema.

Per le macchine che ho fatto fin'ora ho usato un encoder assoluto (non incrementale) gestito via Profibus per fare le camme (ho una macchina rotativa)

Pensavo per le prossime di mettere un encoder incrementale (letto da FM350 o addirittura una CPU 314) e un proxy di azzeramento.

Cosicché ad ogni giro azzero l'encoder.

Usando però una FM350 o una CPU posso gestire ad interrupt le camme (che poi a conti fatti me ne servono 3 o 4) e anche l'azzeramento lo posso mettere sull'ingresso di gate.

E' ovvio che il resto del programma potrebbe appesantirsi ma non è rilevante al fine del funzionamento, ma a me preme avere delle camme precise.

Credo che questa sia la soluzione migliore, cosa ne pensate?

[Livio Orsini]

Pensavo per le prossime di mettere un encoder incrementale..

C'è una scheda Siemens, di cui al momento non ricordo la sigla FM3xx, che è specifica per la gestione di camme. Se passi ad altra soluzione, ti consiglio di considerare, per prima cosa, l'impiego di questa scheda.

sono ormai OT, ma concedimi una ultima replica, visto che l'attacco è stato abbastanza diretto

Non siamo propriamente OT ma, al più border line; poi non c'è nessun attacco, solo una differenza di opinione, magari acuita proprio dal mio retroterra basato più sull'uso di micro controllori che su PLC.

essendo questi "asincroni" rispetto al resto del programma, rischi di trovarti condizioni che cambiano nel mezzo del ciclo di scansione.

Questo non è rilevante, anzi! Gli interrupts si devono usare proprio per gestire eventi asincroni, altrimenti non ci sarebbe necessità di questa funzione.

Ti posso garantire che nella mia oramai quarantennale (eh si son proprio vecchio) esperienza non ho mai avuto problemi del genere. Probabilmente perchè uso progettare il sistema e non scrivere istruzioni così ad libitum. Quanto poi a disabilitare ed a riabilitare le interruzioni non è detto che sia per cattiva programmazione, anzi a volte è proprio indice di corretta programmazione; dipende sempre da come e da che cosa.

Non voglio fare teoria dei microprocessori e dei segnali periodici. Stavo dicendo: attenzione ad usare l'interrupt, può dare più problemi che benefini.

CITAZIONE

Se il tempo ciclo OB1 è molto più lento dell'OB a tempo, ti ritroverai degli eventi che mutano con OB1 in corso; ...

CITAZIONE

Se il tempo ciclo OB1 è poco più lento del tempo di campionamento richiesto ...

Facevo osservare che bisogna indubbiamente fare delle valutazioni.

L'unico problema che può nascere dall'uso di un interrupt a tempo è legato a due condizioni: la frequenza dell'enterruzione ed il tempo occupato della routine di servizio.

Chiarisco con un esempio. Se si ha un'interruzione ogni 5 ms e la routine di servizio occupa 4ms rimane solo 1ms di tempo CPU per gestire tutto il restante programma. In altri termini la parte ad interrupt monopolizza lo 80% delle risorse

[batta]

C'è una scheda Siemens, di cui al momento non ricordo la sigla FM3xx, che è specifica per la gestione di camme. Se passi ad altra soluzione, ti consiglio di considerare, per prima cosa, l'impiego di questa scheda.

Concordo in pieno, anche perché il costo di questa scheda non è esagerato: a listino 764,52 € contro i 404,06 € di una FM350-1.

La scheda in questione è la FM352 (6ES7352-1AH02-0AE0).

Le principali caratteristiche sono le seguenti:

4 DI

13 DO

Encoder incrementale (simmetrico) con differenziale 5V, con frequenza massima 1MHz

Encoder incrementale (asimmetrico) 24V, con frequenza massima 50kHz

Encoder assoluto (SSI) codice Gray, con frequenza massima 1MHz

Altre caratteristiche (da catalogo elettronico Siemens CA01):

32 tracce di camma;

13 addotte direttamente ad uscite digitali on-board.

Numero di camme parametrizzabili;

a seconda della parametrizzazione, sono disponibili 32, 64 o 128 camme.

Caratteristiche delle camme parametrizzabili;

le camme sono definibili come camme di posizione o come camme di temporizzazione. Esse possono essere parametrizzate in funzione della direzione (avanti/indietro).

Assegnazione parametrizzabile delle camme alle uscite digitali;

le uscite di traccia ”0” e ”1” sono parametrizzabili come camma di conteggio, l’uscita di traccia ”2” come camma di frenatura.

Funzioni speciali

Misura di lunghezza

Impostazione del punto di riferimento

Impostazione del valore istantaneo

Impostazione del valore istantaneo al volo

Spostamento dell'origine

Modifica dei fronti di camma

Funzionamento di simulazione

Funzionamento

Il velocissimo blocco programmatore a camme elettroniche FM 352 rileva mediante un encoder le posizioni su un asse controllato ed attiva corrispondenti azioni di comando attraverso uscite dirette on-board.

L’FM 352 funziona autonomamente una volta immessi i dati di macchina e i dati delle camme. Tra CPU e FM 352 vengono scambiati quindi solo segnali di comando e di retrosegnalazione.

L’unità di programmazione a camme elettroniche funziona a velocità assai elevata:

13 uscite digitali per le tracce delle camme;

per il rapido inoltro dei segnali di comando al processo.

Spostamento dinamico dipendente dalla velocità per ogni camma; per la compensazione automatica del tempo morto dell'attuatore collegato.

Gli attuatori da comandare possono essere collegati direttamente all’FM 352. Contattori ausiliari sono necessari solo per attuatori ad elevato assorbimento di corrente.

Le funzioni integrate più interessanti, a mio avviso, sono le seguenti:

Spostamento dell'origine

Funzionamento di simulazione

13 uscite digitali per le tracce delle camme

Spostamento dinamico dipendente dalla velocità per ogni camma per la compensazione automatica del tempo morto dell'attuatore collegato.