- Questo topic ha 11 risposte, 1 partecipante ed è stato aggiornato l'ultima volta 3 anni, 4 mesi fa da
.
-
Post
-
Avrei bisogno di un consiglio su come gestire al meglio un problema di acquisizione encoder.
Ho un sistema con SlimLine MPS056 al quale ho collegato un encoder mediante l’apposito modulo mixed signal. Noto che il sistema non risponde in modo tempestivo pur avendo messo tutto il programma relativo alla gestione encoder nella task Fast ed il resto nella Back.
Io pensavo di migrare ad un modello basato su Cortex M7 per avere maggiore velocità di esecuzione programma, credete che sia la strada giusta?
Credo tu abbia utilizzato il FB IOEncoder per l’acquisizione visto che utilizzi un normale modulo di I/O, in questo caso la gestione della quadratura encoder è tutta demandata al software che campiona i due ingressi encoder in base alla velocità di esecuzione del FB che essendo in programma eseguito in task Fast è di 1 mS.
Se vuoi reattività e sopratutto non vuoi perdere impulsi di conteggio sugli encoder devi utilizzare il FB SysGetEncoder con i moduli di estensione che integrano la gestione encoder in modo hardware permettendo di gestire segnali fino a 50 kHz. Utilizzando queste schede non è più importante in che task ne esegui l’acquisizione perchè il valore ritornato dalla acquisizione è il valore del contatore gestito in modo hardware.
Se cerchi nel forum troverai altri posts che trattano l’argomento.
Grazie della riposta, purtroppo il mio problema non e la rilevazione encoder che faccio con SysGetEncoder, bensì il problema sta nel gestirne il codice. Mi spiego meglio:
L’encoder legge la posizione di un tavolo rotante il quale deve fermarsi 4 volte per scaricare/caricare oggetti. Ho notato che soprattutto quando collegato in Modbus coni PC più i due HMI il tavolo sbaglia spesso le fermate di qualche grado in quanto il comando di stop viene impartito in ritardo. Anche se la lettura encoder viene fatta regolarmente senza errori, il dato non viene elaborato in tempo dal flusso del programma.
Probabilmente hai inserito tutta la gestione dell’arresto in task Back la cui esecuzione dipende dall’impegno del processore nell’eseguire le altre operazioni. Normalmente la gestione del Modbus non incide in modo determinante sul tempo di esecuzione.
Diversa è l’eventuale gestione del disco che a seconda dell’operazione che stai eseguendo potrebbe fare variare il tempo anche di 100-300 mS. A tal proposito ricordo che il sistema autonomamente provvede a registrare log su disco e quindi potrebbe in caso di record di log da salvare creare un jitter di esecuzione della task Back.
Se vuoi avere una esecuzione real time (con tempi certi senza jitters) devi mettere l’esecuzione di tutta la gestione del posizionamento in task Slow (Eseguita di default ogni 10 mS) o nella task Fast (Eseguita di default ogni 1mS). I tempi di esecuzione sono modificabili da programma.
Ma ricorda che devi gestire nella stessa task anche le uscite di comando del driver, se la gestione la inserisci nella task Slow non devi fare nulla, l’immagine di processo gestisce gli I/O nella task Slow.
Se invece inserisci la gestione nella task Fast devi usare il FB SysSetPhrDO ma verifica il tempo di esecuzione della task per non uscire dal tempo massimo (Eventualmente aumenta il tempo). La gestione delle s chede periferiche di I/O richiede un certo tempo 100-300 uS e tu devi leggere l’encoder e settare le uscite quindi occupi già oltre la metà del tempo disponibile. Nota: per velocizzare puoi usare gli I/O del modulo CPU, in questo caso il tempo di gestione è una decina di uS.
Il programma di gestione del tavolo viene eseguito nella task Fast… L’output di rotazione e dato da un uscita sul modulo CPU non usando la SysSetPhrDO, ma direttamente mappando l’uscita come variabile, forse il problema sta li.
A questo punto ti chiedo se per gestire le uscite ingressi dalla task Fast devo sempre utilizzare questo metodo, anche se non mi serve avere tempestiva di funzionamento.
Da quello che dici gestendo tutto nelle task Fast e Slow non hai nessuna dipendenza dai carichi di lavoro della CPU, il programma viene CERTAMENTE eseguito nei tempi definiti.
Certo che se tu gestisci le uscite come variabili utilizzi l’immagine di processo che come ti dicevo è gestita in Slow, quindi tu esegui la variazione della variabile in uscita ma questa verrà trasferita sulla uscita solo nella task di Slow.
Quindi è inutile gestire tutti i calcoli e le comparazioni in task Fast (1000 volte al secondo) se poi l’azione vera di comando arresto motore si esegue 100 volte al secondo. Quindi riassumendo occorre stabilire bene a che velocità realmente ti serve agire sull’arresto ed eseguire sia i calcoli che il comando delle uscite con il tempo adeguato.
Nota: se usi il FB SysSetPhrDO occorre impostare correttamente il parametro Mask per evitare che la task Slow quando esegue l’immagine di processo modifichi il valore settato.
La quadratura dell’encoder è stata abilitata sul modulo CPU CortexM7 (ho letto che era un work in progress) ?
In alternativa, senza usare il modulo di espansione, posso solamente usare un ingresso veloce come semplice counter, quindi monidirezionale?
Attualmente non è ancora gestita l’acquisizione encoder sul modulo CPU CortexM7.
Certo puoi utilizzare un ingresso di counter per acquisisre uno dei canali dell’encoder ed eseguirne il conteggio. Se usi il counter del modulo CPU potrai acquisire segnali fino ad un massimo di 10kHz, ma attenzione utilizzando un solo ingresso senza la quadratura quando l’encoder si arresta a cavallo della tacca rischi di avere un conteggio anche se in trealtà l’encoder è fermo.
Grazie per la risposta.
La necessità di utilizzare gli ingressi della CPU è legata al fatto di avere il minor tempo ciclo sulla task fast, al fine di poterla eseguire anche a tempi di loop pari a 300-400 us, condizione che blocca la comunicazione con i moduli di espansione (in quanto <0.5ms)
L’utilizzo che dovrei fare dell’encoder è solamente un tracking di prodotti su un nastro quando questo è in movimento. A nastro fermo non ho prodotti in attesa, quindi il problema che giustamente riporti tu, almeno per questa applicazione, non è presente.
In quali CPU della serie SlimLine è implementata la quadratura encoder ?
Se utilizzi il counter hardware non occorre campionare velocemente gli ingressi digitali ci pensa il circuito hardware a gestire il conteggio. Come dici tu la necessità di campionare velocemente gli ingressi digitali serve solo nel caso utilizzi un conteggio software o l’FB IOEncoder di acquisizione encoder su I/O.
La quadratura encoder è una feature implementata nel core Cortex M7 ma che al momento non è ancora gestita dal nostro sistema.
La mia applicazione può essere schematizzata in questo modo:da quando ricevo l’ingresso DI01 della CPU, verifico il conteggio encoder sulla DI00. Ho 2 quote obiettivo. Al raggiungimento della prima, devo alzare immediatamente una uscita DO00, e al raggiungimento della seconda, devo alzare una seconda uscita (per quest’ultima posso permettermi piccoli ritardi) DO01.
Dovendo ridurre al minimo i vari ritardi, lavoro su una task fast da 0.3-0.4ms, uso l’ingresso veloce CPU per il conteggio (al limite del vincolo hardware dei suoi 10kHz di capacità di lettura, demandata alla SysGetCounter), e uso le due uscite integrate della CPU, risparmiando anche quei 300us di comunicazione tra CPU e moduli di espansione.
Vedi qualche controindicazione in questa configurazione?
La CPU più performante al momento che potrebbe fare al caso nostro è la Cortex M7 (la ARM9 Linux-PLC ha 2 in e 2out, ma, dal datasheet, non ha ingressi veloci). Vi sono imminenti rilasci di nuovi modelli?
Iniziamo con il dire che la CPU ARM9 è un modello a fine produzione, ed il successivo modello basato su Raspberry non ha I/O a bordo.
Ma da come mi spieghi l’applicazione mi sembra che non dovresti avere problemi nel realizzarla, utilizzando tutte risorse (Counter, Di, Do) a bordo modulo CPU elimini tutti i tempi di comunicazione sul bus e puoi sicuramente impostare un tempo di esecuzione task Fast anche minore di 300uS.
Ti ricordo che se metti nella finestrra di watch le variabili SysTFastExTm, SysTFastExTmMin, SysTFastExTmMax (I tempi minimo e massimo si resettano attivando da debug la variabile SysTimeInit), potrai verificare quanto tempo è necessario ad eseguire il programma in task e regolarti di conseguenza nell’impostazione del tempo di esecuzione task.
- Devi essere connesso per rispondere a questo topic.