Misurare La Velocità Di Una Ruota Dentata Contanto Gli Impulsi

[virgolanera]

Salve, io dovrei misurare la velocità di un albero rotativo, che ha una ruota con 20 denti. Ho un sensore che mi manda un impulso ogniqualvolta che un dente della ruota dell'albero passa davanti al sensore. Secondo quanto consigliatomi dall'assistenza di vipa, sto usando il contatore integrato nella cpu (vipa 314) con il metodo Impulse/direction in continue counting. In questo modo però ho un conteggio incrementale. Ovvero il valore degli impulsi si accumula e non mi serve a nulla. Io vorrei avere solo il numero degli impulsi al secondo. Ho provato col metodo Rotary Econder Single, ma in questo modo, mi da solo il valore 1 quando ho in impulso. Quindi nulla di quanto cercavo.

C'è qualcuno che è ferrato nell'argomento?

Grazie anticipatamente

[pigroplc]

crei un timer con base di tempi di un secondo

ogni volta che il timer scatta fai la sottrazione / somma tra il numero di impulsi attuale e il precedente

memorizzi il numero di impulsi attuale nel precedente

pigroplc

[virgolanera]

pigroplc..il concetto piu o meno è chiaro..la realizzazione un po meno.. (anche se non mi aspettavo di dover fare un "trucchetto" del genere).

Mi viene qualche dubbio..come faccio a far girare di continuo il timer? con una sorta di autoreset? Oppure utilizzo un OB35 (ad. es) e ogni volta che si autoresetta memoriozzo il valore in qualche variabile d'appoggio?

dopo di che, va bene, faccio la differenza fra il valore attuale e quello vecchio e i vari calcoli che ne conseguono ed ho la frequenza e la velocità.. pero è la prioma parte che non mi è chiara.. fra timer e OB, autoreset, etc... non è che saresti cosi gentile da postare un esempio?

grazie infinite

ps: se non si è capito, sono alle prime armi con step7..

Modificato: 15 luglio 2010 da virgolanera

[virgolanera]

allora.. per ora ho fatto in questo modo:

leggo il valore che mi arriva dal contatore integrato nella cpu (che viene salvato in una ped)

oggni due decimi di secondo (per prova..poi se va bene andrà velocizzato) salvo un valore di questo conteggio, utilizzando l'OB32 (impostato appositamente a due decimi), in una variabile.

In un'altra funzione, prima converto i valori da ped a real poi faccio la differenza fra il valore corrente e quello salvato ogni due decimi di secondi. Divido la differenza per il numero di denti (è una ruota dentata, ogni volta che un dente passa davanti al sensore da un impulso). La moltiplico per 5, e ottengo in giri al secondo. Per 60 e ottengo i giri al minuto che è quello che cercavo.

Però non ho ancora la controprova che il valore che ottengo sia corretto. Secondo voi è corretta la procedura?

Grazie

[pigroplc]

Si è capito che sei alle prime armi:

crea un blocco con questo codice

UN M 0.0

L S5T#1S

SE T 1

U T 1

= M 0.0 // ONE SHOT AL SECONDO

U M 0.0

SPB SHOT

SPA END

SHOT: L COUNTER // AGGIORNA IL NUMERO DI IMPULSI

T MD 100 // NELLA MEMORIA AUX

L 0 // QUINDI AZZERI IL COUNTER

T COUNTER

END: NOP 0

devi solamente sostituire l'operando COUNTER con il contatore che tu vedi.

pigroplc

[virgolanera]

Grazie mille per la risposta. Adesso proverò a fare come mi hai consigliato. Nel frattempo, come ho scritto sopra, ho fatto in maniera leggermente diversa. Mi chiedo se sia più corretto o pulito utilizzare un timer che si resetta di continuo o usare l'OB. La mia è ovviamente una domanda da inesperto.

[batta]

La soluzione proposta da "pigroplc", onestamente, non mi piace molto.

Prima di tutto, non ha senso creare un clock di un secondo con un timer (che così sbaglierà sempre del tempo di una scansione) quando si hanno a disposizione i merker di clock o, ancora meglio, gli OB a tempo.

Poi non è che basti scrivere zero nel valore corrente del contatore per ottenerne l'azzeramento.

Il valore di conteggio si legge su una PED e per azzerarlo si deve dare il comando specifico al contatore.

Ma il bello è che non serve nemmeno effettuarlo, questo azzeramento.

Ma c'è da dire anche che i contatori veloci a bordo delle cpu S7-31xC possono essere configurati anche come misura di frequenza.

Qui si parla di una cpu VIPA, che non conosco, ma che dovrebbe essere molto simile alle cpu S7-300.

Quindi, se anche nel plc VIPA si può configurare il modulo per la misura di frequenza, questa è sicuramente la strada che permette di ottenere il miglior risultato col minimo sforzo: basta, in configurazione hardware, impostare "Misura di frequenza", il tipo di segnale (nel tuo caso "Impulso/direzione"), il tempo di integrazione (di default 100ms, da aumentare se si desidera maggior precisione nel caso di frequenze basse) e, da programma, aprire il gate.

Nella PED si legge direttamente la frequenza. Basta poi un semplicissimo calcolo per convertirla in giri/minuto.

Nel caso nella cpu VIPA non ci fosse la possibilità di impostare il contatore per la misura di frequenza, la strada giusta è quella dell'OB a tempo.

L'impostazione del tempo dell'OB dipende dalla frequenza, e dovrebbe essere il giusto compromesso tra precisione e velocità di aggiornamento della lettura.

A parte la questione tempo, il metodo non cambia:

- imposti in questo caso il contatore per conteggio continuo

- ad ogni esecuzione di OB35 esegui le seguenti operazioni:

L PED_ValoreAttualeConteggio //Lettura valore corrente contatore veloce

T DW_VarLocaleAppoggio //Appoggio lettura a variabile locale

L DW_LetturaPrecedente //Precedente lettura

- D

= DW_Impulsi //Numero impulsi letti dal precedente controllo

L DW_VarLocaleAppoggio //Ricarica la lettura del conteggio veloce

T DW_LetturaPrecedente //Memorizza la lettura del conteggio veloce

Con questo metodo non devi nemmeno pensare a gestire l'overflow del conteggio perché, configurato come conteggio continuo, una volta superato il valore massimo di conteggio, il conteggio continua poi dal valore minimo. Il risultato della sottrazione anche a cavallo di questo passaggio sarà sempre corretto.

Anzi, se tra una lettura e l'altra non superi 32767 impulsi, puoi anche leggere solo la word bassa del contatore veloce e utilizzare tutte word al posto di dword per i calcoli.

E' però di importanza fondamentale che eventuali conversioni in REAL vengano effettuate a partire dal risultato del calcolo, e non sul valore del contatore veloce.

L'unica altra accortezza, visto che al riavvio della cpu il conteggio riparte da zero, è di effettuare l'azzeramento (in OB100) della variabile utilizzata per memorizzare la lettura precedente, nel caso questa variabile sia ritentiva (per esempio, variabile di un DB).

Ottenuti gli impulsi contati in un tempo noto, la conversione in giri/minuto è banale.

Modificato: 15 luglio 2010 da batta

[virgolanera]

Ti ringrazio per la risposta molto esaustiva. Come hai immaginato questa cpu vipa non ha a disposizione la misurazione di frequenza diretta, ma va calcolata. Ho usato piu o meno la procedura da te descritta.

Una domanda: faccio la differenza fra i due valori PED (attuale e precedente), e poi faccio la conversione in real. E' corretto? In questo modo posso ottenere il valore effettivo dei giri/minuto? (Considera che devo calcolare esattamente i giri di un albero motore rotante).

Infine, l'ultimo passaggio, ovvero proprio il calcolo banale, per ottenere il "num.giri/minuto" va sempre fatto all'interno dello stesso OB a tempo, giusto?

[batta]

Come hai immaginato questa cpu vipa non ha a disposizione la misurazione di frequenza diretta, ma va calcolata.

Peccato. Comunque poco male: ti basta configurare il modulo per conteggio continuo, lascia perdere eventuali sincronizzazioni o altre impostazioni che non ti servono, dai da programma il comando di apertura del gate (lo puoi fare anche una sola volta in OB100) e poi del modulo di conteggio te ne puoi pure dimenticare.

Con le poche istruzioni viste prima messe in OB35 ottieni praticamente lo stesso risultato.

Se dai indicazioni sulla velocità di rotazione minima e massima dell'albero e sulla precisione richiesta, si potrebbero fare anche considerazioni sul tempo di campionamento corretto.

faccio la differenza fra i due valori PED (attuale e precedente), e poi faccio la conversione in real. E' corretto?

Se usi il metodo da me descritto sì, la conversione in real (ammesso che serva) la devi assolutamente fare dopo il calcolo del numero di impulsi.

Questo, oltre ad essere concettualmente il procedimento più corretto, è anche indispensabile per evitare di dover gestire il passaggio del valore di conteggio dal valore massimo positivo al valore massimo negativo.

Infine, l'ultimo passaggio, ovvero proprio il calcolo banale, per ottenere il "num.giri/minuto" va sempre fatto all'interno dello stesso OB a tempo, giusto?

All'interno dell'OB a tempo è indispensabile fare la lettura degli impulsi. Una volta acquisiti gli impulsi in maniera il più precisa possibile, il calcolo lo puoi fare dove meglio credi.

Anzi, di solito si preferisce mettere negli OB a tempo solo lo stretto indispensabile, in modo da non appesantirli e rendere la loro esecuzione il più rapida possibile, specialmente quando il loro richiamo avviene con tempi molto brevi.

Nel caso specifico, con un calcolo molto semplice da eseguire e un richiamo dell'OB a tempo con tempo molto più lungo di quello di scansione, se ti fa comodo lo puoi tranquillamente inserire nell'OB stesso.

Ma, ripeto, non è assolutamente indispensabile.

In ogni caso, per semplificare il calcolo, anziché fare una moltiplicazione per ricavare gli impulsi/secondo, poi un'altra moltiplicazione per ricavare gli impulsi/minuto ed infine una divisione per ricavare i giri/minuto, puoi riassumere questi tre calcoli in un'unica costante e cavartela con una sola moltiplicazione.

Addirittura, con i numeri che ti ritrovi, non hai nemmeno bisogno di fare calcoli in virgola mobile.

Rimanendo nell'esempio del campionamento ogni 200ms, per passare da impulsi letti ad ogni campionamento a giri/minuto dovresti fare N_Impulsi * 5 * 60 / 20. Ma questo numero è un bel 15 tondo tondo.

Se non devi prevedere la possibilità di cambiare il numero di denti della ruota (con l'eventualità quindi di dover gestire numeri frazionari), con una semplice moltiplicazione tra interi te la cavi.

Per finire...

Nel mio esempio effettuo la lettura del valore corrente di conteggio e la appoggio ad una variabile che utilizzo in seguito per memorizzare il valore.

Si potrebbe pensare di rileggere il valore corrente, senza utilizzare la variabile di appoggio. Questo però potrebbe introdurre degli errori (seppure minimi) dovuti al fatto che la lettura di una PED (lo stesso vale per PEB e PEW) non si basa su un'immagine, ma avviene all'istante. La lettura della stessa PED due volte, seppure a distanza di sole poche istruzioni, potrebbe dare valori diversi.

Soluzione alternativa all'utilizzo della variabile di appoggio sarebbe l'uso dell'istruzione TAK, che scambia il contenuto dei due accumulatori.

[pigroplc]

Per Batta:

mi rendo conto che la soluzione abbozzata in 2 minuti ritagliati al mio lavoro può non piacere, ma non conoscendo la CPU Vipa in questione mi ero completamente svincolato da qualsiasi OB a tempo, stesso dicasi per il discorso del conteggio.

Per Virgolanera:

visto che stai facendo pratica, prova in vari modi e confronta i risultati...

pigroplc

[virgolanera]

Riassumendo: ho impostato in configurazione harwdare l'"Impulse/direction" con conteggio continuo.

Poi nell'OB35 (che nel mio caso cicla a 200ms) ho:

L PED 116 // leggo il valore dal modulo di conteggio

T #temp // lo salvo in una variabile dw locale

L #val_pre // carico il valore precedente

-D

T "velocita".conteggio // la differenza fra il valore attuale e quella precedente, appoggiata in una variabile di un db

L #temp // carico il valore attuale nella variabile contenente il valore precedente

T #val_pre

In un'altra funzione invece ho il calcolo:

L "velocita".conteggio

T #temp // dove temp è una variabile real

NOP 0

L #temp

L 1.500000e+001 // num.impulsi * 5 * 60 / 20

*R

T #risultato

NOP 0

La velocità con la macchina in fuzione sarà sui 250 giri al minuto. In rampa di salita andrà da zero a 250 nell'arco di circa un minuto. Anche se su questo ancora non ne posso essere sicuro.

Mi sembra che ci sia tutto...

[batta]

Premesso che, come detto precedentemente, per moltiplicare x15 non hai bisogno di utilizzare calcoli in virgola mobile, se proprio vuoi seguire la strada dei REAL, ti manca una istruzione fondamentale: la conversione da DINT a REAL.

Copiare una variabile dichiarata DINT in una dichiarata REAL non effettua la conversione.

Devi scrivere:

L "velocita".conteggio //Carica nell'accumulatore il numero di impulsi (DINT)
DTR                    // Converte il contenuto dell'accumulatore da DINT a REAL
L 1.500000e+001       // num.impulsi * 5 * 60 / 20 (costante di conversione)
*R                    // Effettua moltiplicazione in virgola mobile
T #risultato         // Risultato in formato REAL

La velocità con la macchina in fuzione sarà sui 250 giri al minuto. In rampa di salita andrà da zero a 250 nell'arco di circa un minuto. Anche se su questo ancora non ne posso essere sicuro.

Siamo su velocità decisamente bassine.

Già al massimo, nei 200ms del tuo attuale tempo di campionamento, rileveresti solo 250*20/60/5 = 16,7 impulsi.

A volte leggeresti 16, altre volte 17, con una lettura poco precisa e poco stabile.

Viste le basse velocità e anche la lenta variazione della velocità stessa, io porterei il tempo di campionamento minimo minimo ad 1 secondo.

Se vuoi maggiore precisione senza rallentare la lettura, fai sostituire la ruota dentata con un encoder da almeno 1000 imp/giro.

A 250giri/minuto ti troveresti con una frequenza di circa 4kHz, che ti permetterebbe di effettuare una misura rapida e precisa.

Per "pigroplc"

Guarda che la mia non era una critica.

Ho solo mostrato una procedura più corretta, adatta a quel particolare plc.

Modificato: 16 luglio 2010 da batta

[virgolanera]

Posto la versione corretta. O meglio che dovrebbe essere corretta. Ma che evidentemente qualche problema ce l'ha.. perche non riesco ad ottenere un valore stabile. La misura balla troppo, oscilla eccessivamente. E poi non combacia con quello che dice la pistola ottica che misura i giri.

Altra correzione. La velocità arriva a 1000 giri e non a 250. (intorno ai 300 gira la turbina associata all'albero del generatore che ha un fattore di moltiplicazione di 3,6)

Nell'OB35 che ora ho impostato a un tempo di ciclo di 1 secondo:

L PID 116

T #val_temp

L #val_prec

-D

T #conteggio_imp

L #val_temp

T #val_prec

L #conteggio_imp

T "var rav".conteggio

Nell'OB1 invece:

L "var rav".conteggio

DTR

L 3.000000e+000 // conteggio * 60 / 20

*R

T #risultato // velocità dell'albero (max 1000 giri)

L 3.623000e+000

/R

T #risultato2 // velocità della turbina

Vedete qualcosa di clamorosamente sbagliato??

[virgolanera]

Per fare una prova..avevo l'albero che girava (secondo la pistola) a circa 140 giri al minuto.

Io leggevo circa un 70 nel valore del conteggio degli impulsi che corrisponde quindi a un 210 giri/min...

E inoltre la cosa che mi preoccupa è che il valore è troppo ballerino. Gli impulsi cambiamo continuamente da 60 a 70 a 80, ciclando...ovvero la velocità quindi varia intorno ai 200 giri/min. Con oscillazioni veramente troppo grandi..

[Gapo]

Per fare una prova..avevo l'albero che girava (secondo la pistola) a circa 140 giri al minuto.

Io leggevo circa un 70 nel valore del conteggio degli impulsi che corrisponde quindi a un 210 giri/min...

E inoltre la cosa che mi preoccupa è che il valore è troppo ballerino. Gli impulsi cambiamo continuamente da 60 a 70 a 80, ciclando...ovvero la velocità quindi varia intorno ai 200 giri/min. Con oscillazioni veramente troppo grandi..

per esperienza personale, i conteggi di velocità fatti in questo modo sono mediamente un disastro...

non basta saper scrivere l'algoritmo di calcolo e avere una CPU con l'ingresso "contatore veloce", perché bisogna anche vedere quant'è affidabile il segnale che arriva alla CPU. Per esempio, che sensore stai usando?

[virgolanera]

Per esempio, che sensore stai usando?

Guarda adesso sono a casa e non mi ricordo il nome dello strumento. comunque è un sensore induttivo di prossimità. Quando gli passa davanti il dente della ruota, mi manda un impulso, che ricevo nel contatore integrato della cpu vipa.

All'inizio era stato montato troppo lontano dalla ruota dentata, e non mi mandava alcun segnale. Mi insinui il dubbio che il problema possa essere anche hardware??

[virgolanera]

i conteggi di velocità fatti in questo modo sono mediamente un disastro...

non avendo a disposizione una scheda di acquisizione veloce, come ero abituato in altri ambienti, ed essendo il mio prmo progetto su step 7, e la prima volta che uso schede vipa, non conosco altre strade per rggiungere questo obbiettivo.. inoltre ormai devo trovare una soluzione praticamente subito...

[Gapo]

Guarda adesso sono a casa e non mi ricordo il nome dello strumento. comunque è un sensore induttivo di prossimità. Quando gli passa davanti il dente della ruota, mi manda un impulso, che ricevo nel contatore integrato della cpu vipa.

All'inizio era stato montato troppo lontano dalla ruota dentata, e non mi mandava alcun segnale. Mi insinui il dubbio che il problema possa essere anche hardware??

Decisamente si...

Usando un proximity, se lo tieni troppo vicino rischi di perdere i "buchi", se lo allontani rischi di perdere i "denti". Trovare la giusta misura è quasi impossibile, perché poi anche la velocità influisce sulla rilevazione... Senza contare che (a seconda del modello) potrebbe avere un'isteresi o un tempo di reazione troppo lento per la tua applicazione.

non avendo a disposizione una scheda di acquisizione veloce, come ero abituato in altri ambienti, ed essendo il mio prmo progetto su step 7, e la prima volta che uso schede vipa, non conosco altre strade per raggiungere questo obbiettivo.. inoltre ormai devo trovare una soluzione praticamente subito...

la scheda di acquisizione veloce non ti serve, perché hai già l'ingresso veloce a bordo della CPU... se riesci a stabilire che il problema è nel sensore, come già suggerito, ti consiglierei un encoder.

[batta]

A 1000 giri/minuto della ruota dentata da 20 denti ti ritrovi con una frequenza di circa 333Hz.

Questa frequenza è ancora molto bassa rispetto le possibilità del conteggio veloce della cpu, e anche per poter ottenere una lettura stabile e veloce.

Potrebbe invece essere alta per il sensore, specialmente se i denti della ruota sono piccoli (il sensore rischia di vedere più di un dente) e se la distanza non è corretta.

La prima cosa da fare sarebbe controllare i segnali con un oscilloscopio.

In mancanza di oscilloscopio, ti basta un frequenzimetro. Se la frequenza è stabile, devi cercare da un'altra parte la causa della lettura instabile che effettui col plc.

Se invece (come credo) anche il frequenzimetro ti dà una lettura variabile...

Come già detto, io sostituirei ruota dentata e sensore con un encoder. Basta un encoder con un solo canale che ti fornisca un segnale PNP 24Vdc. Non costa molto.

Con un encoder da 1000 imp/giro arriveresti ad una frequenza massima di circa 17kHz. Valore che definirei un ottimo compromesso per lo scopo.

Modificato: 21 luglio 2010 da batta

[virgolanera]

Intanto grazie per le risposte. Il problema è che io non ho potere di cambiare le componenti hardware. Posso proporlo, ma non credo che sarò ascoltato.

Per il resto, il codice che ho postato sopra, secondo voi è corretto? Io non vedo errori.

Adesso provo a utilizzare delle word anziche doubleword ma non credo cambi nulla..

[virgolanera]

Trovato il problema. Il contatore integrato della cpu vipa, non conta correttamente gli impulsi che arrivano. Non mi incrementa di uno ad ogni impulso, ma se un impulso dura leggermente di piu, il contatore incremente di due o tre...

Io uso il contatore integrato in Impulse/direction..

[AVC_Veronica]

Ciao , prova ad utilizzare il fronte di salita del tuo trasduttore, così il conteggio si inc di uno per ogni impulso.

I sensori induttivi dovrebbero arrivare tranquillamente alla tua F di utilizzo.

[batta]

Trovato il problema. Il contatore integrato della cpu vipa, non conta correttamente gli impulsi che arrivano. Non mi incrementa di uno ad ogni impulso, ma se un impulso dura leggermente di piu, il contatore incremente di due o tre...

Ne sei sicuro?

Quanto affermi non ha senso.

Controlla casomai che i segnali siano puliti.

Se il contatore conta di più non è certo perché incrementa di 2-3 count se la durata dell'impulso è lunga, ma perché ci sono segnali sporchi.

In configurazione Hardware delle cpu Siemens S7-314c c'è la possibilità di impostare la frequenza massima di conteggio.

Abbassando tale frequenza viene applicato un filtro sull'ingresso, proprio per evitare questi problemi.

Penso che anche in VIPA ci sia qualcosa di analogo.

La cosa migliore da fare per individuare con certezza il problema, rimane sempre un controllo dei segnali con oscilloscopio.

Se non sai con precisione cosa ti arriva sull'ingresso di conteggio, puoi fare solo ipotesi.

[virgolanera]

Esatto!!! Era il filtraggio del segnale il problema. C'era praticamente tempo di filtro pari a zero. Alzandolo un po ora conta correttamente.

Il problema è che essendo la prima volta che utilizzo schede vipa, sto scoprendo di volta in volta, dove si trovano le varie impostazioni e il loro significato.

Sopratutto per quanto riguarda la parte integrata alla cpu...

C'è ancora secondo me un minimo di oscillazione di troppo, però stavolta è veramente poca, e devo capire se è effettivamente lo strumento, o la macchina che effettivamente non ha una velocità stabile.. Di sicuro il problema degli impulsi adesso non c'è più.

[Livio Orsini]

Quella del filtraggio è sempre e comunque una pezza, meglio sarebbe individuare e rimuovere le cause dei disturbi.

Una soluzione definitiva potrebbe essere quella dell'uso di segnali in quadratura, ma nel tuo caso non sembra applicabile.