Prolungare Un Impulso Di Una Fc

[acquaman]

Ciao a tutti, ho un problema, ho una fc che legge un piccolissimo particolare in movimento su un vibratore, mi succede che una volta ogni tanto il plc perde il passaggio di un pezzo, io temo che sia il segnale troppo breve ed ogni tanto il plc non lo vede.

Io non ho fondamenti di elettronica, ma avevo informazioni che con un condensatore in parallelo al segnale è possibile prolungare un segnale, è possibile o ho detto una cavolata se si qualcuno sa come realizzare una simile aplicazione.

Grazie

[Livio Orsini]

ma avevo informazioni che con un condensatore in parallelo al segnale è possibile prolungare un segnale,

Si è possibile, am è sempre un accrocco poco affidabile.

Piuttosto leggi quell'ingresso direttamente, con l'accesso diretto alla periferia (PEW); lo fai 2 o 3 volte nel ciclo di programma e così dovresti ovviare l'inconveniente. La soluzione ideale sarebbe entrare in un ingresso veloce a cui leghi un interrupt.

[busanela]

io temo che sia il segnale troppo breve ed ogni tanto il plc non lo vede.

Hai impostato tempi di filtro sugli ingressi? Mi sembra strano che il tempo ciclo di qualche millisecondo di una cpu 300 possa farti perdere il segnale di un sensore nella maniera che descrivi.

[LudB]

Da quello che ho imparato da autodidatta: il tempo di ciclo di una cpu è in pratica l'intervallo di tempo tra le due letture dell'immagine degli ingressi... Non vorrei sbagliare in maniera marchiana, ma le CPU che ho io viaggiano sui 20-30 ms... quindi in teoria se un segnale resta alto meno di 20 ms (nel mio caso) potrebbe non essere stato rilevato dalla CPU.

Non ho capito bene l'applicazione pratica che presenta il problema, ma se conto dei pezzi con un sensore su un nastro trasportatore e ne produco più di 50 al secondo (1000 ms/50 = 20 ms) è probabile che avrò dei problemi se non uso un contatore veloce (cioè una CPU con ingressi appositi).

Se invece il pezzo scorre sotto il sensore così velocemente da non tenere sempre alto il segnale del sensore a sufficienza forse uno potrebbe tentare di risolvere inserendo un sensore con ritardo alla disattivazione (meglio di accrocchi fatti in casa...).

Il tutto va preso con il beneficio di inventario... se ho detto cose errate, correggetemi pure, così imparo anch'io...

Ciao.

LudB.

[Gianmario Pedrani]

l'unica soluzione per ovviare al tuo problema e' utilizzare gli interupt che tipo di cpu hai utilizzato? hai detto 300 ma dice molto poco. se e una cpu di nuova generazione con ingressi e uscite a bordo dovresti verificare se nella configurazione hardware pupi anilitare l 'interupt sull 'ingresso e poo elaborare Ob40 che e ' l 'ob di interupt.

[Livio Orsini]

Il filtro d'ingresso provoca un ritardo sul fronte di salita dell'impulso, però provaca un ritardo simile anche al fronte di discesa, percui lìimpulso risulta traslato nel tempo ma non nella durata.

Il tempo di ciclo della CPU deve essere minore della metà della durata minima dell'impulso, questo assunto ha una giustificazione teorica con il teorema di Shannon.

Pertanto se, ad esempio, il tuo impulso ha una durata minima di 20 ms, il tempo di ciclo della CPU deve essere <10ms in qualsiasi condizione.

Però questo non basta. Anche il tempo di ripetizione dell'impulso ha la sua importanza.

Sempre a titolo esemplificativo.

Con un tempo di ciclo <10ms si possono acquisire con sicurezza impulsi di durata minima di 20 ms per il livello "1" e per il livello "0".

[dott.cicala]

Ciao a tutti!

Questo problema non mi è nuovo.

Rilevare un impulso di x ms (forse 4 ma anche meno) ogni 250ms con una 315-2dp 2ah14, con tempo ciclo di 4ms, niente 321-7bh01, ma solo una 1bh02. Non sono ammesse modifiche all' hw esistente e deve essere a costo zero. Operare solo via softw.

Soluzione di ripiego:

Speriamo negli 1.5ms della 1bh02,

usamo l'ob35 a 2ms e vi inseriamo proprio il minimo indispensabile per rilevare l'impulso ed emettere il segnale di controllo.

Che ne dite? Non è troppo affidabile proprio per i motivi che ha esposto Livio....

Secondo voi - A costo zero - c'è una soluzione migliore?

Già provato a leggere la pew, ma.....non rende molto di più

Ciao!

[Livio Orsini]

Già provato a leggere la pew, ma.....non rende molto di più

Non è questione di rendimento ma, come ben sai, nella PEW c'è lo stato immediato di quegli ingressi, mentre nel registro immagine c'è lo stato aggiornato al termine dell'ultima scansione.

Se non leggi lo stato immediato è inutile andare aleggere l'ingresso ogni 2 ms, tanto il valore che leggi è sempre quello dell'ultimo aggiornamento dei rigistri immagine.

Con una lettura ogni 2 ms, ammesso che il filtro Hw abbia un ritardo pressochè costante, puoi leggere sicurezza un impulso (quasi) simmetrico di durata di 4ms.

[dott.cicala]

Buon pomeriggio!

ho usato un termine inadatto:

Con "non rende" volevo dire: "non ho notato significative differenze".

Purtoppo, avendo eseguito l'intervento da remoto, non ho potuto effettuare misure sulla durata dell'impulso,

ho avuto solo il feedback dal chiente, del tipo: va bene-non va bene.

Però, se il mio modulo di ingressi ha una risposta tra gli 1.2 e 4.8ms (secondo il produttore), ho un tempo di scansione non costante (OB1) di oltre i 5ms (max 10),

non si verificherebbe quanto segue?

1) se eseguo la mia istruzione in OB1 anche se leggo la pew, il risultato dell'operazione logica sarà condizionato dal tempo di OB1

2) se l'ingresso ha un tempo di risposta di 3ms, pur leggendo la pew, il valore aggiornato ce l'ho solo dopo 3ms e perderei tutti gli impulsi di durata inferiore o uguale.

Se invece eseguo l'interrupt (OB35) ogni 2ms, il risultato dell'operazione logica lo avrò ogni 2ms, anche se magari l'ingresso non si è aggiornato.

Ed è qui che si presenta il primo grado di inaffidabilità.

Ma come ho premesso, (lasciatemi sperare) ottimisticamente considero che l'ingresso risponda in 1.5ms, a questo punto, eseguento la mia piccola istruzione nell'interrupt ogni 2ms, che differenza fa se vado adi interrogare la eb0 invece che la peb0?

Dovrei avere un risultato attendibile per un segnale la cui variazione non sia inferiore a 4ms.

Se avessi fatto tutto ciò in OB1, sia pur leggendo la pew, peb che dir si voglia, sarebbe trascorso tutto il tempo di scansione, che non è costante, prima di avrer un nuovo risultato dell'operazione logica...(una semplice xor).

Lo scopo qual'è?

Controllare che da una macchina sia stata effettuata correttamente l'espulsione di un piccolo particolare di scarto che viene letteralmente spruzzato via....come ho già detto, a costo zero, altimenti non ci sarebbero problemi...

Dopo le modifiche che ho descritto, probabilmente perchè la durata dell'impulso è maggiore ai 4ms, non si sono più verificati incidenti.

Che ne dite, la mia elucubrazione è corretta?

Ciao

[Livio Orsini]

Il problema è il tempo di ciclo.

I registri immagine degli ingressi sono aggiornati prima del ciclo di lavoro del PLC; al termine del ciclo vengono aggiornati i registri immagine delle uscite.

Se il ciclo di programma dura, per esempio, 10 ms tu puoi anche leggere l'ingresso ogni 2 ms ma leggi sempre lo stato dell'ingresso com'era nell'istante di aggiornamento del registro. Quindui se il tuo tempo di ciclo è di 10 ms tu per 5 volte leggi sempre la medesima informazione indipendentemente dalla variazione fisica dell'ingresso. Per assurdo, am non tanto, potresti avere un ingresso che varia 2 volte per ogni ciclo ma tu la variazione non la leggi mai!

Questo fatto lo ha dismostrato Shannon circa un secolo addietro e sta alla base dei sistemi campionati. Nel caso del PLC il tempo di campionamento, se usi i registri immagine, è il tempo di ciclo, non il tempo che intercorre tra una lettura e l'altra dell'immagine dell'ingresso.

Al contrario se leggi direttamente la perifieria, tramite PEW, leggi lo stato dell'ingresso in quel momento. Ovviamente il ritardo del filtro Hw te lo ritrovi sempre, ma questo è (quasi) una costante.