Vai al contenuto

Tempi esecuzione programma ed aggiornamento I/O

Home Forum Controllori SlimLine e Netsyst (LogicLab) Tempi esecuzione programma ed aggiornamento I/O

Stai visualizzando 4 post - dal 1 a 4 (di 4 totali)
  • Autore
    Post
  • #34982
    Anonimo
    Inattivo

    Spiego di seguito l’applicazione che intendo svolgere, stò cercando di capire se il controllore Slimline, insieme al modulo con integrato la lettura encoder incrementale, possa soddisfare la specifica applicazione.

    Si tratta del retrofit di una macchina “bordatrice” per pannelli in melaminico, la macchina ha 5 assi on/off (per il posizionamento durante l’attrezzaggio macchina, feedback su encoder incrementale), che non rappresentano un particolare problema, in più c’è la gestione della lavorazione del bordo, che invece è l’aspetto delicato per quanto riguarda il timing e che funziona in questo modo:

    La velocità di avanzamento del nastro è 20m/min, viene impostata dal segnale analogico 0:10V che pilota l’azionamento del motore cc di avanzamento cingolo; sul rullo di rinvio del cingolo (che ha diametro 49cm) è posizionato un encoder incrementale a 2000 passi giro.

    Ogni pezzo che entra sulla macchina passa sopra un finecorsa che serve a memorizzare tramite gli inpulsi dell’encoder l’entrata e la lunghezza del pezzo, in seguito calcolando la posizione del pezzo rispetto alle varie zone di lavorazione si gestiscono le entrate a tempo del taglio del bordo, intestatori, frese etc.

    Prima di tutto il finecorsa che determina l’ingresso del pezzo deve essere in grado di generare un’interrupt software in modo da memorizzare (tramite il segnale dell’encoder) l’ingresso del pezzo e la sua lunghezza, che serviranno alle lavorazioni successive; ovvero il segnale di tale finecorsa serve a catturare ‘al volo’ con precisione il segnale dell’encoder legato all’avanzamento eseguendo dei calcoli in base alla velocità di avanzamento del nastro trovo che a 20m/min ho un’impulso dall’encoder ogni 0.5ms, da ciò deriva che la velocità di reazione del sistema di controllo deve essere superiore, se penso ad esempio ad un plc con un tempo di ciclo di 5ms, mi trovo a pilotare le uscite con un possibile errore di 1.75mm, in quanto in 5ms il nastro avanza di 1.75mm;

    Quindi serve avere un tempo di aggiornamento delle uscite più veloce, minore di 0.5m.ad esempio sarebbe comodo poter impostare una task veloce a 0.1ms e poter leggere encoder/finecorsa ed l’eventuale attivazione delle uscite con un refresh di 0.1ms; inoltre è importante sapere il ritardo (se non è trascurabile) che esiste tra il comando di un’uscita e l’effettiva attivazione sul modulo I/O.

    In più se supponiamo di creare una task ‘fast’ a 0.1ms, cosa succede qualora il codice all’interno di questa task impiega più di 0.1ms ad essere eseguito ?

    #36680
    Sergio Bertana
    Amministratore del forum

    Vedo di dare risposte per i vari punti esposti.

    Il finecorsa che determina l’ingresso del pezzo deve essere in grado di generare un’interrupt software in modo da memorizzare (tramite il segnale dell’encoder) l’ingresso del pezzo e la sua lunghezza, che serviranno alle lavorazioni successive.

    Esiste la possibilità di abilitare GateEn nel blocco funzione SysGetEncoder, questo permette all’hardware della scheda encoder di acquisire il valore di conteggio encoder su variazione fronte dell’ingresso logico di Gate. Il valore ritornato in GQuote sarà il valore della quota encoder acquisito sul fronte del Gate senza alcun ritardo indotto dai tempi di esecuzione.

    Quindi serve avere un tempo di aggiornamento delle uscite più veloce, minore di 0.5mS. Ad esempio sarebbe comodo poter impostare una task veloce a 0.1ms e poter leggere encoder/finecorsa ed l’eventuale attivazione delle uscite.

    Quello che serve eseguire nella task veloce è la lettura dell’encoder, il confronto sulle quote di attivazione/disattivazione uscite logiche e la gestione delle stesse. Come si evince da questo post, i tempi maggiori sono proprio nella gestione dei moduli periferici (Lettura encoder, gestione uscite) che possiamo determinare in ~620uS. Quindi anche per non occupare tutto il tempo direi che il minimo tempo di esecuzione della task fast può essere impostato in 1 mS.

    In più se supponiamo di creare una task ‘fast’ a 0.1ms, cosa succede qualora il codice all’interno di questa task impiega più di 0.1ms ad essere eseguito ?

    Se il tempo di esecuzione di una task Fast o Slow, supera il tempo di esecuzione definito, l’esecuzione del programma viene arrestata, il sistema si pone in stop e nella variabile SysErCode viene riportato il codice di errore relativo.

    #36701
    Anonimo
    Inattivo

    Dopo aver acquistato un modulo CPU Slimline ed un modulo di I/O con lettura encoder, ho fatto dei test ottenendo dei risultati soddisfacenti, ho un’indeterminazione massima sul comando alle uscite di 2ms, il che corrisponde ad un errore massimo di 0.7 mm, che ritengo accettabile. Quindi sto procedendo a ‘comporre’ il sistema che andrà ad equipaggiare la macchina.

    Poiché devo leggere altri 5 encoder incrementali, al fine di minimizzare il numero di moduli presenti, è possibile leggere un encoder incrementale mediante gli ingressi high speed dei moduli tipo PCB 124*000 oppure devo acquistare 5 moduli PCB 124*000 ?

    #36702
    Sergio Bertana
    Amministratore del forum

    Attualmente è previsto un solo ingresso encoder veloce a 50 Khz per ogni scheda di I/O tipo PCB124*000.

    Da programma è possibile acquisire un encoder in quadratura dagli ingressi logici utilizzando il blocco funzione IOEncoder, incremental encoder over I/O, ma ricordo che gli ingressi logici hanno un circuito di debouncing che introduce un filtro di ca 5 mS, quindi non si può avere una frequenza di encoder maggiore di 200 Hz.

    Quindi l’unica soluzione attualmente disponibile è l’utilizzo di un modulo PCB124*000 per ogni encoder da acquisire.

Stai visualizzando 4 post - dal 1 a 4 (di 4 totali)
  • Devi essere connesso per rispondere a questo topic.