fbpx

Solitamente utilizzo un design queued state machine e quasi sempre ho necessità di avere oltre messaggi gestiti una tantum, altri che devono reiterare continuamente in polling (es. acquisizione dati, letture da strumenti ecc.).

In un frame work complesso si possono verificare condizioni in cui i messaggi si accumulano saturando la coda.

Questo avviene quando il messaggio di reiterazione viene richiamato da più loop.

In questo esempio abbiamo estremizzato la situazione, il controllo Ciclo? È settato come mecahnical action ad interruttore, così se celo dimentichiamo a true viene accodato Il messaggio “Ciclo” continuamente.

Siccome Ciclo nel CONSUMER reitera se stesso riaccodando il messaggio Ciclo.

L’effetto è che il buffer della coda si inizia a riempire e se si prova a premere Exit, l’applicazione viene terminata solo dopo diverso tempo .

 

reiteraCiclo

 

 

 

 

 

 

 

 

 

 

Per evitare questo inconveniente viene proposto l’utilizzo del timeout per eseguire il polling.

 

reiteraCicloTimeOut

 

 

 

 

 

 

 

 

 

 

Ora però non gestisco più il ciclo a chiamata, ma a tempo, cosa che volevo evitare.

Se invece  guardate l’esempio che segue:

reitera solo se

 

 

 

 

 

 

 

 

 

 

Notate che il Get Queue impostato con “Return elements” a true e utilizzando un Search 1D Array, posso accodare il dato solo se Ciclo non è tra i messaggi in coda.

Nella dispersione dovuta al fatto che i messaggi in architetture complesse sono difficili da cercare, utilizzo spesso incapsulare la coda con il relativo messaggio in SubVI in modo da poterli cercare con maggiore facilità e vederli nell’ Vi Hierarchy.

Ora con un find All Instances diventa più facile verificare questo messaggio.

FindVIs

 

 

Categories: BlogLabVIEW

%d blogger hanno fatto clic su Mi Piace per questo: