I think that I have queried this before, but cannot seem to find
a record of it anywhere, maybe I read it somewhere instead.

My current application has data logging configured to log for a
perioid of 1 day. What is happening though, is that the data is
'rolled' over at midday, ( Midnight GMT ), so this then displays
the data over 2 days, midday to midday. This is workable, but not
the ideal solution.

Is there a workaround to this, short of creating different logging
periods?


I'm sure that I have read it somewhere...

I'm giving this a little 'bump' but I am sure that I read somewhere, that there is a setting that can
be modifed in a config file, I think I may have tried this before and did not work, but for the life
of me, I cannot find that information on where to make the change!!

I don't have CXS available right now and I doubt that it is that simple, but wasn't it possible to set the period to hours? I can imagine 24 hours should not rollover at midnight.

It didn't appear that simple back then when I read it somewhere, unless what I read
was for another package??





Valid suggestion pdl, will try this and see what happens.

If logging is configured for 24 hours, instead of 1 day, and to start on application
startup, I could configure a script to stop logging at midnight, and begin logging
again once logging has stopped. This will only happen once, as it will be dependant
on when CX-S is started, once the first roll-over happens, then the script is disabled,
until of course, IF CX-S has been re-started.

Thanks Pim, your suggestion triggered something obvious for me to implement.

I think the file 'rollovers' always happen based on UTC (Universal Time Code) so I'd guess your timezone is GMT+12 (or GMT-12 ). As a test, on the Data Log Export dialog try ticking UTC to output the logs without local timezone correction. I bet you find the file starts and stops at 0:00 !!

It used to be there was no way to change this - don't think thats changed in the latest version.

I suppose you might be able to 'mis-set' the Windows timezone, and just adjust the clock. Might just work as long as the PC doesn't resync with your server/internet (and of course has side effects for your other software too!). Hope this bounces some ideas around
Bertie

Hi Berti,
We are +12 here, ahead of the rest of the world...

I have looked at the UTC option previously, and it does rollover at 0:00 like you say, but this is 0:00 + 12, which is midday!!

Re mis-setting the windows time zone to suit, probably not an option, as this machine sits on a corporate network, so will resync with that.

I haven't had the chance to try the script idea yet, hopefully going to get a chance on monday.

has someone tried this idea with 24 hours instead of 1 day? my guess is it will work in a following way:
every log has to have 24 hours whenever it is started, but not 24 hours of logged data but 24 hours has to pass since the time when log is started. so if scada and data log are stared at 1400, script stops logging at midnight, then start logging again, it will resume this last log file since from its starting time (you can see it at file name dataset1_datetime.dlv) only 10 hours passed instead of 24.
so, if scada stops at 0100 and then start again in 1600 then the new dlv file will be started.

any who tested this?

Hiya

Not tested this but pretty sure a"24 hour" file will roll over at 0:00 UTC, not 24 hours from when it was started.

Anyone prove me wrong if you can

Regards,
Bertie

Not quite sure I understood you. can you explain a bit more?

[quote] has someone tried this idea with 24 hours instead of 1 day? my guess is it will work in a following way:
every log has to have 24 hours whenever it is started, but not 24 hours of logged data but 24 hours has to pass since the time when log is started. so if scada and data log are stared at 1400, script stops logging at midnight, then start logging again, it will resume this last log file since from its starting time (you can see it at file name dataset1_datetime.dlv) only 10 hours passed instead of 24.
so, if scada stops at 0100 and then start again in 1600 then the new dlv file will be started.[/quote]


I think you are correct tashinz, I have done the method as I proposed, but am pretty sure it did not work as I planned, the datalogs roll over 24hrs after they were started. I do not have access to that site just now to double check.

[quote name='tashinz' date='Jul 22 2008, 08:56 AM' post='71778']
[quote]Not tested this but pretty sure a"24 hour" file will roll over at 0:00 UTC, not 24 hours from when it was started. [/quote]

Berti
I still do want to get to the bottom of this issue, is a bit of pain. At least now though, I have a record on 1 graph of the days trend data.

OK so I go back on what I said, but at least I proved myself wrong !!

I see what you mean now - that a "1 day" file rolls over at 0:00 as I meant originally. But as you say, setting a log file for "24 Hours" operates differently.

I've done a quick test (less than 24 hours though) but agree that the start of the logfile is the time the Runtime is started (actually it is from the START of the hour in which runtime was started e.g. n:00). So yes, 24 hours from then the new data file will start. This is different to what I said before but makes more sense now. Are you sorted now?

Bertie

i have this problem allways btw. I solved it by telling the customer it's a bug and I don't have the power to fix it. customers mainly are satisfied with 1day log file. in winter it goes from 0100 to 0100 next day and in summer it goes from 0200 to 0200 next day (serbia is GMT + 1 in winter, + 2 in summer). I don't understand why it is not possible to make this data log working according to the clock on the pc? is it?