Generate User Events

[Silver_Shaper]

Hello All,

I need to take a report from my application on every friday (At Specific Time). Can any one suggest me the method to do this?

Is it possible to do anything with generate user event registered with event structure (if so please guide me the direction).

[jyang72211]

I thought of three ways.

1. Put your code in the timeout case of the event structure.  Put 1 week as the timeout and start your code on friday.  I am not sure how precise the timing is, but it should work.

2. Same as one, but your timeout will be 5 minute.  Every 5 minutue, you will poll for the time.  If the time is friday, execute your code.  

3. Use window's schedule task and schedule your task to run every friday.  

[Mark_Yedinak]

---

@jyang72211 wrote:

I thought of three ways.

1. Put your code in the timeout case of the event structure.  Put 1 week as the timeout and start your code on friday.  I am not sure how precise the timing is, but it should work.

 

---

You can do this but rather than set the timeout to a constant simply calculate the amount of time you need. That way you can start the application at any time and it will timeout at the correct point in time.

[SteveChandler]

As jyang says above you can check the current time in the event structure timeout case and compare it to your target time.

In the true case above you could put a subVI, generate a user event, enqueue to another loop, etc.

[Mark_Yedinak]

---

@Steve Chandler wrote:

As jyang says above you can check the current time in the event structure timeout case and compare it to your target time.

In the true case above you could put a subVI, generate a user event, enqueue to another loop, etc.

---

The above apporach can be used and can be extended to actually handle multiple timeout events. The only comment I have is that if the user is only looking for an event every Friday set your timeout accordingly. A timeout every 50 ms is WAY TOO many timeouts when looking for an event that occurs once a week.

[JÞB]

Hold on fellows!  What if we want to expand the event structure to handle multiple events-  The timeout may never fire!  Probably a better solution is to convert the timestamp to a date-time record.  Day of week, hour, and week of year are the elements that will alow you to determine when its friday and weather you've written a report this friday.

[nathand]

You could add a separate loop that fires a user event when you reach the right time.  This could be done with very little overhead, because you don't need to poll the current time continuously.  Instead, when the loop first starts, check the current time, calculate how long it will be until you need to fire the event, and use that value as the input to Wait (ms).  Since that value is in milliseconds, you might need to check that the value doesn't exceed the upper limit of a U32, and if so, wait that maximum value instead, then recalculate.  The downside to this approach is that Wait (ms) can't be interrupted.  You could instead wire the value as the timeout for a queue or notifier (note, then it's an I32, not U32) which would give you a way to abort if you need to exit the program.

[Mark_Yedinak]

---

@nathand wrote:

You could add a separate loop that fires a user event when you reach the right time.  This could be done with very little overhead, because you don't need to poll the current time continuously.  Instead, when the loop first starts, check the current time, calculate how long it will be until you need to fire the event, and use that value as the input to Wait (ms).  Since that value is in milliseconds, you might need to check that the value doesn't exceed the upper limit of a U32, and if so, wait that maximum value instead, then recalculate.  The downside to this approach is that Wait (ms) can't be interrupted.  You could instead wire the value as the timeout for a queue or notifier (note, then it's an I32, not U32) which would give you a way to abort if you need to exit the program.

---

The timeout cannot be interrupted but it can be stopped by wiring a 0 to the timeout value. This assumes you do have some other event that occurs. I have actually used this approach for background tasks that buffer up log messages. I use the timeout to specify the maximum time to wait between dumping the events to file. When I get a new event I modify the timeout value. If I surpass the maximum number of events I will buffer I trigger the event to dump the events and set the timeout to 0. No timeout event will fire. The timeout will reset every time a new value is written to it.

As for processing multipl events the timeout event can have a list of timeouts and the corresponding action. If you use the timeout more like a polling event it can check if any timeouts have occured and than trigger the corresponding user event (or post to a queue or notifier) associated with that event.

[SteveChandler]

---

@Mark Yedinak wrote:

---

 The only comment I have is that if the user is only looking for an event every Friday set your timeout accordingly. A timeout every 50 ms is WAY TOO many timeouts when looking for an event that occurs once a week.

---

Yes indeed, unless you want to know it's Friday right away which I usually do

Better to come up with some algorithm that adjusts the timeout as Friday aproaches until it is eventually set to 0. But even firing an event every 50mS all week long will not hurt anything. Overkill yes but the CPU load will not be noticable and memory leaks will not happen. It should be fine (I think)

[SteveChandler]

---

@nathand wrote:

You could add a separate loop that fires a user event when you reach the right time.  This could be done with very little overhead, because you don't need to poll the current time continuously.  Instead, when the loop first starts, check the current time, calculate how long it will be until you need to fire the event, and use that value as the input to Wait (ms).  Since that value is in milliseconds, you might need to check that the value doesn't exceed the upper limit of a U32, and if so, wait that maximum value instead, then recalculate.  The downside to this approach is that Wait (ms) can't be interrupted.  You could instead wire the value as the timeout for a queue or notifier (note, then it's an I32, not U32) which would give you a way to abort if you need to exit the program.

---

My rule of thumb is that if I am waiting less than about second I will use Wait (mS). Anything more and I compare the current time with a previous timestamp and determine myself if the long wait has elapsed for the reasons you give. No need to worry about rollovers or blocking.