- Questo topic ha 5 risposte, 4 partecipanti ed è stato aggiornato l'ultima volta 6 anni, 7 mesi fa da
.
-
Post
-
Stò acquisendo un segnale da una sonda di livello con uscita 4-20mA attiva. Succede che se manca alimentazione alla sonda sono costretto a riavviare lo SlimLine.
Il valore in watch in uscita dalla SysGetAnInp ritorna corretto ma quello in uscita da Average diventa 1.#QNAN e come ultimo errore mi trovo 9983150, Avete una soluzione da propormi ?
Quello che succede è corretto, vediamo perchè ti trovi in questa situazione.
Il modo di acquisizione 4÷20mA è stato pensato volutamente con l’offset a 4mA per controllare l’eventuale interruzione del cablaggio. In caso di interruzione (O nel tuo caso sullo spegnimento del sensore) il valore di corrente in ingresso al convertitore A/D scende sotto i 4mA. In questa condizione il FB SysGetAnInp segnala l’anomalia attivando l’uscita Fault e generando l’errore:
9983150 Il valore ritornato dal modulo analogico non è corretto
In questa condizione non è possibile determinare il valore di ritorno, quindi viene ritornato QNAN che letteralmente significa Not a number. Il valore di QNAN nel formato IEE754 in esadecimale è 16#7F8FFFFF.
Siccome il valore in uscita dal FB di acquisizione è passato alla FB Average se non blocchi l’esecuzione della Average ti troverai a mettere in media un valore QNAN e questo provoca il blocco della FB. La soluzione è bloccare l’esecuzione della FB Average se Fault nella FB di acquisizione. Ecco come:
FBData(Address:=0, Channel:=0, Mode:=AD_CURR_4_20_DIFFER);
IF NOT(FBData.Fault) THEN AvValue(Value:=FBData.Value); END_IF;Allego il programma TestNaN, ecco la stampa ed il progetto per il download.
Salve, lavoro nuovo, problemi nuovi. Mi riallaccio a questo discorso perché sono interessato sia alla media che al problema del Fault.
Per problemi impiantistici, non posso usare la vostra funzione Average ma ho dovuto crearmi una mia procedura dove il tempo di media è definibile dal programma. Dal punto di vista algoritmico non ci sono problemi, quello che mi preoccupa è il comportamento del segnale Done di SysGetAnInp.
Il manuale è molto vago al riguardo e recita: “Done (BOOL) Analog data acquired. Activated if the analog inputs acquisition, has terminated“. Non dice nulla su cosa succede dopo, Done torna FALSE? Se sì quando, alla fine del Loop o al prossimo Start Conversion? Se torna basso alla fine del Loop potrei risparmiarmi lo R_TRIG se non torna mai basso non saprei proprio come risolvere il problema.
Altra domanda relativa al Fault, se va a TRUE lo fa anche Done? Purtroppo al momento l’hardware è anccora in ordine per cui non posso ancora fare esperimenti.
Che valore restituisce SysGetAnInp con AD_CURR_4_20_DIFFER? un REAL da 0 a 16, da 4 a 20 o da 0 a 20?
Allego un breve spezzone di codice:ClFLOW(Address:=0, Channel:=4, Mode:=AD_CURR_4_20_DIFFER);
RtA_5(CLK:=ClFLOW.Done); (*R_TRIG*)IF (RtA_5.Q) THEN
VClFLOW_C := VClFLOW_C +1;
IF (ClFLOW.Fault) THEN
VClFLOW_V := VClFLOW_V + 0.0;
ELSE
VClFLOW_V := VClFLOW_V + ClFLOW.Value;
END_IF;
END_IF;Mi sembra che stai consultando il manuale in inglese, meglio il manuale italiano che è più completo. Poi venendo alla tua domanda in effetti il segnale Done della FB SysGetAnInp è sempre attivo a meno chè non vi sia un Fault. Da quello che scrivi sembrerebbe che tu vuoi eseguire una media in modo sincrono con la lettura.
Purtroppo il FB attuale esegue una lettura asincrona, non vi è una indicazione di fine lettura, il FB ritorna sempre Done con il valore acquisito precedentemente dall’ingresso analogico. Abbiamo già in previsione in un prossimo futuro di gestire anche un tipo di lettura sincrono. Al momento attuale come workaround puoi semplicemente confrontare il valore acquisito con quello acquisito precedentemente ed a ogni variazione di valore, dato che è praticamente impossibile acquisire lo stesso valore due volte consecutive, corrisponde sicuramente una nuova acquisizione analogica.
Se Fault attivo Done è FALSE.
Il valore ritornato dal FB è un valore REAL e nel modo 4÷20mA, per valori inferiori ai 2mA viene ritornato QNAN per indicare interruzione del cavo.
Sono per caso incappato nel messaggio inviato da lillaz (messagge id: 5552). Vorrei, se possibile, un chiarimento in merito all’uso della funzione Average. Viene segnalato nella risposta (5553) che il blocco average dovrebbe essere eseguito solo se l’acquisizione del valore della sonda avviene con successo; in caso contrario può verificarsi il bloccco dello SlimLine. Io ho questa situazione:
SysGetAnInp.Value –>(input).ValueScale –> (value).Average
Mi chiedo, è sufficente assegnare il segnale fault (invertito) del blocco SysGetAnInp all’ingresso Enable di Average per ovviare a questo problema ?
Il valore QNAN passato al FB Average non blocca lo SlimLine ma perturba il valore di media calcolato dal FB. Pertanto se una acquisizione ritorna un valore QNAN e questo valore lo passi al FB il valore in uscita sarebe falsato.
Mi parli di abilitazione del FB Average, quindi immagino programmi in LD o FBD, disabilitare il FB significa non eseguirlo, ma siccome l’uscita di Fault dura un solo loop di programma mentre il valore in uscita rimane stabile fino alla prossima acquisizione l’FB verrebbe eseguito comunque con in ingresso un valore QNAN.
Ho preso spunto dalla tua segnalazione per modificare l’FB Average in modo da controllare il valore in entrata e se QNAN oppure infinito, blocco il calcolo del valore di media propagando in uscita il valore in ingresso. Ecco lo screenshot del programma, modificando in debug il valore in ingresso è poossibile vedere il comportamento del FB. Allego programma con codice sorgente anche del FB Average.
- Devi essere connesso per rispondere a questo topic.