Conteggio Ruota Dentata

[vashello]

..Il titotlo non spiega bene il problema ma non mi veniva in mente altro:

tutto su siemnes 315dp con simatic step 7 programmato in AWL

in pratica dal lato hardware ho:

una ruota dentata diciamo "calettata", (fissata o non so bene come ma in pratica riporta lo scorrimento di una fune di riferimento, stile carrucola per intenderci, )che funziona come un finecorsa a croce, quindi ogni volta che un dente passa per il riferimento mi va a 1 un bit [impulso più o meno lungoa seconda della velocità e della gardnezza dei denti], e resta a zero fra un dente e l'altro,

i denti sono 30,

Io devo assicurarmi che questa fune non vada in fuga, ovvero non mi scappi via e per fare ciò devo verificare che la velocità di rotazione non sia superiore ad un certo tot, esempio 3.7 giri/minuto, se si supera questa soglia devo generare un allarme,

Io avevo pensato di utilizzare un temporizzatore di tipo SI,per calcolare il tempo di zero,con riferimento negato in ingresso, in modo da valutare dal fronte di discesa di un impulso al successivo fronte di salita, ma il conteggio è a ritroso, da un riferimento verso 0, ma mi trovo un po in difficoltà nel senso che il mio vincolo diviene il tempo di durata dello ZERO, ma il mio vincolo rimane sulla "brevità" di qeusto impulso, e quindi non riescoa valutarlo.

se avete consigli o idee son qua orecchie aperte!!

Grazie mille a tutti!!

[lucios]

Ma se usi un segnale derivato sul fronte di salita del bit e incrementi un contatore e controlli il valore del contatore a cadenza prestabilita non riesci a risolvere il problema?

[Bruno]

Non sono sicuro di aver capito il tuo problema, ma una possibile soluzione potrebbe essere:

1) Ricavi un impulso dall'ingresso del dente.

2) Ad ogni impulso incrementi una double word (nel caso che tu sappia la direzione puoi incrementare e decrementare)

3) Analizzi il tuo conteggio ad una data frequenza (sarà la tua reazione per l'allarme, ma non può essere troppo basso in modo da avere un calcolo corretto)

4) Se tra due controlli il delta del conteggio è più alto di un certo valore (soglia di allarme) setti l'allarme di asse in fuga

Nota

Quando calcoli il delta (valore New - valore Old) tieni conto del segno, se guestisci i due sensi di marcia della ruota.

Ciao

BR1

[walter.r]

Condivido la soluzione di lucios.

In realtà non ti interessa quanto tempo passa fra un dente e l'altro, ma quanti denti passano in una unità di tempo da te definita.

Se crei un contatore, lo leggi ogni ....quanto vuoi, e lo azzeri dopo la lettura perchè possa ricominciare a contare, hai risolto il problema.

Bruno ha postato 1 secondo prima di me, beh, siamo già in tre.........

Modificato: 16 novembre 2006 da walter.r

[Bruno]

Opps...

quando avevo letto la richiesta di aiuto non c'era il messaggio di lucios, che ha suggerito la mia stessa soluzione.

[BIT77]

la soluzione di lucios mi pare buona..il siemens 315 ha ingressi a conteggio veloce?

[mynameisrex]

Se la ruota gira a 3.7 giri/minuto significa che hai un centinaio di impulsi al minuto (30*3.7) e quindi meno di due impulsi al secondo... anche se non hai un contatore veloce, penso tu ce la possa fare comunque.

[Ecup]

Al di là delle soluzioni sw proposte, io in passato ho avuto problemi hw proprio nella rilevazione di impulsi veloci, legati non tanto al conteggio della CPU, ma alla rilevazione vera e propria fatta dal proximity, quindi fai attenzione anche a questo aspetto.

Nel mio caso (se ben ricordo) la ruota aveva 28 fori da rilevare, su una circonferenza di circa 70 cm e velocità massime prossime ai 4 giri/min. A seguito di problemi abbiamo constatato con un oscilloscopio che il segnale proveniente dal proximity non era corretto, quindi su due macchine diverse abbiamo adottato due soluzioni diverse:

-soluzione A- regolazione molto precisa della posizione del proximity (se è troppo vicino tende a mancare gli impulsi dei buchi, se è troppo lontano tende a mancare gli impulsi del ferro); una soluzione di questo tipo prevede una verifica periodica della correttezza della rilevazione

-soluzione B- spostamento del proximity sulla parte più interna della ruota, dove c'erano solo 8 fori. La precisione di rilevazione della velocità diminuisce (ma nel mio caso era sufficiente) ma avevo la certezza di non perdere nessun impulso

[mynameisrex]

Semmai hai il problema contrario : se sei costretto a campionare ogni secondo (data la frequenza molto bassa di conteggio - 1 Hz ???) potrebbe capitare che, se la fune "scappa", tu abbia una tempestività di intervento NON inferiore al tempo di campionamento (1s).

[mynameisrex]

Giustissimo Ecup.

A volte si fanno 1000 artifici software per risolvere un problema hardware... attenzione !

[BIT77]

nche se non hai un contatore veloce, penso tu ce la possa fare comunque. wink.gif

giusto, non avevo valutato la cosa

comunque campionando sul cambio di stato, si dovrebbero limitare le problematiche "hardware"...

[Livio Orsini]

Io devo assicurarmi che questa fune non vada in fuga, ovvero non mi scappi via e per fare ciò devo verificare che la velocità di rotazione non sia superiore ad un certo tot, esempio 3.7 giri/minuto, se si supera questa soglia devo generare un allarme,

Con i dati forniti se la velocità massima è 3,7 rpm, il periodo minimo è pari a 540,54 ms.

Il metodo più sicuro e veloce di controllo è misurare questo perido: se risulta inferiore a questo valore scatta l'allarme. Se si vuole un intervento in un tempo inferiore è sufficiente aumentare il numero dei denti della ruota o, se il rapporto pieno vuoto è simmettrico, contare il tempo tra due fronti.

[vashello]

Grazie a tutti...ora stampo e e leggo per bene!! comunque ebbi trovato una soluzione, penso che vi espongo dopo!! grazieshhh

[vashello]

Ecco coem ho "soluzionato la cosa", in pratica conto solo emzzo ciclo di pseudo-clock, ovvero solo quando è basso l'ingresso!

Ho testatoe funziona, sarà una soluzione un po articolata e un po stramba magari...ma funzica...poi ci si puòs empre migliorare!! Grazie a tutti!!!

//usati bit di merker per provare

U M 80.0 //abilita il conteggioper il temporizzatore T1

FR T 1

UN M 80.1 //abilito il temporizzatore quando l'ingresso dal sensore è a ZERO

L S5T#270MS

SI T 1 //starto il conteggio impulsivo

U M 80.1 //resetto quando l'ingresso è a 1

R T 1

U T 1

= M 80.2 //stato del conteggio, se sta contando è a 1, quindi durante INGRESSO BASSO lo STATO è ALTO

LC T 1

BTI

DTR

T MD 100 //scrivo il valore del temporizzatore in un dw in real

U M 80.1 //analizzo il fronte di salita dello STATO

FP M 80.3

= M 80.5 //bit che sta a 1 per il ciclo in cui l' INGRESSO cambia da BASSO a ALTO

U M 80.2 //analizzo il fronte di discesa dello STATO

FN M 80.4

= M 80.6 //bit che sta a 1 per il ciclo in cui lo STATO cambia da ALTO a BASSO

U M 80.5 //nell'istante in cui scende lo STATO e sale l' INGRESSO

U M 80.6 //mi sta a significare che il periodo di zero è stato troppo breve è quindi genero l'allarme

S M 80.7 //ALLARME stabile, resettabile solo manualmente altrove

[Ecup]

>comunque campionando sul cambio di stato, si dovrebbero limitare le problematiche "hardware"...

Se il segnale è errato in partenza (vedi il mio caso che ho esposto) puoi così farne di giochetti software che incapperai sempre in errore. Onestamente non vedo grossi problemi a livello software per fare un controllo del genere, dico solo di prestare molta attenzione al fatto che impulsi così veloci vengano rilevati correttamente proprio dal sensore, perché in base alla mia esperienza ho già avuto problemi in tal senso

[Livio Orsini]

Matia Sansonetti

vedo due problemi nella tua soluzione, ma posso non aver compreso bene quello che fai.

1 - Se gli impulsi del sensore entrano in un ingresso "normale" hai un ritardo di Hw (circa 10 ms) e un ritardo Sw variabile dipendente dal tempo di ciclo.

2 - I temporizzatori che hai usato, se non erro, hanno una precisione non eccelsa.

Io entrerei in un ingresso veloce, ad interrupt, e conterei il tempo tramite un timer di sistema. Puoi settare il timer a 10ms, così da avere un'indecisione di 1o ms.

[vashello]

Ebbene si avete ragione pure voi...eheh..

per il conteggio HW non dovrebbero esserci problemi, dato che non conta i buchi ma diciamo è come un fine corsa a croce che scatta al passaggio di un asta fissa quindi presumo lo percepisca sempre il segnale...

Il consiglio di livio mi fa riflettere molto, ma vediamo di fare qualche prova fisica almeno sfatiamo tutti i dubbi

Siccome è la prima volta che programmo con Siemens e Awl resta un po bruttino pensando al ST (se SCL non costava così tanto coem pacchetto software ...eheh)...ci siamo avvalsi per iniziare della consulenza dei tecnici dei nostri fornitori di materiale di elettroforniture, e anche loro mi hanno consigliato di usare un SI...

va behhhhhh vedremo..se avete altre idee o consigli son qua!!

GRAZIE a tutti comunque!!

[BIT77]

>comunque campionando sul cambio di stato, si dovrebbero limitare le problematiche "hardware"...

Se il segnale è errato in partenza (vedi il mio caso che ho esposto) puoi così farne di giochetti software che incapperai sempre in errore. Onestamente non vedo grossi problemi a livello software per fare un controllo del genere, dico solo di prestare molta attenzione al fatto che impulsi così veloci vengano rilevati correttamente proprio dal sensore, perché in base alla mia esperienza ho già avuto problemi in tal senso

assolutamente...si! limitare, non eliminare. Comunque con sensori magnetici, anche di dimensioni ridotte, non ho mai avuto problemi, certamente se l'HW non va il software poi non puo fare i miracoli...anche se la scena tipica é questa, si avvicina il progettista meccanico e chiede... "non é che da programma si puo'...."

Io entrerei in un ingresso veloce, ad interrupt, e conterei il tempo tramite un timer di sistema.

anche io !

[walter.r]

Io entrerei in un ingresso veloce, ad interrupt, e conterei il tempo tramite un timer di sistema

Concordo, vista la ..........."rapidità" dei normali input PLC.....

Piuttosto, metterei anche un controllo che manda in allarme il sistema in caso NON vi fosse cambio di stato.

Se il sensore si rompe, o va in corto circuito, o qualcuno lo ponticella ( ), è bene che il sistema arresti tutto.

[BIT77]

Piuttosto, metterei anche un controllo che manda in allarme il sistema in caso NON vi fosse cambio di stato.

Se il sensore si rompe, o va in corto circuito, o qualcuno lo ponticella ( tongue.gif ), è bene che il sistema arresti tutto.

ehi, questo é un colpo di tacco, una finezza...comunque giusto!

[vashello]

Piuttosto, metterei anche un controllo che manda in allarme il sistema in caso NON vi fosse cambio di stato.

Se il sensore si rompe, o va in corto circuito, o qualcuno lo ponticella ( tongue.gif ), è bene che il sistema arresti tutto.

Nahhhh...non ha senso penso erpchè la ruota può stare pure ferma in certi casi, devo solo limitare sulla sua eccessiva velocità non sulla sua eccessiva lentezza.....al massimo come sicurezza potrei ragionare con l'allarme ATTICO allo stato BASSO, e pensoc he lo farò!

comunque facendo due conti il caso più sfigato avrei una frequenza dis egnale di 8 Hz, e a quanto ne so le schede di acuqisizione standard arrivano fino alo Kherz!Poi magari me lo sono sognato io....heheh

BIT77

Comunque con sensori magnetici, anche di dimensioni ridotte, non ho mai avuto problemi /

[Livio Orsini]

....e a quanto ne so le schede di acuqisizione standard arrivano fino alo Kherz!Poi magari me lo sono sognato io....heheh

Cosa intendi per schede di acquisizione standard? Se intendi le normali schede di ingresso digitale te lo sei proprio sognato. Considera che solo i filtri Hw hanno ritardi di qualche ms (leggi le specifiche delle schede d'ingresso). Poi hai il problema della lettura. Se usi i registri immagine questi sono aggiornati solo al termine del ciclo di lavoro del PLC. Se usi la lettura diretta come fai? Leggi in continuo l'ingresso bloccando di fatto tutto il resto del lavoro?

8 Hz significa un periodo pari 125ms, solo per avere la sicurezza di riconoscere l'impulso devi campionare con un periodo <62,5ms; con questo periodo però riconosci solo se c'è stata transizione. Se la ruota dovesse andare in fuga, cioè aumenta la velocità degli impulsi, non te ne accorgeresti.

Quindi o campioni molto più velocemente (<=5ms) o ti basi su un ingresso ad interrupt che, tra l'altro, non ha ritardi Hw.

Questo è il mio parere ed è il modo in cui ho sempre realizzato simili trappole.

[walter.r]

Nahhhh...non ha senso penso erpchè la ruota può stare pure ferma in certi casi...

Matia , ovvio che il controllo lo devi fare "solo" quando sai che la ruota sta girando !!!!!!

Io devo assicurarmi che questa fune non vada in fuga...

Non hai pensato che se il tuo sensore non funziona, il tuo sistema di controllo, comunque tu decida di realizzarlo, non funziona, e quindi viene meno l'ipotesi di progetto ???

Per il modo di effettuare la lettura, dai retta a Livio, credimi.......

Modificato: 17 novembre 2006 da walter.r

[BIT77]

cosa intendi per sensori magnetici...non ne ho presenti, se vuoi linkare qualche sito è ben gradito! wink.gif

Prossimity induttivi

I prossimity induttivi si basano sul principio della variazione di riluttanza che presenta un elettromagnete, quando nelle vicinanze si presenta un oggetto realizzato in materiale ferromagnetico: la comparsa di materiale ferromagnetico all'interno del campo magnetico, fa sì che il campo stesso si chiuda meglio, con conseguente abbassamento della riluttanza. I circuiti interni del sensore rilevano la variazione di riluttanza, e superata una certa soglia, fanno commutare il segnale d'uscita.

Questi prossimity pertanto, possono rilevare solo la presenza d'oggetti realizzati in materiale ferromagnetico; inoltre la portata nominale è genericamente piuttosto bassa (qualche millimetro).

Questi sensori possono commutare il loro stato a frequenze molto elevate, dell'ordine di migliaia di volte al secondo, rendendoli adatti a rilevare oggetti in rapido movimento.

[BIT77]

cerca tra le varie aziende nel settore e troverai quello piu' adatto alle tue esigenze, sempre che ti interessi...ciao!

nel mio caso ruota dentata e prox a 2 millimetri di distanza, non perdeva un colpo..

ciao!

ingresso del proxy su ingresso veloce e via! perchè non usare gli ingressi del contatore veloce e un encoder? perchè sulla macchina in questione avevo già 3 encoder, e un modulo di conteggio costava di piu' che un fc magnetico...

Modificato: 17 novembre 2006 da BIT77