Gestire un misuratore di portata ad impulsi
Home › Forum › Controllori SlimLine e Netsyst (LogicLab) › Gestire un misuratore di portata ad impulsi
- Questo topic ha 4 risposte, 1 partecipante ed è stato aggiornato l'ultima volta 5 anni, 1 mese fa da
Alessandro Campodonico.
-
AutorePost
-
Febbraio 17, 2020 alle 8:51 am #53188
Alessandro Campodonico
PartecipanteDovrei acquisire un misuratore di portata ad impulsi, premetto che ho gia letto e riletto vari topic nel forum, ma sono un po confuso. Non mi è molto chiara la differenza tra usare il FB SysGetPhrDI o SysGetCounter. Sicuramente ho capito che per usare SysGetCounter bisogna avere a disposizione una CPU che abbia un ingresso Counter dedicato e sin qui tutto ok.
Nel caso si utilizzasse SysGetCounter si avrebbe la possibilita di una lettura piu veloce degli impulsi rispetto a usare SysGetPhrDI. quale delle 2 FB è piu performante? Insomma, sono rimasto un po confuso dalle varie letture del forum.
Le caratteristiche del sensore sono le seguenti:
Range di flusso: 0,5..20 l/min
Alta risoluzione, 6000 pulsazioni al litro per l’acqua
Range di viscosità: 1..1000 CSt
Accuratezza: ± 1% dell’intera scala
Ripetibilità: ± 0,3% dell’intera scala
Intercambiabilità2): ± 2% dell’intera scala
Temperatura: -20..90°C (non condensante)
Segnale in uscita: Pulsazioni; 100..2000 Hz
Risoluzione: Circa 6000 pulsazioni per litro
Alimentazione: +5..24 Vdc, 12..36 mA
Cavi elettrici: 3 cavi piatti, 15 cmFebbraio 17, 2020 alle 9:03 am #53295Sergio Bertana
Amministratore del forumSysGetPhrDI: Si esegue l’acquisizione degli ingressi digitali da programma e si controlla lo stato gestendo sui fronti di variazione il valore di conteggio. Con questo tipo di acquisizione si possono acquisire segnali la cui durata è maggiore del tempo di esecuzione del programma, ammettendo di eseguire il programma nella task Fast eseguita ogni mS il segnale in ingresso deve durare più di 1mS.
SysGetCounter: L’hardware acquisisce il segnale e lo conteggia, in questo caso possono essere acquisiti segnali la cui durata è compatibile con la frequenza massima di acquisizione del modulo. Sul modulo CPU la frequenza è 10Khz, quindi il segnale deve durare per più di 100uS, sul modulo PCB124 la frequenza è 50Khz, quindi il segnale deve durare per più di 20uS.
Nel tuo caso devi calcolare la frequenza di uscita alla portata che avrai (Alla massima portata 20 l/min avrai circa 2000Hz), ma attenzione si può usare il parametro di frequenza solo se il duty-cycle del segnale in uscita è il 50%. Molti sensori danno in uscita un segnale che stà attivo solo per pochissimo tempo e quindi è importante sapere il tempo di attivazione del segnale oltre alla sua frequenza.
Febbraio 22, 2020 alle 7:09 am #53362Alessandro Campodonico
PartecipanteMi è arrivato il sensore, e ho iniziato a fare delle prove. Sto utilizzando il FB SysGetCounter, e riesco a leggere gli impulsi ovviamente sotto forma di counter. Mi servirebbe però un aiuto nella scrittura di un programma che mi calcoli i litri al minuto istantanei in base agli impulsi. Quello che ho realizzato io adesso è il seguente.
LI:=LI+1; IF (LI < 100) THEN RETURN; END_IF; LI:=0; LITRI:=CONT.Value-Counter; Counter:=CONT.Value; ISTA:=LITRI*0.0001666666*600.0;
Praticamente ogni 100 ms calcolo la differenza tra il Cont.value e Counter (la differenza sarebbero gli impulsi in 100ms). La costante 0.0001666666 sarebbe il calcolo da 6000 impulsi su litro e trovo praticamente i litri ad impulso e moltiplico per 600.0. Quello che ho fatto io pare che funzioni abbastanza, ma mi da l’idea che sia poco sicuro, nel senso che quando il counter raggiunge il suo limite e si reinizializza non so che succede.
Altro limite è che confrontando ogni 100ms il numero degli inpulsi è un valore abbastanza piccolo quindi con minima variazione si ha una differenza del risultato abbastanza grande. Potreste suggerirmi qualcosa?
Febbraio 22, 2020 alle 8:10 am #53598Sergio Bertana
Amministratore del forumDa quello che vedo mi sembra di capire che stai eseguendo il tuo programma di calcolo nella task Fast ad 1mS, e gestisci il tempo di acquisizione (100mS) contando le esecuzioni del programma.
Intanto ti direi di eseguire il tutto in task di Back, se acquisisci il conteggio con il FB SysGetCounter non hai bisogno di velocità di acquisizione è l’hardware a gestire il conteggio. Con la funzione SysGetSysTime puoi temporizzare il calcolo con il tempo che desideri.
Ti consiglio di dare una occhiata al programma ST_SpeedCalculation in questo articolo, se vuoi essere più preciso alle basse portate puoi modificare il tempo di campionamento in modo dinamico in base al valore di lettura.
In merito al roll-over del conteggio, non devi preoccuparti perchè eseguendo i calcoli con tutte variabili dello stesso tipo UDINT, i calcoli sono corretti anche sul roll-over del contatore.
Febbraio 25, 2020 alle 2:55 pm #53647Alessandro Campodonico
PartecipanteHo preso spunto dal programma che hai postato. queste sono le istruzioni:
IF (SysFirstLoop) THEN TimeBf:=SysTime; END_IF; K:=6.0/TO_REAL(Sec); (* Costante per risultato divisione *) Sec:=500; (* Tempo in millisecondi *) IF ((SysTime-TimeBf) < Sec) THEN RETURN; END_IF; TimeBf:=SysTime; (* Time buffer (uS) *) (* Calcolo litri ogni volta che è passato il tempo "Sec" *) MemoCtr:=CONT.Value-MemoCtr; (* Memo counter *) L_Min:=((TO_REAL(MemoCtr)*1.815714)*K)/2; (* Litri istantanei (L/Min) *); MemoCtr:=CONT.Value; (* Memo counter *) (* [End of file] *)
Poi per migliorare un po la risoluzione ho settato CONT.Mode A 64 cosi da contare anche gli impulsi sul fornte di discesa ed avere il doppio degli impulsi, come si nota nella stringa di calcolo L_Min alla fine divido il risultato per “2”
-
AutorePost
- Devi essere connesso per rispondere a questo topic.