Running script weekly at specific time

I need to run a script at at 2:30 every Friday if certain tags are active, im finding it difficult to work out how to specify the day of the week i want this to run as well as the time, i know that i should run this off a timer script, and i have the contents of the script all worked out its just the date/time im having issues getting over i know it would look something like this,

[code]get current time/date
if current date = friday
&&
time = 14:30:

Script
[/code]

I feel like this should be really easy but i cant get my head around it, any help would be appreciated.

[code]from java.util import Calendar

currentTime = Calendar.getInstance()

print currentTime.get(Calendar.DAY_OF_WEEK) # 1=Sunday to 7=Saturday
print currentTime.get(Calendar.HOUR)
print currentTime.get(Calendar.MINUTE)[/code]

The script would look something like:from java.util import Calendar, Date cal = Calendar.getInstance() cal.time = Date() if cal.get(Calendar.DAY_OF_WEEK)==Calendar.FRIDAY and cal.get(Calendar.HOUR)==14: if cal.get(Calendar.MINUTE)==30: # your code hereThis assumes you configured the timer script to execute every 60000 milliseconds, using a fixed rate (not fixed delay).
This solution has a slight chance of either double executing or missing an event due to latency between triggering an event and actually starting execution. To address that, create a memory tag of type Date in which you write the last actual execution timestamp and check it like this:from java.util import Calendar, Date cal = Calendar.getInstance() cal.time = Date() if cal.get(Calendar.DAY_OF_WEEK)==Calendar.FRIDAY and cal.get(Calendar.HOUR)==14: if cal.get(Calendar.MINUTE)>=30: previous = system.tag.read("MyWeeklyEventTimestamp").value if cal.time.time - previous.time > 86400000: system.tag.write("MyWeeklyEventTimestamp", cal.time) # your code hereWith the latter code, you can play with the execution rate to improve precision or reduce CPU load.
If you need both high precision and low CPU load, you could use a gateway startup script with java.util.Timer or java.util.concurrent.ScheduledThreadPoolExecutor to precisely schedule a first event and the execution pace. If you do this, make sure you choose daemon mode for the timer’s thread.

PTurmel - Calendar.getInstance() returns the current date and time, so isn’t cal.time = Date() redundant?

It’s not documented to do that, so Oracle could change that and claim compatibility. Just looked… it is specified for GregorianCalendar(), so that could be used instead of the generic getInstance().

I see that method summary doesn’t say that it returns the current date/time. Under the class information it says - “Like other locale-sensitive classes, Calendar provides a class method, getInstance, for getting a generally useful object of this type. Calendar’s getInstance method returns a Calendar object whose calendar fields have been initialized with the current date and time:” That’s why I was scratching my head :slight_smile:

Option B: Use an expression tag.

Expression:

dateFormat(now(),"E H:mm")="Fri 14:30"

Then put the script in the tag’s Value Changed area:

A little late to the party, but this seems like a bit of a hack imo. Literally every other SCADA package I’ve used offers the ability to schedule an event to occur at xx:xx PM on Day(s).

Surely there’s something available within Ignition to do this? The crontab format used by reports and the gateway backups schedule would be perfect.

2 Likes

Agreed! I hope the come up with a scheduled gateway event script.

Well there is a completely unsupported way if you have the reporting module.
Create a blank report, schedule it, and set it to run a script.
Put whatever you want in the script. :slight_smile:

11 Likes

Clever. You win this topic, supported or no. (-:

4 Likes

It is full CRON scheduling too.
Works awesome, we use this to generate PDF reports and send them all in one email instead of separate emails. We generate other reports to a folder in the gateway, then use system send email to send them all together. Works very well.

1 Like

Interesting! This is definitely something to be clearly highlighted in any technical design manual for the system, else no-one will ever find this! But a great work around, cheers :slight_smile:

I don’t know why I didn’t think of that. Thanks for the tip.