Jump to content
PLC Forum


Contagiri con PLC


DickMorley
 Share

Recommended Posts

Buonasera, vorrei condividere con voi un problema che mi tormenta da qualche giorno.

Ho bisogno di controllare la velocità di un motore, la cui velocità può variare da 0 a 5000 rpm circa.

Per la misura utilizzo un sensore PNP, connesso ad una scheda di ingressi veloci ( max 60kHz) sul PLC (BMXEHC0200 Schneider)

Ogni giro d'albero ricevo 2 impulsi (N)

In prima battuta ho utilizzato la scheda in modalità frequenza e ho calcolato i giri con la formula :  RPM= (Hz*60) / N

ovviamente in questo modo la misura, nel mio caso, variava di 30 rpm alla volta. Inaccettabile!

Allora ho impostato la scheda HSC in modalità Periodo, utilizzando la formula RPM= 1/N * (60/T)

In questo modo la misura è molto più accurata, ma molto "ballerina"

Ho provato con il filtraggio della scheda ....e nulla!

Ho provato a ridurre la frequenza di commutazione degli inverter, pensando che la misura fosse disturbata....e nulla!

Non so veramente come fare per avere una misura stabile, se non acquistare un convertitore di segnale con ingresso in frequenza e uscita in corrente.

Ma la domanda che più mi tormenta è questa:

Se un relè da 100€ riesce a darmi una misura stabile , come è possibile che non riesca a farlo un PLC?

Evidentemente esiste una tecnica. 

Qualcuno di voi ha gia' affrontato un problema simile ed ha qualche suggerimento da darmi?

Grazie anticipatamente a tutti. 

 

Link to comment
Share on other sites


Mirko Ceronti
1 ora fa, DickMorley scrisse:

In questo modo la misura è molto più accurata, ma molto "ballerina"

 

Cioè vuoi dire che anche se i giri del motore sono stabili (ne hai certezza ?) il risultato è comunque una pendolazione di valori ? :huh:

Saluti

Mirko

Link to comment
Share on other sites

Livio Orsini
11 ore fa, DickMorley scrisse:

Ogni giro d'albero ricevo 2 impulsi (N)

In prima battuta ho utilizzato la scheda in modalità frequenza e ho calcolato i giri con la formula :  RPM= (Hz*60) / N

ovviamente in questo modo la misura, nel mio caso, variava di 30 rpm alla volta. Inaccettabile!

Allora ho impostato la scheda HSC in modalità Periodo, utilizzando la formula RPM= 1/N * (60/T)

 

Con questi dati è il classico caso in cui si dovrebbe usare almeno un algoritmo misto periodimetro-freqenzimetro, oppure, meglio, un apposito algoritmo ottimizzato per la base tempi.

 

però per fare questo non si possono usare le funzioni di libreria dei PLC ma farsi una funzione apposita scegliendo la base tempi più adatta.

Link to comment
Share on other sites

Ciao Livio, scusa ma mi sfugge il tuo suggerimento; cosa intendi per “algoritmo misto periodimetro-frequenzimetro”?Come utilizzo entrambe le misure nello stesso algoritmo?

Link to comment
Share on other sites

Livio Orsini

Non è ne semplice ne facile spiegare in poche righe come funziona questo algoritmo.

Inoltre non credo sia possibile usare contemporaneamente le due modalità.

Io ho sempre risolto il problema, quando si presentava, con una funzione dedicata che avevo scritto io.

 

Vediamo di charire con qauttro conti per esemplificare.

 

Il tuo dispositivo genera 2 inpulsi al giro, quindi tra un  fronte ed il successivo intercorre un tempo che è funzione inversa della velocità di rotazione.

Ad esempio a 30 rpm hai impilsi ad 1Hz quindi 1" di periodo; a 300 rpm avrai 0.1" di periodo ovvero 100ms ed a 3000rpm avrai 10ms di periodo.

Ora tutto dipende dalla precisione e dalla risoluzione del cronometro che effettua la misura.

Se avesse la risoluzione di 1µS avrest ancora 1/10000 di risoluzione anche a 3000rpm.

Probabilmente però il clock del PLC avrà al massimo 1ms di risoluzione, quindi la risoluzione della misura già secende a 1/100 a 300 rpm ed ad 1/10 a 3000 rpm.

 

Se lavoriamo come freqeunzimetro con base tempi di 0.1", si avranno 10 aggiornamenti al secondo.

Con questa base tempi si conteranno 1 impulso a 300 rpm  e 10 impulsi a 3000 rpm (1/10 di rispoluzione)

Allungando la base tempi ad 1" la rusoluzione aumenta deìi un ordine, am è ancora insufficiente per velocità dell'ordine dei 30 rpm.

Bisognerebbe allungare la base tempi a 10" per avere un minimo di precisione anche a basse velocità, ma a questo punto la misura potrebbe essere lenta per un suo uso anche come visualizzatore.

 

Se tracci u  diagramma di risoluzione in funzione della freqeunza vedi che il periodimetro ha una funzione rettilinea discendente mentre per il freqeunzimetro è ascendente.

Il punto d'incontro delle due rette è il punto in cui si commuta la misura da un modo all'altro.

 

Poi essitono algoritmi particolari che permettono di crescere la precisione a regime anche con misure di freqeunza con aggiornamento veloce. Ad asempio si può avere la risoluzione di una finestra di 10" con aggiornamenti ogni 0.1", ma solo dopo che son trascorsi i primi 10".

Se si tratta di utilizzare la misura per visulaizzare o poco più può anche andar bene, se invece dovessi effettiare una regolazione di velocità allora potrebbe non essere più adatta.

Link to comment
Share on other sites

Mi accodo a Livio, un approccio potrebbe essere:
 Disporre di una uscita a impulsi veloci, come quelli per un motore passo passo, emetterli e usare il sensore come switch/gate verso l'ingresso veloce
Se questa soluzione è praticabile, il limite di funzionamento è alla velocità massima. 5000 RPM sono 83,33 giri/sec
In teoria con una uscita PWM a 10 kHZ avresti già 10000/83,33 = 120 impulsi/giro. questo in teoria. Alle velocità basse la risoluzione migliora.

 

E' il metodo (reciprocal count) con cui lavorano i frequenzimetri per basse frquenze.

Link to comment
Share on other sites

Sandro Calligaro

La prima domanda che ti farei è quanta banda ti serve, cioè quanto velocemente devi poterti accorgere di una variazione di velocità.

Se devi fare un normale controllo in catena chiusa di un motore, ti occorrono ben più di due impulsi a giro, direi almeno cento volte di più.

Se invece devi solo monitorare la velocità, oppure regolarla in modo molto lento (cioè ti basta che la velocità a regime sia quella desiderata), allora può darsi che anche 2 ppr siano sufficienti.

Se questo è il tuo caso, l'uscita della velocità calcolata va filtrata, possibilmente con un filtro non a media mobile.

 

Naturalmente, preso un certo metodo (frequenza degli impulsi o misura del periodo) la precisione con la quale puoi determinare la velocità cambia con la velocità stessa, come hanno accennato Livio e rguaresc.

In più, c'è un compromesso tra la precisione nel determinare la frequenza degli impulsi ed il tempo che occorre per farlo. Da questo non si sfugge, purtroppo, è una questione matematica.

 

Un'implementazione della misura mista che descrive Livio prevede di pesare le due misure (basate una sul periodo, l'altra sulla frequenza), in funzione della velocità (che a sua volta è il risultato del "mix"), ad esempio così:

vel_mix = vel_periodo*(1-Kpeso) + vel_freq*Kpeso;

Kpeso = sat(0,1,(vel_mix - soglia_min)/(soglia_max-soglia_min));

dove sat(vmin,vmax,x) è una funzione che satura x tra vmin e vmax, soglia_min è la minima soglia alla quale iniziare ad usare la velocità misurata come frequenza e soglia_max è la velocità alla quale smettere di usare la velocità misurata in base al periodo.

image.png.49dd70182e4b7cd3f697acaba7e3605a.png

Non ho mai implementato questa cosa, ma in base all'esperienzadi altri e ragionandoci direi che deve funzionare.

Le soglie saranno equidistanti dalla velocità che diceva Livio. In ogni caso, la misura di velocità (e non i segnali di ingresso!) va filtrata passa-basso.

 

Un'ultima considerazione banale: se il conteggio guarda le transizioni del segnale (sia in salita che in discesa), allora la misura potrebbe essere ballerina perché il duty-cycle dell'onda non è precisamente 50%.

 

PS: ultimissima considerazione... Per una cosa "seria", magari in ambiente industriale, non è consigliabile usare un segnale di posizione che non sia differenziale (infatti la maggior parte degli encoder ha uscite differenziali).

Link to comment
Share on other sites

Buongiorno, in primo luogo ringrazio tutti per le risposte, a seguire le dovute precisazIoni:

Quote

Se invece devi solo monitorare la velocità, oppure regolarla in modo molto lento (cioè ti basta che la velocità a regime sia quella desiderata), allora può darsi che anche 2 ppr siano sufficienti.

Se questo è il tuo caso, l'uscita della velocità calcolata va filtrata, possibilmente con un filtro non a media mobile.

Devo fare un controllo di giri differenziali; devo monitorare e correggere la velocità in modo che sia sempre mantenuto il rapporto desiderato, (all’interno di un campo definito) tra due motori. Posto che il primo motore in un funzionamento ‘normale’ dovrebbe avere una velocità a regime stabile, direi che i 2 ppr sono sufficienti.

Quote

... non è consigliabile usare un segnale di posizione che non sia differenziale (infatti la maggior parte degli encoder ha uscite differenziali).

Avevo intenzione di provarlo martedì, perché la macchina ha già installati 2 sensori PNP sullo stesso albero.

 

Provero a realizzare l’algoritmo suggerito..Vi farò sapere nei prossimi giorni!

Link to comment
Share on other sites

Livio Orsini
15 ore fa, Sandro Calligaro scrisse:

la misura di velocità (e non i segnali di ingresso!) va filtrata passa-basso.

 

Scusa Sandro perchè pensi che la velocità debba essere filtrata da un passa basso?

Io, nelle mie applicazioni, non ho mai riscontrato la necssità.

L'unica vera necessità è avre una base tempi precisa e costante; ovviamente questo vale anche per il clok del periodimetro.

5 ore fa, DickMorley scrisse:

devo monitorare e correggere la velocità in modo che sia sempre mantenuto il rapporto desiderato, (all’interno di un campo definito) tra due motori.

 

Non la vedo molto bene!

Questo sembra un classico albero elettrico in velocità. Io, per mie esperienze pregresse, userei 2 encoders incrementali, con almeno 255 impulsi-giro, meglio 500 impulsi.

Con 255 giro avresti, a 5000 rpm, una freqeunza massima di 21250Hz, valore che qualsiasi scheda di conteggio veloce deve accettare.

Poi, se non vuoi ritardi di inseguimento, dovresti usare un master virtuale a cui asservire i due motori.

Link to comment
Share on other sites

Per me la questione fondamentale è che sono infinitamente pochi due segnali a giro per determinare in maniera precisa la velocità di un asse, è ovvio che più è variabile la velocità e più è necessaria una definizione dei punti in cui dividere l'asse. Per basse velocità più sono le divisioni meglio è, se invece l'asse raggiunge velocemente velocità o frequenze alte non c'è poi necessità di dividere eccessivamente il giro perchè già l'alta frequenza raggiunta aiuta a determinare finemente la velocità. Vi sono istruzioni per PLC che determinano in maniera piuttosto semplice la velocità dell'asse dando pure i valori intemedi di campionamento, in questo modo determini ad ogni scansione di programma la velocità attuale dell'asse dividendo gli impulsi passati per il tempo passato dall'inizio del campionamento. E' ovvio come dicevo sopra che se l'asse gira piano più sono le divisoni a giro e più si ha precisione nel calcolo intermedio della velocità. I PLC a cui faccio riferimento sono Mitsubishi con l'istruzione SPD (SPEED) che dando anche un tempo lungo di campionamento impulsi ritorna comunque il numero impulsi contati da inizio campionamento e il tempo che ne è passato, con una semplice divisione ottieni la velocità è ovvio che per velocità basse è fondamentale come dicevo il farzionamento dei rilevamenti a giro

Link to comment
Share on other sites

Sandro Calligaro
il 31/3/2018 at 15:33 , Livio Orsini scrisse:

Scusa Sandro perchè pensi che la velocità debba essere filtrata da un passa basso?

Filtrando passa-basso si scambia un po' di dinamica con un po' di precisione, attenuando il ripple dovuto alla natura discreta della misura di posizione.

E' un compromesso, ovviamente.

In questo caso, con una risoluzione pessima, filtrare permetterebbe magari di ricavare un segnale lento che però dà un valore di velocità sensato.

 

In quasi tutti i drive che ho visto c'è la possibilità di filtrare passa-basso la velocità misurata.

 

 

Tornando all'estrazione della velocità da un segnale di posizione... il metodo "ottimale" per migliorare la lettura della velocità da un sensore poco risoluto è quello di usare una PLL o un osservatore di stato meccanico.

In ogni caso, i miracoli non si fanno, occorre un minimo di risoluzione, se si vuole fare un controllo degno di questo nome.

Link to comment
Share on other sites

Livio Orsini
6 ore fa, Sandro Calligaro scrisse:

In ogni caso, i miracoli non si fanno, occorre un minimo di risoluzione, se si vuole fare un controllo degno di questo nome.

 

Questa saràuna verità lapalissiana, ma è comunque inoppugnabile.:)

6 ore fa, Sandro Calligaro scrisse:

Filtrando passa-basso si scambia un po' di dinamica con un po' di precisione

 

No Sandro ho posto male io la domanda; intendevo perchè non un passa abasso a media scorrevole. E' come mettere una capacità con un segnale analogico.

Link to comment
Share on other sites

Sandro Calligaro
13 ore fa, Livio Orsini scrisse:

perchè non un passa abasso a media scorrevole. E' come mettere una capacità con un segnale analogico.

Qui si aprirebbe effettivamente una lunga discussione...

Ho già litigato parecchio, su questi argomenti (non qui sul Forum). :lol:

Scherzi a parte, non ho argomenti esatti per dire che uno sia meglio dell'altro, però ho delle "buone ragioni" per dirlo.

 

La media mobile, a mio avviso, è più dispendiosa in termini di calcoli e memoria (in particolare per durate lunghe) ed è meno flessibile.

L'altra cosa che non mi piace è che si finisce di solito per ciclare tra due valori di velocità ben precisi, a regime, perché ogni impulso dell'encoder in più o in meno dà un ben determinato contributo alla media, che viene solamente diviso per la lunghezza del filtro. Con un filtro passa-basso del primo ordine, magari in virgola mobile, si evita questo comportamento.

 

La media mobile la userei principalmente dove si tratta di eliminare del tutto una ben precisa armonica, visto che può eliminare completamente le frequenze multiple del reciproco della durata.

 

Per quella che è la mia esperienza, anche in algoritmi abbastanza complicati, legati ad esempio a stime on-line di grandezze (come la velocità nel sensorless), i filtri del primo ordine sono la prima opzione, sia per ragioni di sfasamento (che negli anelli di controllo è fondamentale tenere basso), sia perché basta una riga di codice per implementarli e basta modificare un solo coefficiente per cambiare la banda passante.

Link to comment
Share on other sites

Livio Orsini

Sandro ora ho compreso appieno il tuo pensiero.

 

Io la media scorrevole la scopersi (non come concetto come modo di implementarla facilmente) molti decenni fa, agli albori delle applicazioni dei microprocessori quando le operazioni in virgola mobile erano solo Sw e duravano eternità di tempo macchina. l

La media scorrevole si implementa con poche istruzioni ASM (che era l'unico linguaggio usufruibile) e funziona molto bene perchè non è altro che un in tegratore semplice.

 

Oggi si dispone di processori molto più performanti, programmabili con linguaggi estremamente potenti, quindi è facile implementare algoritmi anche molto complessi.

 

Però la media mobile a mio gidizio introduce solo un ritardo perfettamente quantificabile, di cui si puà tenerne facilmente conto nella regolazione.

 

ovviamente non ho nessun intento polemico, ma a me piace discutere ed analizzare le varie soluzioni. Anche se ho oramai un'età avanzata son sempre pronto ad imparare qaulche cosa di nuovo.

Link to comment
Share on other sites

Quote

In ogni caso, i miracoli non si fanno, occorre un minimo di risoluzione, se si vuole fare un controllo degno di questo nome.

Vi faccio vedere la differenza tra 2 misure eseguite a 1000 rpm e a 5000 rpm con 2 sensori identici (PNP 3 fili stessa marca è stesso modello) che eseguono la misura nello stesso albero. Uno è collegato alla scheda HSC del PLC ( traccia inferiore) e l’altro ad un rele’ di controllo giri della P+F. (Traccia Superiore).  Premesso che io non devo fare posizionamenti e che una misura stabile come la prima mi andrebbe bene, prendendo ovviamente in considerazione tutti i vs consigli e le vostre esperienze l’unica spiegazione plausibile che fino ad ore sono riuscito a darmi è quella di un limite hardware nella catena di misura e di acquisizione del segnale. Credo che sia tutto dovuto ad un fenomeno di “contact bound “, non risolvibile con un solo filtro software. Probabilmente il rele’ P+F ha anche dei filtri hardware in ingresso che la scheda del PLC non ha. Sono quasi sicuro che installando un sensore ad effetto Hall in ingresso al PLC ottengo lo stesso risultato. 

 

5000 rpm

1284A0B9-3375-4380-95A5-83D333A02656.jpeg

2BD70647-C39E-48B2-AD33-1FD69F396F16.jpeg

 

1000 rpm

 

 

D24C40D2-DAE6-4DAD-9806-6E0CA28AADBA.jpeg

Link to comment
Share on other sites

Livio Orsini

No c'è anche qualche altra cosa che non quadraLa traccia relativa al rele’ di controllo giri (se ci dessi un link al data sheet non sarebbe male per capire meglio) si comporta come mi aspetto: a 1000 rpm il ripple è appena legermente accennato, mentre a 5000 rpm è assente nella zona a velocità costante.

 

Mentre la misura effettuata con PLC è esattamente l'opposto: ripple maggiore a 5000 rpm rispetto a quello relativo a 1000 rpm. Ovviamente riferito alla velocità costante.

 

Se cisono filtri Hw ci sono all'uscita anlogica, ma se ci fossero si dovrebbe notare un certo ritardo nella traccia.

 

Dovresti spiegare come fai la misura con la scheda HFC, se sfrutti le due librerie standard, periodimetro e frequenzimetro, quello che vedi è perfettamente normale.

I rimbalzi, o se preferisci i contact bounces, sono inifluenti perchè il filtro discriminatore up-down della scheda li elimina e comunque eventuali rimbalzi causerebbero misure completamente errate, visto anche l'esiguo numero di impulsi/giro.

Link to comment
Share on other sites

Quote

se ci dessi un link al data sheet non sarebbe male per capire meglio

Manuale relè

 

Quote

Dovresti spiegare come fai la misura con la scheda HFC, se sfrutti le due librerie standard, periodimetro e frequenzimetro,

In questa registrazione la velocità è calcolata con la sola misura di periodo.

 

38 minuti fa, Livio Orsini scrisse:

comunque eventuali rimbalzi causerebbero misure completamente errate

Ho delle variazioni anche di 100 rpm (in + e in -) rispetto ai reali giri del motore. :toobad:

 

Link to comment
Share on other sites

Livio Orsini
7 minuti fa, DickMorley scrisse:

Ho delle variazioni anche di 100 rpm (in + e in -) rispetto ai reali giri del motore

 

Se si trattasse veramente di rimbalzi avresti anche errori maggiori del 50%

Sfortunatamente il data sheet non da nessuna indicazione sulla modolità di m isura,anche se suppongo si tratti di una conversione frequnza tensione, magari con moltiplicazione con tecnica PLL .

14 minuti fa, DickMorley scrisse:

In questa registrazione la velocità è calcolata con la sola misura di periodo.

 

Poi cosa fai? la converti con un D/A del PLC?

Se usi solo il periodo è normale che a velocità alta sia più disturbata che a bassa velocità.

Poi molto dipende dalla frequenza del clock di misura, come ti ho spiegato nel mio primo messaggio.

Usare le librire di sistema da spesso pèroblemi simili. Queste necessariamente sono state implementate per scopi generali, mentre il tuo è un caso particolare.

Link to comment
Share on other sites

Sandro Calligaro

Hai provato a dare un'occhiata ai segnali digitali che arrivano alla scheda?

Se usi un'uscita PNP, uno stato non viene forzato, quindi la transizione dipende dalla resistenza di carico.

A frequenza alta questo potrebbe essere un problema, a causa delle capacità del cavo ecc...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...