- Questo topic ha 4 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 5 anni, 2 mesi fa da
.
-
Post
-
Mi trovo su di un impianto alcuni I/O logici che devono essere gestiti molto velocemente (Ad ogni mS), quindi ho scritto un program che poi ho eseguito nella task Fast ma non riesco ad ottenere una gestione veloce degli I/O. Sapete darmi indicazioni?
Tutti i moduli di I/O logici connessi al modulo CPU sono aggiornati automaticamente (Immagine di processo) e mappati nella tabella %IX e %QX nella task Slow. Gli ingressi sono acquisiti prima e le uscite sono gestite dopo, l’esecuzione del programma utente. Quindi l’immagine dello stato di un I/O è valida per tutta l’esecuzione della task slow.
Nella task Back, viene creata una immagine di processo “parallela” che riporta lo stato degli ingressi prima della esecuzione e gestisce le uscite dopo l’esecuzione del programma utente, anche questa “immagine” dello stato di un I/O è valida per tutta l’esecuzione della task ma riporta lo stato degli I/O così come sono stati gestiti dalla task Slow, aggiornati quindi con la velocità di esecuzione della task Slow.
Nella task Fast se si vuole gestire gli I/O alla velocità di esecuzione della task, occorre acquisirne il valore e gestirne l’attivazione con le apposite FB (SysGetPhrDI e SysSetPhrDO) e non utilizzando quelli mappati nella tabella %IX e %QX. Ora siccome la gestione degli I/O tramite il bus I2C richiede tempo CPU è preferibile utilizzare nella task Fast gli I/O del modulo CPU, od in alternativa cercare di utilizzare I/O sullo stesso modulo di estensione a gruppi di 8/16 in modo da potervi accedere con una unica chiamata alle funzioni di gestione. In questo topic viene trattato lo stesso argomento.
Dopo quanto scritto precedentemente ecco la stampa di un programma che dimostra come utilizzare I/O nella task Fast. Come si vede vi sono due programmi uno eseguito in Slow che appoggia l’ingresso Di00M00 sull’uscita Do00M00, ed un programma eseguito in Fast che appoggia l’ingresso Di01M00 sull’uscita Do01M00 (Download programma). Punti da considerare.
Il modo di acquisizione ingressi e DI_I_8_LL in modo da evitare il debouncing hardware presente sui moduli.
Nella gestione delle uscite logiche viene impostato il Mask per mascherare il bit 1 (Quello relativo alla uscita Do01M00). Attenzione la mascheratura è definita a bit, se si gestiscono più bit devi fare la OR dei bits utilizzati. Esempio per mascherare i bits 0, 1, 4 devi scrivere 16#00000013.
Nelle altre tasks (Slow e Back) non devi utilizzare le uscite gestite nella task Fast.
Domanda riferita a:
Nelle altre tasks (Slow e Back) non devi utilizzare le uscite gestite nella task Fast.
Chiaro che ci possono essere problemi gestendo uscite sia con SysSetPhrDO che con immagine di processo. Per gli ingressi invece?
Ho sette manopole (encoder incrementali) su un sinottico, collegate da DI00 a DII13 su un modulo a 32 ingressi. Gli ingressi sono prelevati dalla SysGetPhrDI in modo “DI_I_16_L” in una task Fast. Ovviamente in questo modo vengono prelevati in blocco gli ingressi da 00 a 15. Sugli ingresso DI14 e DI15 ci sono collegati due pulsanti che vorrei gestire con l’immagine di processo creando le variabili %IX1.14 e %IX1.15. A rigor di logica non dovrebbe creare problemi, è una lettura in più.
Il dubbio che mi viene è: l’immagine di processo acquisisce con il debounce presumo, mentre nella mia task fast la SysGetPhrDI no. Potrebbe esserci qualche acquisizione falsata nella task fast ?
Lo scenario descritto funziona senza problemi, puoi acquisire in task Fast il blocco degli ingressi (Senza debouncing) ed utilizzare i due ingressi in immagine di processo con il debouncing.
Naturalmente nell’immagine di processo saranno trasferiti tutti i 16 ingressi e potresti leggerli tutti con il debouncing in immagine di processo e senza debouncing in task Fast. Ma se non ti servono puoi assegnare uno mnemonico solo ai 2 che ti interessano.
- Devi essere connesso per rispondere a questo topic.