Scheduler: On first run, date is not calculated correctly.

[vtiu]

I have created a scheduler to turn on a pump for a certain time, three times daily. The VI is working, at least over a weekend period. At present the pump is only pseudo turned on for testing. My problem is, the user enters just the three times but not the date. The date is checked and changed accordingly, if the time has passed, to the next day after the current day.

I realise that polling the current time continuously is maybe not the best way as the CPU will be busy but that is not a problem as the PC is dedicated to just this task.

When I run the VI for the first time, the remaining time till next "on" is a minus value. If I stop the VI and run again, it is correct. Can anyone see where I have made a mistake.

Many thanks.

Mark

[GerdW · Accepted solution]

Hi vtiu,

---

@vtiu wrote:

Can anyone see where I have made a mistake.

---

Your timestamp math is way too complicated!

See this:

I recommend to cleanup and simplify the other code too…

[vtiu]

Thank you for your input. That makes things a lot easier.

I also had to set a default value in the time 1 to 3 where the seconds were 0. I didn't notice that they were fixed at 57. Now the countdown time remaining fits better with the actual time.

The timestamp math in the while loop is also simplier. Why simple when you can be complicated 🤔

The finished version is attatched as a new VI. I have to remember why the changes were made.

Regards

Mark.

[GerdW]

Hi vtiu,

---

@vtiu wrote:

The timestamp math in the while loop is also simplier. Why simple when you can be complicated 🤔

---

More simplifications:

• Instead of the 86400 constant you could enable the unit display for the numeric constant and use the unit "d". Then the value of the constant should be "1"…
• Instead of using a timestamp control to inut the "pump time" you could use a numeric control, set to "relative time" formatting. No date needed, and you get the "seconds since midnight" for free…
• Instead of rounding and checking for zero you could simple check for "<0". (Much more safe when comparing floats…)

---

@vtiu wrote:

I have to remember why the changes were made.

---

This is where you place your comments when you commit your new code to your code repository!

You use a code revision tool, do you?

(Or when you place comments in the code.)

[altenbach]

In addition to what has been said, there is quite a bit of code smell here.

• There should not be any value properties anywhere
• Your lower loop is greedy, spinning millions of times when the trigger is false
• 
• If trigger is true, the lower loop gets trapped for minutes.
• Complicated instructions for the user (do not do that unless this and that, etc.) should not exist. The code need to give feedback if values are not reasonable.
• It is confusing that the times can be changed while the code is running, just to be ignored and overwritten by the code soon after.
• If something needs to run 3x/day, you don't need all these data structures.
• Why all that duplicate code?
• etc. etc.

All you really need is a proper state machine, one toplevel loop running at a reasonable rate and defined states and transitions based on time and state.