CX Supervisor DataLogging

[scottmurphy]

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...

[scottmurphy]

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!!

[PdL]

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.

[scottmurphy]

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.

[Berti Baker]

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

[scottmurphy]

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.

[tashinz]

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?

[Berti Baker]

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

[tashinz]

Not quite sure I understood you. can you explain a bit more? Edited July 22, 2008 by tashinz

[scottmurphy]

[Berti Baker]

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

[tashinz]

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? Edited July 28, 2008 by tashinz