Thanks for the response I guess I should have said that the database (MSSQL Express) is installed on the same machine that the Ignition Software/Gateway are all installed on. I’m in development mode right now so I have everything running on my PC.
I had a similar problem in the past that I’m not sure got resolved, but it was related to the EasyChart and it having an offset between discretes versus analogs, and it was most certainly timezone related (discretes and analogs were off by 5). What was weird was it showed perfectly fine on the local gateway, but the data was being split between the two systems, and only on the remote gateway did the issue show up. We never did figure that out, but I will tell you that looking at the epoch time stored in the DB was identical between the two systems.
Anyway, it is possible that the database is storing and presenting data from the database with an incorrect adjustment from the timezone. The database is capable of correcting on its own, but Ignition is dependent on the system time. If you don’t need this (DB on the same machine), then you might want to check the timezone setting on MySQL. You might need to run this command or adjust a parameter on MySQL so it will also use the system time and let Windows adjust everything for you:
SELECT @@global.time_zone, @@session.time_zone;
The above code will return what MySQL is the setting.
SET GLOBAL time_zone=‘system’;
This code will set it to use your system time. Even if the settings are correct for the timezone, running a Now() sql command can return the offset incorrectly. Something to check at least.
Thanks for the input, unfortunately I’m using microsoft sql server express (I put ‘MSSQL’ in my post for some reason). And my understanding is that SQL server uses the OS as well. But after reading your post I did a quick check of the database to see what time it thinks it is. Well it’s 2:29pm (14:29) and the database seems to agree. I ran this SQL command and the results are below. I’m in eastern standard time, which is UTC -5 hours but DST makes it UTC-4 hours now.
SELECT SYSDATETIME() AS [SYSDATETIME()]
,SYSDATETIMEOFFSET() AS [SYSDATETIMEOFFSET()]
,SYSUTCDATETIME() AS [SYSUTCDATETIME()]
,CURRENT_TIMESTAMP AS [CURRENT_TIMESTAMP]
,GETDATE() AS [GETDATE()]
,GETUTCDATE() AS [GETUTCDATE()];
SYSDATETIMEOFFSET()==2019-07-15 14:29:56.5390741 -04:00
Herbie seems to know more about it than I do, yet there is a Knowledgebase article by Anna Christian entitled “ClockDriftDetector warnings in the Gateway Console” posted 07/21/2016 08:11 A.M.
While the error involved of an hour is much greater than a second or two, there seems to be some important information in there about time synchronization. Most of what is said there pertains to system resources and Java Garbage collection. Again, if the issue is critical, you may want to read the support policies at https://support.inductiveautomation.com and ask them about it. Your e-mail response would be free unless you need ‘priority e-mail’. Not so with voice support- that depends on your account, if any.
Just an FYI- My PC here in Central DST seems to be set to UTC less *** SIX hours ***. How many time zones between Eastern and Central? My current time is 14:42.
I just took a look at the support page you referenced and as far as I can tell my PC knows what time it is. EST is an hour ahead of centeral so it’s 16:27 now (about 45min after your post).
Even the gateway seems to know what time it is
However, the XY charts still show the current time for the data as 15:25 instead of 16:25.
Then it looks like you may have found a BUG that pertains to either the newer versions of Ignition or the ability of your Windows10 environment to time-sync to the Ignition changes that are used to trigger the charting function. It has been a few months, yet I think that I remember someone else with a forum post about having difficulties with the XY Charts ( yet for a different reason- wanted to use reverse order on one axis ). It may be possible that the variables inside just the X-Y were expanded in order to allow the specific case mentioned… but that is not likely. If you looked at PC resources (previous) then you should get a good response. It should not be necessary to have IEEE1588 timing to get the accuracy of one hour. I would e-mail support, yet expect a delay unless it is a priority e-mail. My time here is 16:03 CDT. I suspect that IA will want the module versions…and maybe the Win10 long version.
Re: Other Issues reported on Forum Section:
XY Chart issue with Zoom does not have a resolution, yet does not seem to apply.
Your response to other user of X-Y charts in May. (Paully with the fancy blue mobius-strip bowtie logo ).
No other obvious forum posts, so the cited Knowledge Base check re: previous post about time sync and PC resources ( eg. Hard-Drive access or other timer loss activities ) is the only other IA source of information about timing issues or X-Y charts that is easily found. The Knowledge base can be accessed from the support page, then searched.
I just took a look. The project timezone is set to ‘Gateway Timezone’
I’m guessing that would be the recommended setting?
I believe that should mean the clients show time as if they’re in the gateway timezone regardless of what timezone the client is in. Whether this is desired or not varies with the project. That said, it seems unlikely this is responsible for the issue you’re seeing with that setting. You could try another setting and see if it makes any difference.
Thanks, I don’t think I’ll have an opportunity to test until Monday but I’ll give it a try. In my case, clients and gateway will be in the same building so I think the ‘gateway timezone’ setting makes sense. But I’ll still play around with those settings.
Good luck. FWIW, I haven’t seen this issue in Perspective XY charts. We’re using Gateway Timezone setting as we prefer clients in other timezones see the same time values as locals they may be discussing the chart with (the charts are very locale specific; the timezone viewer is in isn’t relevant). When I pull it up on my phone in a different timezone than the server, the time on the x-axis shows server time as expected. If we were using multiple gateways in different timezones running the same project, we’d set it to the actual timezone desired so all clients show the same time on charts regardless of gateway.
This other forum poster had an answer that may help:
This should only be an aid to understanding what is happening, from there it is up to you.
Thanks for the input but I’m still not having any luck. I guess I’ll reach out to Tech support. As far as I can tell the historian tags are being saved into the database with the correct UTC time and my gateway displays the correct time. It’s just the XY chart is shifted an hour. I changed the the project timezone and it didn’t change the time on the chart at all. There is no difference on the chart whether I set timezone to New York or LA.
I wonder if it has something to do with the way I’m populating (binding) the data. I use the system.tag.queryTagHistory() function in a script to generate a dataset.
I just created a new project with two XY graphs one graph pulling data using
and one graph just binding data to the tag historian and guess what… The time with regular binding is correct. The queryTagHistory() function is my problem it doesn’t adjust for daylight savings time.
FYI, the reason I’m using the query function to get the data is because my horizontal ‘limit’ lines disappear if I just bind the data. I have the limit lines associated with a second X axis because I’m using a single value memory tags to plot a horizontal line, I don’t store the line data over time.
You can still have your control lines, it just takes a bit of code.
First create a custom property on the chart called LSL of dataset type.
Then create another custom property called Meas which contains your historical tag query.
Then in the property change event of the chart do code like this(Adjust for your tag names)
if event.propertyName=='Meas': lcl = system.tag.read("PathToYourTag/LCL").value lwl = system.tag.read("PathToYourTag/LWL").value ucl = system.tag.read("PathToYourTag/1SigDev").value uwl = system.tag.read("PathToYourTag/2SigDev").value tmpDS =  l = system.dataset.toPyDataSet(event.source.Meas) hdr = ['t_stamp','1LCL','1LWL','1UCL','1UWL'] for i in range(0,len(l)): tmpDS.append([l[i],lcl,lwl,ucl,uwl]) event.source.LSL=system.dataset.toDataSet(hdr,tmpDS) chart = event.source axes = chart.getYAxes() axis = axes.get('Default Y Axis') axis.setLowerBound(lwl - (lwl * .05)) axis.setUpperBound(uwl + (uwl * .05)) chart.setYAxes(axes) chart.createChart() l=None
It will look funky in designer when not in Run mode, but fills in when it preview and runtime.
One question, you siad
Are you referring to the “Add Change Script…”? I’ve never had the need to put a script on a property change (well at least I didn’t think I did).
I’ll give this a go tomorrow
Well maybe, I just saw this… (I’m ready to ditch the xy chart)
Ahh damn, sorry. I don’t use Perspective yet.
The above works in Vision, I’m sure someone can chime in on where to put that in Perspective.
Individual change scripts are the closest analogue to Vision’s component level property change events, but yeah, the script would be totally different in Perspective.