Direzione encoder

[Teoclimber]

Ciao a tutti, è la prima volta che scrivo sul forum, spero di avere aperto una discussione nel posto giusto.. 

Cominciamo a dire che sto utilizzando una CPU 314ifm, un po vecchiotta,  ma per quello devo fare è ottima..  Dopo aver impostato "ingressi di allarme" nelle funzioni speciali della CPU,  in ob40 mi sono appoggiato alle variabili OB40_MDL_ADDR  e Ob40_POINT_ADDR..... 

stabilito che DB100.DBX5.0  DB100.DBX5.1  DB100.DBX5.2  DB100.DBX5.3 sono i miei 4 bit che mi generano l'interrupt.... 

Ho bisogno di collegare tre encoder incrementali,  due contano in avanti mentre uno avanti e indietro.. 

Per fare conteggio avanti nessun problema, ho scritto che quando su DB100.DBX5.0 c'è un fronte aggiungo 1 in una variabile, quando voglio azzerare sposto 0.... È fin qui tutto ok,  lo stesso lo faccio con DB100.DBX5.1!!

Adesso comincia il problema che non mi fa più dormire di notte, cioè conteggio avanti e indietro.  Utilizzo DB100.DBX5.2 per il canale A e DB100.DBX5.3 per il B.

Ho provato a scrivere svariati codici ho provato e riprovato ma niente da fare, ho letto e riletto una discussione del 1200 "gestione encoder incrementale" ma non ne vengo fuori...  

Quindi, gentilmente mi potreste dire come posso settare un bit quando DB100.DBX5.2 è maggiore di DB100.DBX5.3 e resettare quando è minore, o forse sbaglio già di partenza a pensarla così!!

Rimango in attesa dei vostri preziosi consigli per poter ritornare a dormire di notte.... Grazie ciao

 

[odx]

solitamente si usano le schede encoder o ingressi veloci per gli encoder, però se nel tuo caso vanno "piano" a bassa frequenza, allora puoi gestirli anche con ingressi normali.

Nel caso delle schede encoder, ti danno già il valore di encoder da sole.

 

Il discorso di controllare quando un bit è maggiore di un altro ... mi pare errato in partenza.  Un bit vale 0 o 1 ... cosa intendi per maggiore ??? 0 maggiore di 1 ? ... basta un contatto

Se vuoi generare un conteggio usando i due canali manualmente, credo dovresti guardarti come funzionano i canali encoder. A e B ... quando è su uno e l'altro fa il fronte incrementi ... se invece e su l'altro viceversa, ma credo sia più facile da capire guardando il diagramma di funzionamento dei canali encoder.

 

In pratica credo che puoi fare ... quando 5.2 è 1 e hai il fronte su 5.3 incrementi .....   quando hai 5.3 su e fronte su 5.2 decrementi ... poi vedi tu come ampliare il lavoro in base alla risoluzione che vuoi ottenere.... così è il minimo sindacale   ( fronte di salita )

[Teoclimber]

Grazie odx per la risposta, 

I miei contatti non sono ingressi normali, con questa CPU sono ingressi speciali, possono leggere tranquillamente encoder incrementali.. 

Forse mi sono spiegato male io, in pratica non so cosa scrivere per vedere una variabile incrementare e decrementare in base a come giro l'encoder o meglio come scrivere: 

Se il canale A va a 1 prima del canale B contami in avanti se invece il canale B va a 1 prima del canale A conta indietro.

Il fatto è che se dovessi fare come dici avrei una variabile impazzita,  continuerebbe a dare 1 -1 1 0 1 -1 ecc.. 

Questo perché se giro in senso orario l'encoder arriva un impulso dal segnale A e poi  dal B e se giro al contrario  prima il B poi A..

 

Sto diventando matto

 



 

[eddy]

Teoclimber,

Se rileggi la risposta di odx, risulterà chiaro che devi usare il fronte di salita di un canale o dell'altro per incrementare o decrementare la variabile di conteggio.

[Livio Orsini]

Per convenzione si considera avanti se A prima di B ed indietro se B prima di A.

Però il conteggio non è semplicemnte contare i fronti, perchè è necessario discriminare il "trillio" nell'intorno di un fronte.

 

Discriminare gli impulsi corretti in modo software, in modo da eliminare le oscilalzioni dell'encoder attorno ad un fronte è la parte più complessa.

 

Io solitamente sul fronte di B verifico che A sia alto, in questa condizione incremento la variabile che totalizza il conteggio. Alzo anche un bit che riabbasserò sul fronte di discesa di A. Se su un nuovo fronte di salita di B il bit non è stato azzerato non effettuo il conteggio perchè è un impulso spurio.

Similmente sui fronti di salita di A compio le medesime operazioni e verifiche per decrementare la variabile che totalizza il conteggio.

[batta]

Quote

I miei contatti non sono ingressi normali, con questa CPU sono ingressi speciali, possono leggere tranquillamente encoder incrementali.. 

Se con questo vuoi dire che utilizzi gli ingressi del contatore veloce, non devi analizzare tu lo stato dei segnali, ma lo fa già il PLC. Semplicemente, devi studiare il manuale e configurare il contatore veloce.

[Teoclimber]

Eccomi,

Grazie per le risposte..

Batta sono d'accordo con te, già provato con la funzione contatore e funziona benissimo, ma se la uso posso collegare solo un encoder...  mi piacerebbe proprio vedere cosa c'è scritto nella funzione contatore.... 

Adesso provo a scrivere un codice seguendo i vostri consigli

A presto e grazie

[odx]

Parere personale ... un ingresso encoder ti permette di interpolare i canali e aumentare la risoluzione ricavabile dal tuo encoder fino a 4 volte tanto ( oltre ad altre funzioni ) ... usarli come semplici ingressi ad alta frequenza è un po' sprecato. Sei sicuro che la frequenza del tuo canale sia così alta da non poter essere letta da un ingresso tradizionale, che comunque non è così lento ... ?

[Teoclimber]

Ciao a tutti,  dopo una lunga settimana movimentata finalmente oggi sono riuscito a riprendere il mio problema.. 

Ho provato a utilizzare ingressi tradizionali, senza funzioni speciali diciamo e devo dire che ho visto finalmente la mia variabile incrementare e decrementare ... 

Però così facendo se giro fisicamente l'encoder un po veloce (con pollice e indice intendo) mi perde dei conteggi...

Allora ho provato con i miei famosi bit in ob40..

Ma anche così perde colpi...

Mi chiedevo, ma utilizzare un -(p)- in ob40, come ho fatto,mi potrebbe ritardare il tempo di interrupt?? Spero che abbiate capito cosa voglio dire 

Buon week end a tutti

[Roberto Gioachin]

• Quando esegui i conteggi attraverso le istruzioni scritte sul tuo programma, hai sempre a che fare con il tempo di scansione del plc, in questo modo dubito fortemente che tu possa leggere un encoder che superi i 50 imp/sec.  Quindi hai due strade: O lasci fare al plc configurando il contatore veloce interno e non scrivi nulla come programma se non la letture del valore ed il suo azzeramento, oppure ti accontenti di basse velocità.
•  

Roberto

[Teoclimber]

 

Ciao...

Alla fine quello che avevo in mente non si può fare, vabbe', l'importante è che mi avete chiarito un po' le idee...

 

Alla fine penso che farò così....

Quando alzo il bit che mi farà girare il motore avanti  alzò anche un bit che mi abilitera' conteggio avanti quando andrà indietro stessa cosa..

Logicamente dovrò stare attento alle inerzie !

Grazie a tutti...

[Livio Orsini]

Con quel sistema avrai sicuramente letture errate. Quando il motore si ferma rischi di leggere per impulsi le piccole oscillazioni nell'intorno di un fronte.

 

[batta]

Oltre a quanto detto da Livio, aggiungo che non sono le due istruzioni in più per rilevare il senso di rotazione che ti impediscono di contare più velocemente.

Contare i fronti e discriminare la direzione con un segnale dal senso di rotazione non ti aiuterà in nessun modo.

Il fatto è che non puoi pretendere di gestire gli impulsi di un encoder (a meno che la frequenza non sia molto bassa) da programma con normali ingressi.

I contatori veloci sono stati inventati proprio per questo. Se hai un encoder, utilizza il contatore veloce. Tutto il resto può andar bene come esercizio, ma niente più.

[Teoclimber]

Perché Livio??

Non utilizzerei più A&B.... 

Se uso solo il canale A, come facevo per contare avanti, lo stesso canale lo uso per contare anche all'indietro..

Mettendoci davanti un bit che mi permette o no il conteggio.

Che dici, no?!?! avrò veramente dei problemi con questo sistema? 

 

 

Vorrei allegare una foto ma non capisco perché non mi permette più di farlo,

Mi chiede: inserisci allegato già caricato in down.. Oppure.. 

Inserisci immagine da Url 

[Teoclimber]

Ciao Batta,

Io volevo solo capire come avere una variabile incrementare e decrementare in base a come giro l'encoder... 

Da quello che dici i miei due codici sono giusti, le foto intendo, e sono contento... 

Dopo si è aggiunto l'argomento "velocità" 

Sono consapevole che dovrei utilizzare i contatori veloci per avere le cose fatte bene, ma adesso sono veramente confuso.... 

All'inizio di questa discussione  scrissi:

"

Dopo aver impostato "ingressi di allarme" nelle funzioni speciali della CPU,  in ob40 mi sono appoggiato alle variabili OB40_MDL_ADDR  e Ob40_POINT_ADDR..... 

stabilito che DB100.DBX5.0  DB100.DBX5.1  DB100.DBX5.2  DB100.DBX5.3 sono i miei 4 bit che mi generano l'interrupt.... "

Con questo sistema non avrei una lettura più veloce???  Sto sbagliando?? Cioè scrivere un bit normale es, m0.0 m5.0 m4.2 o  usare i bit di questa CPU ( ingressi di allarmi) sono la stessa cosa, avrei la stessa velocità?? 

[Livio Orsini]

Quote

Perché Livio??

 

Osserva all'oscilloscopio come si comporta un segnale di encoder e la cosa ti sarà evidente; la spiegazione verbale te l'hogia data nel mio primo messaggio.

 

Batta poi ti ha dato un'esauriente spiegazione del perchè si usano i  contatori veloci.

Se chi queste cose le usa da decenni e conosce (quasi) tutti i problemi che possono capitare ti indica la strada da percorrere, non pensi che abbia un po' di credibilità?

[leleviola]

Scusate se mi intrometto,

ma lo scopo della discussione non è quello di distinguere il senso di rotazione e conteggio dell'encoder?

gli encoder trattandosi di ingressi veloci che possono variare in un tempo inferiore alla scansione di programma

devono essere obbligatoriamente trattati come contatori veloci i quali sono appositamente introdotti come funzionalità o istruzione che

riesce a controllare il variare dei due fronti di segnale fasati e quindi riescono a dare in tempo reale se si vuole il valore raggiunto dal contatore veloce in questione.

Normalmente i contatori veloci oltre a rendere disponibile il valore attuale del contatore veloce riescono pure a dare anche un segnale del senso di valore di conteggio attuale,

in genere ciò è dato da una variabile binaria che si attiva in un senso di rotazione e si disattiva nell'altro senso oppure si ha l'attivazione di una variabile binaria in un senso e l'attivazione de un'altra variabile binaria per l'altro senso. Non vedo utile andare a verificare direttamente i fronti di attivazione dei due canali via software in quanto, come detto sopra ci pensa già il contatore veloce  a darmi un report di ciò.

[Livio Orsini]

E' anche possibile, entro certi limiti, effettuare discriminazione del senso di rotazione e conteggio impulsi, anche su ingressi veloci legati ad interrupt.

I limiti son dovuti alla frequenza massima degli impulsi ed alla velovità di esecuzione delle istruzioni da parte del PLC.

 

Cerco di chiarire con un esempio.

Un encoder che ha una risoluzione di 1000 imp/giro, calettato su di un motore che ruota a 1500 rpm massimi avrà una frequenza pari a 25 kHz, ovvero ad un periodo di 40 µs; per leggere e discriminare con sicurezza son necessari entrambi i frontiquindi si verificano 2 interrupts a distanza di 10µs circa, ogni 40µs. In questo intervallo di tempo il PLC dovrà elaborare le istruzioni necessarie al riconoscimento. Nel tempo restante il PLC potrà elaborare le istruzioni del programma normale. Di tempo non ne avanza molto ed il programma procederà molto rallentato.

Notare che la velocità ed il numero di impulsi dell'esempio non siano nemmeno molto elevati.

 

Come costruire la funzione l'ho spiegato nel primo messaggio che ho inserito in questa discussione.

 

E' evidente che se appena sono necessarie prestazioni normali è praticamente obbligatorio ricorrere ad una periferica Hw specializzata: il contato re veloce.

[Teoclimber]

Oook... Tutto chiaro...

Grazie mille per le dritte..

Buona serata a tutti

[batta]

Quote

Da quello che dici i miei due codici sono giusti, le foto intendo, e sono contento... 

Il tuo codice funziona, ma non è la soluzione ottimale.

Tu incrementi se quando rilevi il fronte di salita del canale A il canale B è alto, e decrementi se quando rilevi il fronte di salita di B, è alto il canale A.

In linea di massima funziona, ma ti trovi incremento e decremento sfasati di 90°. A parte questo, se con l'encoder, a causa di vibrazioni del sistema meccanico, si muove avanti e indietro sul fronte di salita, per esempio, del canale A quando B è alto, tu continueresti ad incrementare.

Molto meglio invece rilevare fronte di salita e fronte di discesa di un solo canale.

Per esempio, se il canale B è alto e rilevo il fronte di salita di A incremento; se il canale B è alto e rilevo il fronte di discesa di A decremento.

In questo modo incremento e decremento avvengono sempre nello stesso punto e, se l'encoder dovesse vibrare intorno al cambio di stato di A, continueresti ad incrementare e decrementare di una unità, mantenendo quindi il conteggio fermo (salvo, appunto, quell'unità).

 

Poi, se fai l'analisi dei fronti di A anche con lo stato di B basso, ecco che ottieni un moltiplicatore x2 degli impulsi encoder. Se analizzi anche i fronti di salita di B, ottieni un moltiplicatore x4. I moltiplicatori x2 e x4 sono, quasi sempre, configurabili nei contatori veloci.