Hey guys,
I’m still having the double triggering problem on scheduled transactions, this is the same problem as this post. (I would have just unsolved it and continued but I don’t have the option to unsolve. FYI)
It was working fine for a while, but the last few days I’ve been getting double records about a minute apart. It looks like it’s firing early again:
I’m not doing anything fancy, here is the transaction group that goes with these records:
Why would it be triggering early and then again at the correct time?
That’s very strange. Does it happen regularly now? For example, in your screen shot, it actually shows that it’s not supposed to run until 23:59 tonight. I would be interested to know whether it runs early again tonight.
Is the machine set up with any type of clock synchronization? I’m just curious if perhaps the clock is being adjusted by an outside force, causing things to get thrown off by some amount of time now and then. It’s a wild guess, but stranger things have happened.
Regards,
Hey Colby,
Yes, it is happening almost every night now. It happened last night as well, here are the database records:
I talked with our IT department and they don’t think there should be a time change issue with this server. They said that since they are part of our domain the domain controllers should keep them constantly updated to the correct time, not just at any particular time of the day.
The only other thing I can think of that may be different from other setups is that my Ignition servers are off-site virtual servers, but I don’t think that should matter.
I am running the latest version of Ignition (7.5.4 (b1206)).
Are there any logs or anything that you would want me to collect that could be of help tracking down this issue? Let me know if there is anything particular that you’d like me to do. Thanks!
It’s a virtual machine, huh? One interesting thing about the way that scheduling works, is that it’s all based on delay. As in, when the group runs, the system then says, “how many milliseconds should I wait to run again”, not “what time should I run”. I know that virtual machines are more or less known to have strange clocks, and I wonder if over the course of 24 hours the delay mechanism just isn’t accurate. It thinks it’s been 24 hours, runs, and then sees that the next execution, from a time point of view, should be in a minute or two.
The first time this came up, we put in logic to prevent re-execution due to small variance, like a few seconds (or milliseconds, which could be common). For some reason, the time span has grown.
Out of curiosity, when was the Ignition gateway last started? You said it worked for a while, I’m just curious if perhaps there could be some cumulative effect. If the gateway was restarted somewhat recently, and this kept happening, that wouldn’t likely be the problem.
Regards,
The last time I restarted it was when I upgraded to the latest version, about 11 days ago:
It may be a cumulative effect, since it was fine for days after I started it up. However, last time I had this problem it was very intermittent. Some days it would do it and some days it wouldn’t.
You would think that it would always be the same number of milliseconds from 11:59 to 11:59 though, so shouldn’t it reset after it runs? I don’t quite understand what you mean about cumulative effect if it should always be the same number of milliseconds between executions.
Or perhaps the domain controller changing the clock constantly may be the issue if the Ignition server is running fast? Then you would be constantly “adding” milliseconds throughout the day, no?
I don’t know, all I know is it gets annoying having to manually delete and edit records every day 
I may have to go back to triggering on the controllers.
Yeah, I doubt it’s cumulative, since it should just go from after each event- just wanted to think about that, though.
You could try executing the way it used to be done, before this feature:
- Group set to run at 1 second.
- An expression item set to:
dateExtract(now(),“hour”)=23 && dateExtract(now(),“min”)=59
- Set the group to trigger on that, with “only execute once while trigger is active”.
Regards,
