Sviluppare Da Velocita Impulso = Velocità In Cm/min - Impulsi ruota fonica velocita=tempo=Velocità in cm/min

[TravelMen]

Allora, adesso fai prima a postare l'OB35 ed OB 40 ed anche OB1, non serve tutto il programma ma solo le parti che hai scritto per eseguire il conteggio degli impulsi e del tempo, così è più facile per noi vedere dove sbagli, se riesci anche una piccola descrizione della "funzione" ed il perchè non sarebbe male, ma sopratutto indica con precisione tutte le variabili.

Perchè applicazioni di questo genere sono "semplici" ma richiedono attenzione hai piccoli dettagli.

[Livio Orsini]

il passo dei denti della ruote ed e esattamente 12mm

Allora Vmax = 500 mm/1' ===> 41,66666 impulsi/1' ==> 0.694444 impulsi /1" ===> periodo > 1.44"

La velocità è inversamente proporzionale al periodo; facendo le proporzioni tra velocità massima e periodo minimo,scritto in forma analitica, si avrà:

v = 500*1.44/T

Se misuri, ad esempio, 2,88" avremo una velocità di 250 mm/1' o, se preferisci di 25 cm/1'.

Se cambi o rilevi altri errori di misura devi solo correggere le costanti, anzi la costante equivalente al periodo minimo (velocità massima). Se invece cambi solo la velocità massima di riferimento, la relazione rimane valida. Anzi puoi ricalcolarti la costante di proporzionalità ricalcolandoti il periodo per un'altra velocità, se questo ti facilita le cose.

[batta]

Io lascerei perdere l'OB35.

Se il periodo è sufficientemente lungo da poter accettare il tempo di scansione come errore, la soluzione più semplice consiste nel sommare, ad ogni scansione, la durata della scansione precedente (vedi OB1_PREV_CYCLE).

Quando si verifica l'evento, si legge il valore raggiunto e si azzera.

Il tutto senza bisogno di tirare in ballo interrupt.

Se invece si ha bisogno di maggior precisione e si decide di ricorrere ad un iterrupt, la scelta migliore consiste nel rilevare il tempo trascorso dall'interrupt precedente sfruttando direttamente le variabili messe a disposizione dall'OB di interrupt stesso, che permettono il calcolo del periodo con la precisione del millisecondo.

Usare un interrupt per andare poi a leggere il valore di una variabile incrementata in OB35, non ha molto senso.

Esempio:

- l'interrupt lancia OB40 "HW_INT0"

- effettuo il controllo di quale evento ha avviato l'interrupt (quale ingresso, se fronte salita o discesa). Se c'è un solo ingresso configurato come ingresso di interrupt, e se si valuta solo il fronte di salita, posso evitare di fare controlli e passare direttamente alla valutazione del tempo.

- in OB40 richiamo la funzione "DT_TOD" (FC8 in standard library -> IEC Function Blocks -> Blocks), passandogli la variabile "OB40_DATE_TIME". che contiene data e ora di avvio di OB40. La funzione restituisce i millisecondi trascorsi dalla mezzanotte. A questo valore sottraggo il valore memorizzato durante il precedente richiamo di OB40. Se il risultato è negativo (richiami di OB40 a cavallo della mezzanotte), sommo L#86400000 (ms in un giorno). Il risultato è il tempo trascorso dal precedente interrupt con precisione di 1ms.

- basta poi memorizzare il valore restituito da "DT_TOD" per il prossimo interrupt.

Basta provare. E' più difficile da spiegare che da fare.

[Livio Orsini]

Batta leggiti un po' tutto, così capisci che non ha a disposizione l'ingresso da interrupt.

La soluzione da OB40 era stata ipotizzata subito: messaggi #2 e #4

Se il periodo è sufficientemente lungo da poter accettare il tempo di scansione come errore,..

Quant'è l'errore sul tempo di scansione? Poi le devi somamre all'errore sul riconoscimento del fronte, poi lo devi sommare agli arrotondamenti. Già con interruopt si arriva ad alcuni %

Modificato: 12 febbraio 2010 da Livio Orsini

[batta]

Scusa Livio, non è per polemica, ma io leggo quanto segue:

Messaggio #8:

- Nell'OB35 fai un semplice conteggio, ad ogni interrutp incrementi un contatore.

- Leghi gli impulsi ad un ingresso veloce ad interrupt (OB40), al primo impulso leggi il contaotre di OB35 e lo memorizzi, al secondo impulso rileggi il contatore

Messaggio #17:

Inserisci in OB35 quelle 3 righe di codice e solo quellle. Se hai configurato OB35 come ti ho scritto e come ha spiegato abbondantemente TraveMen, ogni volta che scatta l'interrupt di tempo s'incrementa il contatore.

Poi leghi l'ingresso della ruota fonica ad un ingresso veloce ad interrupt.

Messaggio #21:

Per l'interrupt esterno.

Devi avere o una CPU con ingressi veloci, oppure una scheda di input digitale per ingressi veloci (interrupt di processo). Nella configurazione Hw ne configuri uno in modo che generi un interrupt ad ogni fronte di salita. A quell'ingresso colleghi il sensore della ruota fonica. Poi nell'OB di interrupt, associato a quell'evento nella configurazione HW, scrivi le istruzioni che leggono la differenza.

Non mi pare che la strada dell'interrupt fosse stata del tutto abbandonata e, se si usa l'interrupt, non serve OB35.

Escluso l'interrupt, usare OB35 può migliorare la precisione solo se, come giustamente suggerisci nel messaggio #24, si rileva il fronte dell'ingresso con la lettura diretta della periferia, e non leggendo lo stato dall'immagine degli ingressi.

La soluzione con l'utilizzo di OB1_PREV_CYCLE ha il vantaggio di essere semplicissima, e di commettere l'errore massimo di una scansione.

Il ritardo sulla lettura dell'ingresso è, con buona approssimazione, ripetitivo. Quindi, se leggo l'ingresso alto con 3ms di ritardo, lo leggerò sempre con 3ms di ritardo e non commetto errore.

Il caso peggiore è quando lo stato alto dell'ingresso arriva appena dopo l'aggiornamento dell'immagine. In questo caso, mi accorgo del cambiamento di stato solo alla successiva scansione e sommo quindi il tempo di una scansione in più.

Se i tempi di scansione sono accettabili, forse non vale la pena di passare ad OB35 e letture diretta della periferia, considerando le difficoltà che sembra incontrare il nostro amico.

[Livio Orsini]

Nessuna polemica, è solo che a volte entrando dopo un po' di messaggi sfugge qualche cosa. C'erano state un paio d'ipotesi di soluzione

La soluzione con l'utilizzo di OB1_PREV_CYCLE ha il vantaggio di essere semplicissima, e di commettere l'errore massimo di una scansione.

Concordo, il problema è quanto può durare la scansione e che può avere tempi diversissimi.

Comunque l'uso di OB35 è semplice e comporta solo due istruzioni, quindi nessun appesantimento. Poi dipende sempre dal grado di precisione richiesto.

Il caso peggiore è quando lo stato alto dell'ingresso arriva appena dopo l'aggiornamento dell'immagine.

Quindi se il tempo di ciclo è stato di, per esempio, 10 ms hai un errore di riconoscimento di 10 ms che nel caso pessimo si può raddoppiare perchè ti capita su due impulsi successivi.

E' anche vero che statisticamente il fornte tenderà a capitare nel mezzo di due aggiornamenti, però l'errore massimo può essere anche grande.

Però prima di fare congetture bisognerebbe sapere il tempo medio di ciclo, magari la CPU non fa niente ed il tempo di ciclo è di unpaio di ms

[batta]

Quindi se il tempo di ciclo è stato di, per esempio, 10 ms hai un errore di riconoscimento di 10 ms che nel caso pessimo si può raddoppiare perchè ti capita su due impulsi successivi.

No. Rimane sempre, al massimo, quello di una scansione. O meglio, per essere precisi, +/- il tempo di una scansione. La media delle misure è invece esatta.

Se si utilizza lo stesso sistema in OB35, si ha il vantaggio di sapere con precisione quale sarà l'errore massimo.

[Livio Orsini]

No. Rimane sempre, al massimo, quello di una scansione.

Se il tempo di ciclo è molto variabile rischi che, se i due impulsi capitano appena prima ed appena dopo l'aggiornamento del tempo di ciclo, l'errore sia molto più grande.

La cosa mi ha incuriosito al punto che appena ho un attimo di tempo e voglia mi metto giù un diagramma di temporizzazione per veirficare il caso pessimo

[tecnologyassistence]

Ringrazio Livio e Flavio ma credetemi sarà cosi banale da fare ma è un vero dilemma ho provato tutte le ipotesi non si riesce proprio a gestire in modo corretto e quindi avere la giusta misura cm/min non vorrei abbandonare la possibilità di realizare ciò creando questo benedetto calcolo perchè altrimenti avrei una soluzione che sarebbe una dinamo tachimetrica che non vorrei utilizzare ma vorrei tanto riuscire a superare questo problema che per quanto banale sia e diventato per me un'ostacolo.

il discorso di avere questa precisione sta nel fatto che il materiale in lavorazione che sarebbe pietra lavica se non avanza in modo corretto la lucidatura non avviene per come dovrebbe essere tutto qui ragazzi confido in voi perche non so più cosa provare. dimenticavo la velocita e molto lenta ogni impulso si ha circa 1secondo e 200ms per volta e cioè ogni 12mm ho un impulso comunque non ci sono alte velocità e unaltra cosa e che non ho ingressi veloci nella cpu e una 3152DP.

grazie Domenico

Modificato: 14 febbraio 2010 da tecnologyassistence

[Livio Orsini]

Scusa Domenico ma cosa non riesci a fare?

Partiamo dalla prima soluzione: interrupt ogni 10 ms in OB35.

Sei riuscito a conteggiare gli interrupts?

Sei in grado di leggere direttamente la periferia, leggendo direttamente l'ingresso del sensore?

Se fai regolarmente queste due cose, cos'è che non riesci a fare?

[tecnologyassistence]

Ciao Livio dunque parto dal presupposto che non ho dimestichezza con la gestione interrupt non l'ho usata quasi mai nell'hardware ho impostato ob35 a 10ms dentro ob35 ho scritto questo per come mi avevi indicato

L "DB023".DB023_042

L 1

+I

T "DB023".DB023_042

a questo punto vedo incrementare la db23.dbw42 presumo che questo sia il conteggio che dici tu nr.interrupt non ho capito bene come il mio ingresso E6.0 che sarebbe il sensore che legge i denti della ruota lo devo gestire non ho capito come.

devo eseguire sempre tutto dentro ob35?

[Livio Orsini]

devo eseguire sempre tutto dentro ob35?

No, assolutamente. Nell'OB35 gestisci solo l'incremento.

L'ingresso E6.0 lo leggi tramite un'istruzione di PEW che è l'istruzione che permette di leggere direttamente da periferia hw (consulta il manuale o l'help in linea per PEW e PAW)

Per esempio in OB1 che è il blocco main con cui richiami i vari OB, FB e FC, scrivi una serie di PEW per leggere il tuo ingresso. QUando riconosci il cambio di stato da 0 a 1 leggi e memorizzi il valore di db23.dbw42. Al successivo cambio di stato tra 0 e 1 rileggi e rimemorizzi il valore di db23.dbw42 . La differenza dei due valori, moltiplicato per 10, ti da il tempo in ms del periodo. A questo punto calcoli la velocità come ti ho indicato nel post precedente.

Modificato: 14 febbraio 2010 da Livio Orsini

[batta]

Io farei così:

- in configurazione hardware imposti OB35 per l'esecuzione ogni 10ms

- nell'esempio, il segnale di cui si deve rilevare il fronte è collegato all'ingresso E0.0

- in OB35 scrivi il seguente codice:

//Incremento la variabile DB23.DBW42 del tempo diesecuzione di OB35,
//leggendo questo tempo dalla variabile locale OB35_EXC_FREQ.
//Così facendo, se cambio il tempo di esecuzione di OB35 il calcolo
//del tempo è sempre corretto, senza bisogno di apportare correzioni
//per adeguarsi alla nuova configurazione di OB35.
      L     DB23.DBW   42
      L     #OB35_EXC_FREQ
      +I    
      T     DB23.DBW   42


//Lettura diretta del byte di periferia contenente l'ingresso
//del quale devo rilevare il fronte di salita
      L     PEB    0
      L     2#1
      UW    
      L     2#1
      ==I   
      FP    M     20.0                  //Merker per fronte salita
      SPBN  EXIT
//Muovi il conteggio raggiunto in variabile da utilizzare
//per calcoli velocità in qualsiasi altra parte del programma
      L     DB23.DBW   42
      T     DB23.DBW   44

//Azzera conteggio
      L     0
      T     DB23.DBW   42

EXIT: NOP   0

Nell'esempio, la variabile DB23.DBW44 contiene il tempo in ms intercorso tra due fronti di salita del segnale, e rimarrà invariata fino al rilevamento del fronte successivo.

Puoi usare questo valore in qualsiasi parte del programma per effettuare il calcolo della velocità.

Volendo, potresti gestire anche un merker da settare ON in OB35 nel momento in cui aggiorni DB23.DBW44, ed effettuare il calcolo solo quando questo merker è ON.

Alla fine del calcolo, resetti il merker.

[tecnologyassistence]

Grazie Flavio ti farò sapere come provo il tutto.

Saluti Domenico

[batta]

Più che sapere se funziona, mi farebbe piacere sapere che hai capito perché funziona.

Se ci sono punti oscuri, fai domande specifiche e vedremo di fare luce.

[tecnologyassistence]

ciao Flavio grazie per l'aiuto tu e Livio mi avete schiarito abbastanza le idee ho capito come funziona adesso ho fatto delle prove come valore da calcolare se ad esmpio viene fuori un valore di 9600 dovrei moltiplicarlo a quale valore? ho capito come funziona la scansione finalmente grazie al tuo aiuto per la prima volta ci sbatto la testa su l'ob35 quindi ho capito bene devo eseguire la moltiplicazione? ma non ho capito il calcolo preciso da fare per poi trasferire il valore al pannelo

grazie Domenico

Modificato: 16 febbraio 2010 da tecnologyassistence

[batta]

Se sei riuscito a misurare il tempo intercorso tra un impulso e l'altro, e sai a quanto spazio corrisponde un impulso, si tratta solo di fare un semplicissimo calcolo:

Velocità = Spazio / Tempo

Poi si tratta solo di adeguare le unità di misura.

Per esempio:

1 impulso = 1cm

Tempo tra due impulsi = 960ms (dici che ti risulta 9600. Stai andando molto piano o c'è qualche errore?)

Se desideri la velocità in cm/minuto, dato che lo spazio è già in cm, mentre il tempo è in ms, devi moltiplicare il risultato della divisione per 60000 (millisecondi in un minuto).

Esempio:

Velocità = 1 * 60000 / 960 = 62,5 cm/minuto

[tecnologyassistence]

Ciao Flavio allora intanto ti ringrazio per avermi aiutato a risolvere un problema adesso funziona alla perfezzione davvero molto preciso eseguo il calcolo e trasferisco il risultato al pannello operatore visulizando quindi tutto in real time anche se cambia di pochissimo la velocità si riesce a variare il dato perfettamente ho solo una piccola perplessità cioè il mio ingresso che legge gli impulsi in ob35 lo utilizzo cosi come mi hai detto:

L PEB 0

L 2#1

UW

L 2#1

==I

FP M 20.0 //Merker per fronte salita

SPBN EXIT

ma essendo che viene utilizzato in un fc che mi fa gestire il mio shift register mi potrebbe creare problemi?

ti ringrazio ancora e ringrazio anche Livio per avermi aiutato a tutti gli amici e colleghi del forum spero che tutto questo possa tornare utile.

buon lavoro a tutti e grazie Domenico

[batta]

Intanto c'è da dire che le istruzioni

L PEB 0

L 2#1

UW

L 2#1

==I

Sono valide solo se l'ingresso al quale è collegato il segnale è E0.0.

Dovresti sostituire 2#1 con 2#10 se l'ingresso è E0.1, 2#100 per E2.2, ... 2#10000000 per E0.7.

Altro sistema potrebbe essere il seguente (esempio sempre con E0.0):

L PEB0

T MB19

U M19.0

FP M20.0

...

...

...

Per venire invece alla tua domanda, non capisco cosa intendi con:

ma essendo che viene utilizzato in un fc che mi fa gestire il mio shift register mi potrebbe creare problemi?

Quello che ti posso dire è che in OB35 leggi lo stato del byte EB0, ma non lo alteri.

Il fatto di leggere il byte EB0 con l'istruzione

L PEB0

al posto di

L EB0

produce l'effetto di leggere lo stato reale degli ingressi nel momento stesso in cui fai l'interrogazione, anziché leggere l'immagine degli ingressi salvata ad inizio scansione.