FIFO per eseguire un azione

[gepponline]

...ma ciao!
ho un applicazione in cui devo eseguire una certa azione trascorso TOT tempo da un segnale di trigger.
Tra il trigger e il tempo dell'azione, mi puo' arrivare un altro trigger pero', quindi non posso semplicemente ritardare ma devo in qualche modo creare una coda, fifo o qualche altro tipo.
Qual'e' la soluzione migliore secondo voi usando LabVIEW?
Esistono degli strumenti già implementati a questo scopo magari?
grazie!

[paracarro]

...ma ciao!
ho un applicazione in cui devo eseguire una certa azione trascorso TOT tempo da un segnale di trigger.
Tra il trigger e il tempo dell'azione, mi puo' arrivare un altro trigger pero', quindi non posso semplicemente ritardare ma devo in qualche modo creare una coda, fifo o qualche altro tipo.
Qual'e' la soluzione migliore secondo voi usando LabVIEW?
Esistono degli strumenti già implementati a questo scopo magari?
grazie!

Non hai specificato cosa vuoi che succeda quando il secondo trigger interviene, cmq ti ho confezionato questo esempio che spero possa esserti utile.

NotifierTimeout.vi

LV2016

(18.08 KiB) Scaricato 181 volte

In un vecchio progetto avevo un certo numero di questi loop in cui un notifier attendeva un evento per un certo periodo di tempo: il passaggio di oggetti da una antenna RFID generava un evento che resettava ogni volta l'attesa. Se gli oggetti non passavano dall'antenna per un certo periodo di tempo, voleva dire che probabilmente questi oggetti si erano incastrati da qualche parte. L'uscita dall'attesa di notifica per timeout rappresentava un allarme.

bye

[gepponline]

Grazie per la risposta, poi come avviene spesso, subito dopo al momento in cui chiedo aiuto, arriva il "lampo di genio"
In effetti non ho specificato che il secondo e i vari trigger seguenti fanno la stessa cosa che fa il primo trigger. Cioè scatenano un evento che fa eseguire un azione sempre uguale alla macchina.
Allego il riassunto di quello che ho sviluppato sfruttando le code usando come hai fatto tu un indicatore stringa per dare un idea.
C'e' qualche criticità in questo tipo di approccio secondo te?

[paracarro]

LabVIEW 2016, please!

Cmq per fare quello che vuoi tu, basterebbe creare una istanza di un VI rientrante che fa quello che deve fare quando scatta il trigger: la prima cosa che farà questo VI è attendere un tempo congruo prima di procedere.

bye

[gepponline]

C'e' qualche problema al server e non mi lascia uploadare file.
Ci riprovo piu' tardi.

[gepponline]

Ok, ho messo un snippet fatto con la 2012, dovrebbe andare

[paracarro]

Ciao.


Scusami Geppo, ma... non mi piace.

Usi una coda contenente un timestamp, ma poi fai un polling disperato sull'orologio di sistema.

Il ritardo dal trigger, poi, può cambiare anche durante l'attesa e necessariamente deve essere lo stesso per tutti i trigger generati che sono pendenti

Cmq dipende da quello che devi fara.

Se a te va bene, va bene pure a me.

bye

[gepponline]

Considera che il ciclo va temporizzato, qui mi son dimenticato e che il tempo di attesa potrebbe anche essere inserito nella coda insieme al timestamp.
Ma detto questo, e' per questo che ho chiesto qui.
Il problema di usare eventi o notifier o cose simili era che l'evento mi scatena subito un azione.
Per ritardare l'azione dovrei temporizzare, ma la temporizzazione non mi deve impedire di ricevere i nuovi eventi e non deve cancellare quelli vecchi.
Allo stesso tempo non so a priori quanti eventi possono avvenire tra un evento e la sua azione, possono avvenirne tanti o nessuno, quindi il ciclo dovrebbe comunque andare in polling.
Tral'altro la coda arresta il ciclo se è vuota, quindi il polling si arresterebbe.

[paracarro]

Questa è la mia soluzione.

Come ti ho scritto sopra, non ho usato code, ma solo un VI rientrante che viene istanziato al momento del trigger.

Per evitare casini, il subVI "LogMe" è semaforato (non è rientrante).

bye

[gepponline]

Soluzione interessante, la valuto sicuramente
Non mi è chiaro perchè esegui il RunMe e il log prima del ciclo pero'..

[paracarro]

Soluzione interessante, la valuto sicuramente
Non mi è chiaro perchè esegui il RunMe e il log prima del ciclo pero'..

Eseguo il "Runme.vi" solo per comodità.

Come avrai notato, se il parametro "Number" vale 0, allora Runme.vi non esegue nulla ed esce subito.
Quindi la chiamata fuori dal loop non fa ...niente.
In compenso permette di avere il "Runme.vi" caricato in memoria unitamente a "MyMain.vi" in quanto subVI referenziato direttamente dallo stesso.

Ciò consente:
1) di passare alla funzione "Open VI reference", il nome del SubVI "RunMe.vi" come stringa e non come path (perchè si trova già in memoria)
2) nel caso dovessi creare l'eseguibile, non avresti la necessità di includere esplicitamente il VI "runme.vi" in quanto caricato dinamicamente.

il log viene chiamato per inizializzazione.

Quando al VI di log viene passato il reference dellindicatore stringa in cui loggare i messaggi, il reference dell'indicatore viene memorizzato all'interno di LogMe.vi, di modo che non sia più necessario passarlo nuovamente. oltre alla memorizzazione del reference, la stringa viene azzerata.


bye

[gepponline]

Perfetto, sospettavo fosse un caricamento in funzione di un eseguibile o robe simili, ma volevo essere certo di non aver perso qualche passaggio per strada.
La parte del log invece, doovendo poi escludere tutta la parte di messaggistica direi che mi resta superflua visto che devo solo eseguire un azione.
E adesso aggiungero' quindi un altro step ai miei dubbi con un altro post, visto che l'azione che devo eseguire, la devo eseguire da due eseguibili separati ma che utilizzano la stessa risorsa HW.

[paracarro]

Dipende da quanto deve essere il ritardo a partire dall'evento di trigger, ma,
- se il ritardo è nell'ordine dei secondi
- se fosse necessario abortire l'esecuzione del codice associato all' evento,

allora consiglio di usare un Notifier per gestire l'attesa.
se dal VI di attesa di notifica si esce per Timeout, allora tutto OK, altrimenti vuol dire che un evento di ABORT è stato attivato.

bye