Scheduled Transaction Groups Record Two Values

Hey guys,

Last Saturday, for some reason, a scheduled transaction group started logging to the database twice. It’s been working fine for a few months now and nothing has changed recently with it. Here is the schedule settings:

and the data in the database:

I’m not sure what to look for here since it was working fine with no issues for a while now. Any thoughts?

You didn’t happen to make a copy of that project on Friday did you? Any other gateways (like a development gateway) running that project and writing to the same database?

No… but I do have a redundant server setup though… However, it is connected to the primary server so it shouldn’t be writing to the database at all.

Can you stop the service on the slave tonight and see if it still logs twice?

I got this after I left work so I couldn’t stop it last night. I will stop it today and report back tomorrow.

FYI, I have a bunch of other transaction groups that are trigger based, not schedule based, and they are NOT being written to the database twice. Seems to be only an issue with the schedule based transaction groups. I will let you know what I find out about the backup server possibly being the issue. Thanks!

OK, let us know how it goes tonight. Also, what version of Ignition are you using?

Will do.

Ignition version: 7.5.1 (b1122)

Someone marked my previous thread solved when it wasn’t and now I can’t add to it, so I’m starting this one. The previous thread is here.

I turned off the backup gateway but all of my scheduled transaction groups are still logging to the gateway twice, so it does not seem to be a redundant server issue. There is only one copy of this project running and now I have only one Ignition server running (I’m going to start the backup server up again now that I know this isn’t the issue.)

Something must have changed on the 18th for this to start happening. Try adding another column to your transaction group that logs a string with the name of the project? If you have a second project or gateway logging this info, then one of the duplicates will be blank each time.

I did what you suggested and it logs the same thing to the database. The other weird thing is that on Monday night it worked fine, no double logs, but last night it did a double log again.

Another thing I thought of is that the server was moved to the cloud on the 11th, but it was fine for an entire week and then started double logging on the 18th. Not sure if that has something to do with it? :scratch:


Looking closely at those times, and at how the scheduling works, I’m going to guess that it’s an issue on our side with rounding in the timing/executing system. Basically, it works by finding the next time that it should run, subtracting the current time, and telling the system to wait that long. As soon as the group runs, it is asked to calculate the next execution time.

Looking at your timestamps, we see some rows coming in at 23:56:59, not 57:00. IF it ran then, and then immediately calculated the time, it would say, “hey, run again in 1 second- at 57:00”, which is in line with what we see.

I’ll have to look closely at how to handle this. If nothing else, this scheduling system only offers resolution to the minute, so if you’re specifying an exact time, there really shouldn’t be a way for it to run more than once a minute.

As a work around, I think you can do the following: Specify a range (“23:57-23:58”), and then set the rate for something larger than the range, like 5 minutes. When you specify a range, you can then specify a rate, and this works by adding the rate on to the last execution, until it’s outside the range. Then, it looks to the start of the next range (which can be the next day). In this case, your rate is large, so it will always forward over to 23:57 the next day. If it happens to run at 22:59, no problem, because 5 minutes will still be outside of the range.

Hope this helps,

Err, I might be wrong about my work-around. It only adds the rate when the time falls inside the range, so if my guess at what’s happening is true, it’s still going to execute twice - once early, and once at the right time. We’ll have to try to get some sort of fix or extra check in for the next update.


Ok, we’ve tweaked the scheduling a bit in 7.5.3 beta 3, so that a group can only run once per minute, unless using a range with a slower rate. In other words, if it happens to run a bit early, it won’t run again immediately, but will instead calculate the next time after that.

That beta should be up tomorrow, I think.


Cool, I’ll check it out. Thanks, Colby!

Ran a little behind with the beta, but it is now up on the website.

FYI, after upgrading to 7.5.3 this does not seem to be an issue anymore. I haven’t seen it record a double value since upgrading. I think this issue is resolved. Thanks for the help!