In LabVIEW esistono due funzioni di temporizzazione comunemente utilizzate per inserire ritardi nell’esecuzione di un VI:
- Wait (ms)
- Wait Until Next ms Multiple
Anche se entrambe servono a “pausare” il flusso di esecuzione, il loro comportamento e gli scenari d’uso ideali sono differenti.
Comprendere queste differenze è fondamentale per progettare applicazioni robuste, soprattutto in contesti dove è importante mantenere un loop rate costante o garantire tempi di attesa precisi.
Wait

La funzione Wait(ms) semplicemente attende fino a che il tempo specificato non trascorre.
Attenzione al DataFlow ovvero a come LabVIEW esegue il codice:
Il dataflow comporta un funzionzionamento diverso, provate a indovinarne il tempo ciclo, senza leggere le descrizioni.

Esecuzione Parallela, il vi e il wait partono insieme, quindi il VI termina a 10ms, ma la wait è arrivata a 90ms di conseguenza, il tempo complessivo è 100ms per ogni iterazione, sembrerebbe quindi che il wait stia assolvendo una funzione di timeloop determinando la cadenza, ma è solo perchè il wait ha un tempo maggiore rispetto alla durata del vi.
Per questo motivo usato così non si osserva molta differenza tra wait e wait until in applicazioni windows, mentre diventa cruciale in applicazioni deterministiche come RT e FPGA che hanno ovviamente funzioni sul tempo con risoluzioni più alte (us o tick 4ns (dipende da clock).

In questo la funzione wait per il dataflow deve aspettare il terminale di errore sia libero, per cui attende l’esecuzione del VI. La durata dell’iterazione quindi diventa 110ms.
Questa è l’uso corretto del wait, per esempio nelle comunicazioni con dispositivi, si introduce una piccola pusa tra un comando e una lettura della risposta, lasciando il tempo di generare il buffer di trasmissione al device.
Wait until next ms multiple

La funzione “Wait Until Next ms Multiple”, invece attende un multiplo del clock di sistema, espresso in millisecondi, non è divisibile per valore specificato nella funzione.

Come sopra il codice viene eseguito in contemporanea, quindi il Wait Until, misura un tempo pari a 100ms.

In questo caso, il loop esegue prima la funzione da 10ms, quindi la wait esegue la sottrazione tra il tempo impostato e il tempo del vi.
Come conseguenza, la wait until aspetta
Sapendo che non vi fidate, e fate bene, potete fare una prova, ecco una test unit per verificare il funzionamento del VI

Test
Proviamo con un esempio pratico. Mettiamo quindi in test il wait e la wait until.

Usiamo il TickCount, come cronometro.

La funzione tick count (ms) viene utilizzata in LabVIEW come un cronometro, essa restituisce il tempo di esecuzione in millisecondi(ms), perciò può essere molto utile anche per fare dei test di prestazione dei propri VI.
Ricordare che utilizzandolo per comparazione ed essendo 32Bit quindi la capacità di 2^32-1.
The base reference time (millisecond zero) is undefined. That is, you cannot convert millisecond timer value to a real-world time or date. Be careful when you use this function in comparisons because the value of the millisecond timer wraps from (2^32)–1 to 0.
Va bene per cronometri nell’ordine dei ms ma non usare per misurare tempi più lunghi dove si può usare la funzione “Get Date/Time in seconds“, che fornisce un timestamp in secondi.

Tornando a noi, cosa fa e come si comporta il VI?

In sequenza viene preso un Tcount0, la funzione Wait attende esattamente il tempo impostato in waitTime.
Proseguendo la funzione Wait Until aspetta il primo multiplo dei ms impostati al suo terminale.
Quindi se la waitTime del primo wait è impostata a 50ms e il terminale di WaitUntil è 200ms, la wait until dovrà attendere 150ms prima di trovare il suo prossimo multiplo.
Di conseguenza
wait 50ms (impostato a 50ms)
wait until 150ms (impostato a 200ms)
Tempo ciclo totale 200ms
Come e dove usarli?
- Inserire un ritardo fisso dopo una funzione, come una write per inviare un comando. In questo caso usare Wait in serie al codice.
- Fornire un loop rate fisso indipendente dal tempo operazione.Wait in parallelo
- Loop rate adattabile al tempo del codice. Wait Until in serie al codice.
Consigli
- Per mantenere reattivo il codice e soprattutto la UI, non mettere tempi di pausa alti. Esempio se devi creare una pausa di 10s o più, usa Time Elapsed con un wait ciclo di 200ms.
- Temporizzare sempre i loop in caso di polling, in windows inutile scendere sotto i 50ms se il loop aggiorna una Interfaccia Utente usare da 150:250ms relativamente alla percezione dell’ occhio umano.
Approfondimenti
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P82BSAS&l=it-IT
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YKYzCAO&l=it-IT
https://www.ni.com/it-it/shop/labview/timing-and-synchronization-in-ni-labview.html