Question about Event Timeouts, does time reset on an event?

[cayenne]

I've a quick question about how the timeout works with an Event Structure within a While loop.

Let's say the Event Timeout is 20ms.  If an event (say a button click on the front panel) happens, and the code for that event fires and completes...what happens to the timer on the Event....does it get reset to 20ms...or is it running continuously in the background....and the timeout codes gets fired still every 20ms regardless of the event happening in the middle...?

I'm wondering what happens to the code within the Timeout event....when would it be fired off.....?

Thanks in advance,

cayenne

[MoReese]

The timeout will be reset if an event occurs.  If and event does not occur the timeout event will be executed.  The timeout event will not interuppt another event.

[cayenne]

---

@MoReese wrote:

The timeout will be reset if an event occurs.  If and event does not occur the timeout event will be executed.  The timeout event will not interuppt another event.

---

I was afraid of that.

Ok...well, if one needs one's code to run and fire off every 20ms (or whatever time), say to be communicating over a serial connection (say to send and read from port)...how does one do that when they have events also being monitored for clicks and all on and front panel?

I had planned to put my serial communication in the timeout area...with the 20ms time out...thinking that would work.

Are there any good examples out there how to do a general set up of this sort....?  Links? Suggestions?

Thank you in advance,

cayenne

[GregFreeman]

Create a parallel loop that is dedicated to the serial communication. Use a queue to communicate between the loops. Google "producer consumer LabVIEW" or search for it here on the forums. I would post a link but am on my phone

[P@Anand]

I'll do that. Here you go with the Producer consumer design pattern and other design patterns

Good luck

[altenbach]

One way around it would be to correctly shorten the remaining timeout whenever a non-timeout event occurs. Here's an example (from the end of this thread).

(see also my comment to a related idea)

[GregFreeman]

---

@altenbach wrote:

One way around it would be to correctly shorten the remaining timeout whenever a non-timeout event occurs. Here's an example (from the end of this thread).

(see also my comment to a related idea)

---

But, since the OP only has one loop, if he is doing any complex processing in the event loop, there is the possiblity some event will take longer than 20 ms to execute. So, in that case he may want a dedicated loop for serial communication. I'd suggest benchmarking to see what works best for your application.

[cayenne]

---

@P Anand wrote:

I'll do that. Here you go with the Producer consumer design pattern and other design patterns

Good luck

---

Thank you...I've been reading on the producer/consumer, and trying to figure out the queing thing.

A quick question.....which would will be the producer and the consumer in my case?

My code starts like this:

1. I gather info on the status of the clusters for right and left on my front panel.

2. I construct a byte messages that goes out the serial port.

3. The unit responds on the serial port (right now, this is just doing a loopback, not hooked to the final unit)

4. The code reads the serial message, updates the clusters

5. Goto Step 1.

Basically except for the first run that sends first....my code reads from serial->updates cluster->reads from cluster-> sends to serial

I'm guessing one loop would be read and write to serial....the other loop would be my events driven code.  Which one is the producer and consumer in this case?

Also, where I currently have all this code (the reading/writing is in the events timeout, which I'm changing from)....when the code reads in, it actually calls buttons and rings to cause events to trip on the front end which updates the clusters.

So, I'm fuzzy how I'll ensure I get my messges in, update the cluster, use that updated cluster to construct the outgoing message...and send out...in that order....with the producer/consumer paradigm.

Suggestions, comments or insights?

Thank you in advance...

cayenne

[MoReese]

---

@cayenne wrote:

---

---

 

My code starts like this:

1. I gather info on the status of the clusters for right and left on my front panel.

2. I construct a byte messages that goes out the serial port.

3. The unit responds on the serial port (right now, this is just doing a loopback, not hooked to the final unit)

4. The code reads the serial message, updates the clusters

5. Goto Step 1.

Basically except for the first run that sends first....my code reads from serial->updates cluster->reads from cluster-> sends to serial

I'm guessing one loop would be read and write to serial....the other loop would be my events driven code.  Which one is the producer and consumer in this case?

Also, where I currently have all this code (the reading/writing is in the events timeout, which I'm changing from)....when the code reads in, it actually calls buttons and rings to cause events to trip on the front end which updates the clusters.

So, I'm fuzzy how I'll ensure I get my messges in, update the cluster, use that updated cluster to construct the outgoing message...and send out...in that order....with the producer/consumer paradigm.

Suggestions, comments or insights?

Thank you in advance...

cayenne

---

It sounds like receiving your data is the trigger for the updates.  This would be in your Producer loop.  Use the producer loop to gather information or to trigger.  Sending/receiving serial data is fine.  But once data is received from the device, send the request to the consumer loop to perform the assigned task (udpate your clusters).  If your front panel is not used that often, you can use the data type P/C loop.  You don't need events.

[Norbert_B]

---

@cayenne wrote:
[..]
I was afraid of that.

[..]

---

Maybe it should be renamed to something like "Watch Dog Bark" instead of "Timeout". Would address such questions, but on the other hand... create new 😞

Norbert