How do I take a time stamp and get a new time stamp that is a specific time tomorrow?

[aputman]

---

@Rhidium wrote:

Wouldn't it be more simpler to just have a timestamp set up for the time you want to have the alarm to go off.. and upon alarm, the same timestamp is just changed to the next period alarm setting?

For example have the time stamp be compared to the alarm time.. When timestamp is greater than the alarm time (compare it in seconds), it will set off the alarm (within the case statement).  Note in that within the case statement, it would increment the alarm timestamp to the new time that you want to alarm at (whether you do it in seconds, etc).

Maybe I'm missing what this person wants to do.. seems a bit vague on the details on what the true outcome they want..

If it's for calibration control of your instrumentation, you might want to do more complex stuff such as snooze the alarm, or repeat the alarm in case the person doesn't do the calibration immediately.

---

Rhidium, I'm not sure if you saw the OP's attached code but basically, everything you suggested is what is already being done.  The problem, as I stated above, is that the alarm time, which is currently being stored in the shift register, is being overwritten in the false case with the current timestamp value.  If the OP will wire the shift register value thru the false case, everything should work as intended.   I would also take the advice of others to add 86400 to the timestamp to avoid any problems associated with converting a date/time record to a timestamp.  

[Mancho00]

The problem is inherent in the date/time record.  There are elements for 'day of month', 'day of week', and 'day of year'.  If you change one, but not the others, what is the expected outcome?  The language in the help for Date/Time to Seconds function only confuses the issue.  e.g.

"day of year can be from 1 to 366. If is UTC is TRUE, the function ignores day of year. 

Note  This function ignores day of year when building the timestamp."

If UTC is true, it ignores it, otherwise it ignores it?

[paul_cardinale]

Try this.  It adds 24 hrs then sets a specific time.

[Viper]

---

@Mancho00 wrote:

Add 86400 to the time (before the Seconds to Date/Time function)

Edit: Also, why are you changing the Boolean to integer and adding?  Just use an OR function.

---

I don't want the alarm set for 24 hrs later. I want it at a determined time like 5:00 AM. If I ran it at 9:30 then the next alarm would be at 9:30 the next day. Not what I want.

In the beginning I thought I needed three states not just two t/f. 1st time through, due, not due. Turns out just two cases are necessary since the uninitiated time is T=0 (... 1903)

[Viper]

---

@aputman wrote:

Be more specific about what doesn't work.  What you have there, adding 1 to the month should work.  There may be some edge cases that can cause problems converting the date/time record back to a timestamp (i.e. leap year).

I would replace the single iteration for loop with a while loop and wire a constant boolean to the stop terminal so that it only executes once. 

---

What is the difference between the for loop or a while loop in this case? Is there an advantage?

[Viper]

---

@Rhidium wrote:

Wouldn't it be more simpler to just have a timestamp set up for the time you want to have the alarm to go off.. and upon alarm, the same timestamp is just changed to the next period alarm setting?

For example have the time stamp be compared to the alarm time.. When timestamp is greater than the alarm time (compare it in seconds), it will set off the alarm (within the case statement).  Note in that within the case statement, it would increment the alarm timestamp to the new time that you want to alarm at (whether you do it in seconds, etc).

Maybe I'm missing what this person wants to do.. seems a bit vague on the details on what the true outcome they want..

If it's for calibration control of your instrumentation, you might want to do more complex stuff such as snooze the alarm, or repeat the alarm in case the person doesn't do the calibration immediately.

---

This is a watchdog. I want the tech to perform an operation 1st thing in the morning every day. This vi will go in a while loop that runs every 60 sec to check if the operation is due. So the 1st time through it will prompt the user and set a new alarm. Because the dialog box is modal the tech can't miss it. This limited use PC shouldn't have any other windows that obscure the message.

[Viper]

I'm running LV2013 that's why I used a snippit. It's more version agnostic than a specific versions code. I can't run your code.

---

@paul_cardinale wrote:

Try this.  It adds 24 hrs then sets a specific time.

---

[Viper]

Rhidium, I'm not sure if you saw the OP's attached code but basically, everything you suggested is what is already being done.  The problem, as I stated above, is that the alarm time, which is currently being stored in the shift register, is being overwritten in the false case with the current timestamp value.  If the OP will wire the shift register value thru the false case, everything should work as intended. 

---

I have a "working version" now. However I do believe there are corner cases that will give unexpected results. If you have further suggestions I'm game.

Just to summarize. I have an operation that must be performed by the tech 1st thing every day before running my test program. The program can run over multiple days so I want the alert every day. When they do it for that day they need not do it again until the 1st time the next day. This VI is included in a while loop that runs every 60 sec. This loop is a tickler that makes sure one of my wayward instruments doesn't fall asleep. Choosing 5:00 am was arbitrary yet before shift begins. If they started my program at 9:30 am adding 86,400 would set the alarm for 9:30 the next day. If they then continued the next day at 7:00 am (shift start) then the alert would be very late and errors could occur because they missed this wanted daily operation.

If there is a more rugged way to do this please post it as a snippit.

This NI forum is the best. You users rock.

[aputman]

---

@Viper wrote: What is the difference between the for loop or a while loop in this case? Is there an advantage?

---

I use a while loop with the stop terminal set to Continue if True and wire a false constant to it.  Some use Stop if True with a true constant.  Mostly just a matter of preference.  I don't know if there are any (dis)advantages to using a while loop over a for loop.  The while loop seems to be the conventional method for loops that only execute once.  Action engines are a good example that use this method.

Edit: On a technicality, a while loop must execute at least one time.  If you wire a 0 or a negative number to the for loop N terminal, it won't execute at all.  

[RavensFan]

---

@Viper wrote: Choosing 5:00 am was arbitrary yet before shift begins. If they started my program at 9:30 am adding 86,400 would set the alarm for 9:30 the next day. If they then continued the next day at 7:00 am (shift start) then the alert would be very late and errors could occur because they missed this wanted daily operation.

No. You didn't follow along completely with what Rolf was saying in message 10. You add 86400 seconds to get a timestamp set for tomorrow.  The same time as now, but exactly 1 day in the future.  But then you use the cluster to set the hour, minutes and seconds to be the time you want.  Effectively it does the same thing you are doing by adding 1 day to the day of the month.  But doing math on the cluster elements doesn't always correlate to a real date.   So if it is Jan. 31 and you add 1 to the day of the month, you have Jan. 32 which doesn't exist.  If all works well LabVIEW will turn that into Feb. 1.  But there are some cluster elements that don't reliably recalculate the date when you roll over.  I know because of played with this before and sometimes it works and sometimes it doesn't.

But if you add 86,400 to the timestamp, it correctly calculates the timestamp for tomorrow, then you can change the cluster elements to give the correct time for tomorrow.  That is the more robust solution.