ASTRO_CLOCK vs. TimeManager, sunrise/set
I'm getting incorrect sunrise and sunset times from the Astro_Clock function. Using TimeManager I get the correct sunrise & sunset times. Both using same timeserver, same latitude & longitude.
Tech support suggests not using Astro_Clock.
I'm curious....anyone else encountered this before?
Thanks
Tech support suggests not using Astro_Clock.
I'm curious....anyone else encountered this before?
Thanks
Comments
To use ASTRO_CLOCK, check when sunrise and sunset are supposed to be, then adjust your offset that you pass to ASTRO_CLOCK to make them match. Offset seems to +16 from local time for us out here (PST/PDT).
http://www.amxforums.com/showthread.php?t=6681&highlight=astro
There is nothing wrong with ASTRO_CLOCK. I?ve been using it for years without issue. You?ll have to add an hour if DST is true.
Are you using the correct value for GMT? For example here in my neck of the woods in the Midwest it?s -6.
Post your code if you want and we?ll figure out the problem.
Nothing weird about it, no need to fudge the numbers. The function works correctly. I never heard of a +16 hour offset, you sure it?s not -8? Although rolling over into the next day will get you to the same place timewise.
the question then is how do you know when DST is active? CLock Manger only tells you if you have or have not enabled DST not whether it is ACTIVE.
I would assume the DST rules are built it otherwise what's the purpose of this query? But are the rules universal for all that observe it? Hmmm...
CLKMGR_SET_START_DAYLIGHTSAVINGS_RULE
CLKMGR_SET_END_DAYLIGHTSAVINGS_RULE
CLKMGR_SET_DAYLIGHTSAVINGS_MODE
CLKMGR_SET_DAYLIGHTSAVINGS_OFFSET
I would assume if you set these astro_clock settings it will return the correct time so you won't need to -+ an hour for DST. You could also just create your own DST flag when DST begins and ends and do the math based on your flag.
We are -8/-7DST. I tried -8 first. Did not function as expected - hour was way off. I had to apply a 16 hour offset from local time (basically, +8/+9DST) in order to get correct values. Time was set and the proper timezone was selected on the master.
Latitude = 32.72
Longitude = -117.16
GMT = -8
Adding an hour for DST and I get:
Sunrise = 06:28
Sunset = 19:11
You must have something else going on that’s not correct. Are you using DOUBLEs for Lat, Long, and GMT? Is your Longitude negative?
The time on the master should have nothing to do with the results. It's just a formula. Obviously the date has to be correct.
Thinking about it now, no, it shouldn't. I can't describe why I have this problem, but I don't really care much, since it worked in the end.
What am I missing? Is there a document somewhere I have missed?
Re: other stuff, they have some documentation but I don't use them.
I'll write some sample code with ASTRO_CLOCK() (using clkmgr with an assumed +1h DST offset, although you can pull this from the master too). All you need to do is include this and you'll have working sunrise/sunset.
/* variables */ define_variable volatile double ss_coords[2] = {0.0, 0.0} // set these to target lat/long volatile double ss_gmt_offset volatile char ss_sunrise[8] volatile char ss_sunset[8] /* start */ define_start // use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) { // startup code when DST is on goes here wait (200) send_string 0, 'DST is active' } else { // startup code when DST is not on goes here wait (200) send_string 0, 'DST is not active' } /* mainline */ define_program wait (600) { astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(), LDATE, ss_sunrise, ss_sunset) // send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset" if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) { // code for when sunrise occurs goes here send_string 0, 'SUNRISE OCCURRED' } if (left_string(ss_sunset, 5) == left_string(TIME, 5)) { // code for when sunset occurs goes here send_string 0, 'SUNSET OCCURRED' } }Set ss_coords and ss_gmt_offset. Every minute, ss_sunrise and ss_sunset will be updated, and instructions will be executed depending on if the current time matches.. Check these by debugging to make sure they're right. I haven't tested it. It should work. Point out issues if you see them, please.
EDIT: fixed obvious bug.
EDIT 2: As indicated by Joe Hebert below, the DST stuff likely doesn't work properly. I'll update this later with an implementation for you, glr-fti.
You need to set the GMT value just like you need to set lat and long. Check out the help file. In your case for the west coast it should be -8. Do that and you should be fine. No fudging needed.
// use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) {Unless things have changed I believe that will only tell you if DST is observed or not. It doesn?t tell you if it?s active at the moment which is what Gary (glr-fti) is talking about.
This has been brought up on the forum previously and I sure hope AMX gives us the flag in the future. Or maybe we have it and I just don?t know about it.
I assumed DST would turn on / off - so the switch is to turn observance on, rather than currently being observed on? I didn't test this thoroughly. That's kind of backwards thinking or bad function naming - especially since documentation for clkmgr stuff is pretty bad. It's something I'll look at closer, thanks. (Which means it's trivial but not simple to get DST being observed now, as you now need to calculate based on current rules...sigh.) I'll probably write a function we can all use (clkmgr_is_currently_dst()?)
Easy there big fella, no need to get your feathers ruffled.
The ?proper? offset for the west coast is -8 GMT. It?s easy enough to look up on a time zone map like the one built into Windoze. There is no such thing as +16 GMT. But as I stated before since we?re dealing with a 24 hour clock +16 rolls over into the next day and ends up the same as -8 the next day.
If I use your code with the correct offset of -8 GMT then I get the correct value for sunrise and sunset.
ASTRO_CLOCK works fine with the correct values. Nothing weird about it.
Yes, I believe that?s the case. Sucks I know. I hope I?m wrong.
Peace.
I get the wrong value unless I pass +8 or +9. Only had to use ASTRO_CLOCK() once so far (had to do it a lot with C restron customers but never had the request until recently with an AMX customer). I tried it on my NI with the same results. I'll probably be hacking away at stuff this weekend so I'll try to figure out where the bug lies.
Using your code with the correct value for GMT (-8) I get then correct values for sunrise/sunset for San Diego (ignoring the whole DST thing) as shown below:
define_variable _ volatile double ss_coords[2] = {32.72, -117.16} // set these to target lat/long [b]volatile double ss_gmt_offset = -8[/b] volatile char ss_sunrise[8] volatile char ss_sunset[8] /* start */ define_start // use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) { // startup code when DST is on goes here wait (200) send_string 0, 'DST is active' } else { // startup code when DST is not on goes here wait (200) send_string 0, 'DST is not active' } /* mainline */ define_program wait (600) { astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(), LDATE, ss_sunrise, ss_sunset) send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset" if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) { // code for when sunrise occurs goes here send_string 0, 'SUNRISE OCCURED' } if (left_string(ss_sunset, 5) == left_string(TIME, 5)) { // code for when sunset occurs goes here send_string 0, 'SUNSET OCCURED' } }And the output:
There?s no bug in your code or ASTRO_CLOCK. Where?s the problem?
Here is a snapshot showing the value for your GMT true:
I don't think you're getting it, and won't really continue - I experienced this offset problem and continue to, others don't, so obviously there is a problem somewhere and as I said, I'll try to figure it out.
I explicitly wrote that I haven't tested this code. Works for you? Great. Maybe my other code has some bug this doesn't, I don't know. I'll test it when I get time but I'm not going to argue with you over semantics (+16h local to PST and +8/+9GMT means the same exact thing! last time I'm writing it!) and try to drive my point yet again when I've written my experience numerous times already.
One last time. If you use the correct value for GMT as the function calls for which is -8 for pacific time (as the picture above shows) then you?ll get the correct value.
I took the time to test your code and showed you the output. Your code is fine, ASTRO_CLOCK is fine. What else can I do? It?s all there in black and white with a picture.
I don?t care about the local time +/- whatever argument (or parameter as Hedberg might call it.
I previously stated that ASTRO_CLOCK works. I know where the documentation is as well. I also know where the documentation is for i!Schedule, i!Time Manager, and Clock Manager. The problem is that none does what is needed in the scenario described. I've been testing i!Time Manager and changing code the last few days, after talking with TS, to see if I could nail this issue. Just when I think I have it something weird happens and changes my offset back to non DST.
As has been pointed out clkmgr_is_daylightsavings_on() only returns whether it has been enabled not whether it is active. Yes we need another that says clkmgr_is_daylightsavings_ACTIVE() then we can all go back to bed.
I'll write something later (likely this weekend) that uses clkmgr to check if you are in DST or not.
wow, I really got a discussion going on this....sorry to post a message and not be able to respond until now.
Anyway - an update. I'm going to be doing a bunch of time related stuff on an upcoming job so I wanted to bring myself up to date on the various time and astronomical clock functions in Netlinx and the current generation of firmware.
Toward that end, I wrote a program that attempts to use both the TimeManager module and the built-in clock manager and astro_clock routines.
I'm running this code on a NI2000 running master FW v3.50.430.
What is puzzling is that I seem to be getting 4 minutes difference between the Sunrise and Sunset times from Timemanager and astro_clock.
Since I don't have a touch panel handy, my code runs a timeline to generate a timeline event every minute. I call the ASTRO_CLOCK function to get its Sunrise & Sunset for my Seattle location.
I'm running timemanager using the same lat and long values. The system is set to use an external time server. I'm getting a 4 minute difference between the sunrise and sunset times between ASTRO_CLOCK and TimeManager. For example for today 4/13/10 astroclock gives me sunrise of 06:28:00 (which is +4 minutes from the correct time) and timemanager gives me 06:24:00, the correct sunrise time.
As someone else noted, it seems like the numbers ought to be dead on the same. Maybe I have a typo that I'm missing. Here is my source......
DEFINE_DEVICE dvDEBUG = 0:0:2 dvMASTER = 0:1:2 vdvTP = 33002:1:2 dvTMTIMESYNC = 0:3:2 vdvTMEVENTS = 33001:1:2 //****************************************************************************** // CONSTANT DEFINITIONS //****************************************************************************** DEFINE_CONSTANT // TIME SERVER CONSTANTS (* TIMESERVER PROTOCOLS *) nProtoNone = 0 nProtoDaytime = 1 nProtoTime = 2 nProtoSNTP = 3 nProtoSNTPBCast = 4 (* TIME SERVER CHANNELS *) nTmSunriseChannel = 1 nTmSunsetChannel = 2 nTmDstChannel = 3 nTmTimeChangeChannel = 4 (* TIME SERVER LEVELS *) nTmGmtEffLevel = 1 nTmGmtLevel = 2 nTmLongLevel = 3 nTmLatLevel = 4 //****************************************************************************** // DATA TYPE DEFINITIONS //****************************************************************************** DEFINE_TYPE //****************************************************************************** // VARIABLE DEFINITIONS //****************************************************************************** DEFINE_VARIABLE // TIME SERVER & TIME RELATED VARIABLES //VOLATILE CHAR cTIMESTRSUNRISE[50] //VOLATILE CHAR cTIMESTRSUNSET[50] //VOLATILE SINTEGER sSUNRISEHOUR //VOLATILE SINTEGER sSUNSETHOUR //VOLATILE SINTEGER sSUNRISEMINUTE //VOLATILE SINTEGER sSUNSETMINUTE VOLATILE CHAR cTMSUNRISE[10] VOLATILE CHAR cTMSUNSET[10] (* TIMEZONE *) VOLATILE CHAR cTMTZNAME[100] VOLATILE CHAR cTMTZDESC[10] VOLATILE DOUBLE dTMTZGMTOFFSET VOLATILE CHAR cTMTZDSTRULES[1000] (* LOCATION *) VOLATILE CHAR cTMLOCNAME[100] VOLATILE DOUBLE dTMLOCLONG VOLATILE DOUBLE dTMLOCLAT (* TIMESERVER *) VOLATILE INTEGER nTMTSPROTOCOL VOLATILE INTEGER nTMTSCHECKTIME VOLATILE CHAR cTMTSSERVER[100] CLKMGR_TIMESERVER_STRUCT TS // TO HOLD CURRENT TIMESERVER INFO CLKMGR_TIMEOFFSET_STRUCT DST_OFFSET VOLATILE CHAR cDST_START_RULE[35] VOLATILE CHAR cDST_END_RULE[35] VOLATILE INTEGER nRESYNCH_PERIOD // MINUTES VOLATILE INTEGER bDST_ON VOLATILE SINTEGER sRET_CODE VOLATILE CHAR cTZ_STRING[25] VOLATILE DOUBLE dHRS_TO_UTC // CURRENT HRS FROM GMT OR UTC CONSTANT LONG lONE_MIN_TL = 1 // TL ID VOLATILE LONG ONE_MIN[] = {60000} // 60,000/1,000 = 60 SEC VOLATILE INTEGER nTL_RET // TIMELINE_CREATE RETURN VALUE VOLATILE DOUBLE dLATITUDE = 47.6350 // NORTH LATITUDE FOR OLIN PLACE VOLATILE DOUBLE dLONGITUDE = -122.3129 // WEST LONGITUDE FOR OLIN PLACE VOLATILE CHAR cSUNRISE[10] VOLATILE CHAR cSUNSET[10] //****************************************************************************** // INCLUDE FILES //****************************************************************************** //****************************************************************************** // LATCHING DEFINITIONS //****************************************************************************** DEFINE_LATCHING //****************************************************************************** // MUTUALLY EXCLUSIVE DEFINITIONS //****************************************************************************** DEFINE_MUTUALLY_EXCLUSIVE //****************************************************************************** // SUBROUTINE AND FUNCTION DEFINITIONS //****************************************************************************** //****************************************************************************** // STARTUP //****************************************************************************** DEFINE_START (***********************************************************) (* STEP 1 - CONFIGURE THE TIMEZONE: *) (***********************************************************) // CONFIGURE TIMEZONE // PARAMETER 1: TIMEZONE NAME. EX: "EASTERN" // PARAMETER 2: TIMEZONE DESCRIPTION. EX: "E%ST" // PARAMETER 3: TIMEZONE GMT OFFSET IN HOURS. EX: -5.0 cTMTZNAME = 'Pacific' cTMTZDESC = 'PD%sT' dTMTZGMTOFFSET = -8.0 // CONFIGURE TIMEZONE RULES // PARAMETER 1: DAYLIGHT SAVINGS STRING. EX: "NONE", "US" OR CUSTOM. // CUSTOM STRING: "MONTH" "DAYDESCRIPTION" "TIME" "OFFSET FROM STD" "DESCRPTION" // "MONTH": MONTH NAME EX: "APR" // "TIME" TIME TO ACTIVATE (HH:MM:SS, 24 HOUR). EX: "02:00:00" // "OFFSET FROM STD" TIME TO OFFSET FROM GMT (HH:MM:SS, 24 HOUR). EX: "01:00:00" // "DESCRIPTION" STRING TO REPLACE "%S" WITH IN TIMEZONE DESCRIPTION. EX: 'D' // "DAYDESCRIPTION" DAY DESCRIPTION. FIXED DATE, LAST DAY OF WEEK OR // FIRST DAY OF WEEK BEFORE/AFTER DATE // FIXED EX: "15" // LAST DAY OF WEEK EX: "LASTSUNDAY" // FIRST DAY OF WEEK BEFORER DATE-EX: "SUN<=24" // FIRST DAY OF WEEK AFTER DATE-EX: "SUN>=1" cTMTZDSTRULES = 'US' (***********************************************************) (* STEP 2 - CONFIGURE PHYSICAL LOCATION: *) (***********************************************************) // CONFIGURE PHYSICAL LOCATION // PARAMETER 1: LOCATION NAME. EX: 'SEATTLE' // PARAMETER 2: LOCATION LONGITUDE. EX: -122.33 (>0 == EAST, < 0 == WEST) // PARAMETER 3: LOCATION LATITUDE. EX: 47.6 (>0 == NORTH, < 0 == SOUTH) cTMLOCNAME = 'Seattle' dTMLOCLONG = -122.3129 dTMLOCLAT = 47.6350 (***********************************************************) (* STEP 3 - CONFIGURE TIME SERVERS: *) (***********************************************************) // CONFIGURE TIME SERVERS // PARAMETER 1: PROTOCOL, 0=DISBALED, 1=DAYTIME(13/UDP, 13/TCP), 2=TIME(37/UDP, 37/TCP), 3=SNTP(123/UDP), 4=SNTP BROADCAST (137/UDP). EX: 2 // PARAMETER 3: DEFAULT SERVER. EX: 'MYTIMESERVER.MYDOMAIN.COM'. LEAVE BLANK TO READ FROM TIME SEVRER FILE (TIME/NIST_SVR.LST) // PARAMETER 2: CHECK TIME INTERVAL IN SECONDS. USE 0 FOR DEFAULT (2 HOURS). EX: 3600 // PARAMETER 4: PREFERED INDEX OF TIMESERVERS IN LIST. EX: 2 // NOTES: IF PARAMETERS 3 IS SUPPLIED, PARAMETER 4 IS IGNORED // IF PARAMATER 3 IS AN EMPTY STRING AND PARAMETER 4 IS 0, A DEFAULT WILL BE PICKED FROM THE LIST IS POSSIBLE // CONSTANTS- // nProtoNone = 0 // nProtoDaytime = 1 // nProtoTime = 2 // nProtoSNTP = 3 // nProtoSNTPBCast = 4 nTMTSPROTOCOL = nProtoSNTP nTMTSCHECKTIME = 0 cTMTSSERVER = '' (***********************************************************) (* ALTERNATE MANUAL TIMEZONE CONFIGURATIONS: *) (***********************************************************) // THESE ARE SHOWN FOR EXAMPLE PURPOSES AND REPRESENT INFORMATION THAT IS NOT GUARANTEED TO BE CORRECT! // HERE IS AN EXMAPLE CONFIGURATION FOR SANTIAGO, CHILE WHICH IS -4 HOURS BEHIND GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE SATURDAY ON OR AFTER OCTOBER 9TH AT MIDNIGHT (JUMP AHEAD 1 HOUR) AND THE SATURDAY ON OR AFTER THE 9TH OF MARCH AT MIDNIGHT (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS CST" OR "HH:MM:SS CDT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "33S27, 70W40": // // cTMTZNAME = 'Santiago' // cTMTZDESC = 'C%sT' // dTMTZGMTOFFSET = -4.0 // cTMTZDSTRULES = "'Oct Sat>=9 00:00:00 01:00:00 D',$FF,'Mar Sat>=9 00:00:00 00:00:00 S'" // // AND // // cTMLOCNAME = 'Santiago' // dTMLOCLONG = -70.67 // dTMLOCLAT = -33.45 // HERE IS AN EXMAPLE CONFIGURATION FOR SYDNEY, AUSTRALIA WHICH IS +10 HOURS AHEAD OF GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE LAST SUNDAY IN OCTOBER 2:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN MARCH AT 3:00 AM (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS EST" REGARDLESS OF DAYLIGHT SAVINGS AND IS LOCATED AT "33S52, 151E13": // // cTMTZNAME = 'Sydney' // cTMTZDESC = 'EST' // dTMTZGMTOFFSET = 10.0 // cTMTZDSTRULES = "'Oct LastSun 02:00:00 01:00:00 X',$FF,'Mar LastSun 03:00:00 00:00:00 X'" // // AND // // cTMLOCNAME = 'Sydney' // dTMLOCLONG = 151.22 // dTMLOCLAT = -33.86 // HERE IS THE EXAMPLE CONFIGURATION FOR LONDON, ENGLAND WHICH USES GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE LAST SUNDAY IN MARCH AT 1:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN OCTOBER AT 2:00 AM (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS BST" OR "HH:MM:SS GMT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "51N30, 0W10": // // cTMTZNAME = 'London' // cTMTZDESC = '%s' // dTMTZGMTOFFSET = 0.0 // cTMTZDSTRULES = "'Mar LastSun 01:00:00 01:00:00 BST',$FF,'Oct LastSun 02:00:00 00:00:00 GMT'" // // AND // // cTMLOCNAME = 'London' // dTMLOCLONG = -0.16 // dTMLOCLAT = 51.50 // TIMELINES.... nTL_RET = TIMELINE_CREATE(lONE_MIN_TL,ONE_MIN,LENGTH_ARRAY(ONE_MIN),TIMELINE_ABSOLUTE,TIMELINE_REPEAT) SWITCH(nTL_RET) { CASE 0: { SEND_STRING dvDEBUG,"'TL lONE_MIN_TL SUCCESSFULLY STARTED.',$0D" } CASE 1: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIMELINE ID ALREADY IN USE.',$0D" } CASE 2: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIME ARARY NOT ARRAY OF LONGS.',$0D" } CASE 3: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: LENGTH SPECIFIED GREATER THAN LENGTH OF PASSED TIME ARRAY.',$0D" } CASE 4: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: OUT OF MEMORY.',$0D" } } // END OF SWITCH ON TIMELINE RETURN DEFINE_MODULE 'i!-TimeManagerMod' mdlTM(vdvTMEVENTS, dvTMTIMESYNC, (* TIMEZONE *) cTMTZNAME, cTMTZDESC, dTMTZGMTOFFSET, cTMTZDSTRULES, (* LOCATION *) cTMLOCNAME, dTMLOCLONG, dTMLOCLAT, (* TIMESERVER *) nTMTSPROTOCOL, nTMTSCHECKTIME, cTMTSSERVER) //****************************************************************************** // EVENTS //****************************************************************************** DEFINE_EVENT TIMELINE_EVENT[lONE_MIN_TL] { cTZ_STRING = CLKMGR_GET_TIMEZONE() SEND_STRING dvDEBUG,"$0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A" // PUT SOME SPACE BETWEEN REPORTS SEND_STRING dvDEBUG,"'CLKMGR CURRENT TIMEZONE IS: ',cTZ_STRING,$0D" IF(FIND_STRING(cTZ_STRING,'UTC',1)) { REMOVE_STRING(cTZ_STRING,'UTC',1) cTZ_STRING = LEFT_STRING(cTZ_STRING,(FIND_STRING(cTZ_STRING,':',1))-1) SEND_STRING dvDEBUG,"'CLKMGR cTZ_STRING= ',cTZ_STRING,$0D" } ELSE SEND_STRING dvDEBUG,"'UTC NOT FOUND IN CLKMGR cTZ_STRING!',$0D" IF(bDST_ON) dHRS_TO_UTC = -7.0 ELSE dHRS_TO_UTC = -8.0 sRET_CODE = ASTRO_CLOCK(dLONGITUDE,dLATITUDE,dHRS_TO_UTC,DATE,cSUNRISE,cSUNSET) SWITCH(sRET_CODE) { CASE 0: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK FUNCTION EXECUTED OK',$0D" } CASE 1: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK LATITUDE ENTRY ERROR',$0D" } CASE 2: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK LONGITUDE ENTRY ERROR',$0D" } CASE 3: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK HOURS ENTRY ERROR',$0D" } CASE 4: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK DATE ENTRY ERROR',$0D" } } // END OF SWITCH ON RETURN CODE IF(CLKMGR_IS_NETWORK_SOURCED()) SEND_STRING dvDEBUG,"'CLOCK MANAGER IS NETWORKED SOURCED',$0D" ELSE SEND_STRING dvDEBUG,"'CLOCK MANAGER IS STAND ALONE',$0D" CLKMGR_GET_ACTIVE_TIMESERVER(TS) CLKMGR_GET_DAYLIGHTSAVINGS_OFFSET(DST_OFFSET) cDST_START_RULE = CLKMGR_GET_START_DAYLIGHTSAVINGS_RULE() cDST_END_RULE = CLKMGR_GET_END_DAYLIGHTSAVINGS_RULE() nRESYNCH_PERIOD = CLKMGR_GET_RESYNC_PERIOD() bDST_ON = CLKMGR_IS_DAYLIGHTSAVINGS_ON() IF(TS.IS_SELECTED) SEND_STRING dvDEBUG,"TS.URL_STRING,', ',TS.LOCATION_STRING,' IS CURRENTLY SELECTED TIMESERVER.',$0D" ELSE SEND_STRING dvDEBUG,"'CLKMGR TIMESERVER IS NOT CURRENTLY SELECTED',$0D" SEND_STRING dvDEBUG,"'CURRENT TIME IS ',TIME,$0D" SEND_STRING dvDEBUG,"'DATE IS ',DATE,$0D" SEND_STRING dvDEBUG,"'SUNRISE TODAY AT ',cSUNRISE,$0D" SEND_STRING dvDEBUG,"'SUNSET TODAY AT ',cSUNSET,$0D" } // END OF TIMELINE_EVENT[lONE_MIN_TL] DATA_EVENT[vdvTMEVENTS] (***********************************************************) (* DATA_EVENT: STRINGS FOR SUNRISE/SUNSET *) (* PURPOSE: PARSE STRINGS FOR SUNRISE AND SUNSET *) (***********************************************************) { STRING: { STACK_VAR CHAR cUPPER[30] STACK_VAR CHAR cTEMP[30] STACK_VAR CHAR cTRASH[30] cUPPER = UPPER_STRING(DATA.TEXT) cTEMP = DATA.TEXT cTRASH = REMOVE_STRING(cTEMP,'-',1) SELECT { ACTIVE (FIND_STRING(cUPPER,'SUNRISE-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Sunrise Time = ',cTEMP" cTMSUNRISE = cTEMP } ACTIVE (FIND_STRING(cUPPER,'SUNSET-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Sunset Time = ',cTEMP" cTMSUNSET = cTEMP } ACTIVE (FIND_STRING(cUPPER,'TIMEZONE-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Timezone = ',cTEMP" } ACTIVE (FIND_STRING(cUPPER,'TIMEDESC-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Time Description = ',cTEMP" } ACTIVE (FIND_STRING(cUPPER,'LOCATION-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager: Location = ',cTEMP" } } // END OF SELECT-ACTIVE } // END OF STRING DATA_EVENT } // END OF vdvTMEVENTS DATA_EVENT BUTTON_EVENT[vdvTMEVENTS,nTmSunriseChannel] (***********************************************************) (* BUTTON_EVENT: SUNRISE CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE SUNRISE OCCURS *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Sunrise occured at ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmSunsetChannel] (***********************************************************) (* BUTTON_EVENT: SUNSET CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE SUNSET OCCURS *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Sunset occured at ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmDstChannel] (***********************************************************) (* BUTTON_EVENT: DST ACTIVITY CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE DST RULES AFFECT A TIME CHANGE WITH *) (* A NON-ZERO TIME OFFSET (DST ACTIVE) *) (* CHANNEL IS RELEASE (AND TURNED OFF) WHEN *) (* THE DST RULES AFFECT A TIME CHANGE WITH *) (* A ZERO TIME OFFSET (DST INACTIVE) *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: DST is now active: ',TIME" } RELEASE: { SEND_STRING dvDEBUG,"'i!TimeManager: DST is now inactive: ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmTimeChangeChannel] (***********************************************************) (* BUTTON_EVENT: TIME CHANGE CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND PULSED) WHEN *) (* THE TIME IS CHANGED BY A COMMUNICATION *) (* WITH A TIME SERVER. *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Time adjusted by time server. New Time is ',TIME" } } LEVEL_EVENT[vdvTMEVENTS,nTmGmtEffLevel] (***********************************************************) (* LEVEL_EVENT: EFFECTIVE GMT OFFSET *) (* PURPOSE: LEVEL IS SENT WHENEVER THE EFFECTIVE GMT *) (* OFFSET IS CHANGED. THE EFFECTIVE OFFSET *) (* IS THE REAL GMT OFFSET WITH DLS CORRECTION*) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Effective GMT Offset = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmGmtLevel] (***********************************************************) (* LEVEL_EVENT: GMT OFFSET *) (* PURPOSE: LEVEL IS SENT WHENEVER THE GMT *) (* OFFSET IS CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: GMT Offset = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmLongLevel] (***********************************************************) (* LEVEL_EVENT: LONGITUDE *) (* PURPOSE: LEVEL IS SENT WHENEVER THE LONGITUDE IS *) (* CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Longitude = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmLatLevel] (***********************************************************) (* LEVEL_EVENT: LATITUDE *) (* PURPOSE: LEVEL IS SENT WHENEVER THE LATITUDE IS *) (* CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Latitude = ',FTOA(LEVEL.VALUE)" } //****************************************************************************** // MAINLINE PROGRAM //****************************************************************************** DEFINE_PROGRAM //****************************************************************************** // END //****************************************************************************** //******************************************************************************Regardless, I'm going to just use TimeManager and get on with things.....but I am curious where my error lies.
thanks (and take a deep breath),
Rich
Instead of DATE try LDATE and I believe that should resolve the difference you are seeing.
ASTRO_CLOCK calls for the mm/dd/yyyy format.
DATE returns mm/dd/yy and LDATE returns mm/dd/yyyy
Have fun.
Thanks Joe! That was it.
Rich
Always happy to help.
Long live ASTRO_CLOCK.
BTW I only changed to astro_clock because of an error the ZigBee Pro firmware update caused on a job that showed up in my daily log files. To minimize the errors plus being informed that astro_clock runs regardless and since there may be possible negative affects if !iTimemamger is running at the same time I decided to switch to the astro_function since I can control it somewhat and minimize the errors. So I pulled out Timemanager and changed to the astro clock. Of course I didn't pay attention and I didn't impliment it properly which this thread made me aware of.
This is a useful include file and can be easily plugged into your code in it's entirety or in parts. Some functions aren't completely tested but seem to work so if you find something that doesn't work properly feel free to fix it and let me know so I can fix mine. It will chcek to see if DST is in affect or not based on the start and stop dates. I don't do anything with that info since I haven't seen any problems with what the astro_clock function returns but you can use it to display on your TP.
There's some other time functions in here that aren't needed for the code in this include but are used elsewhere in my code and since they are time related I decided to store them in the time include so they would be easier for me to find.
Since this is an .axi there are parts that this file needs that isn't in this file. If you find you can't figure it out on your own and need the missing parts just let me know. A few things may make you scratch your head and yes 8 space indents, camel case w/ hungarian notations and braces where no real programmer would ever put them so deal with it.
If anybody wants to improve the get_holiday function (add holidays) feel free but post your additions.
--John