ASTRO_CLOCK vs. TimeManager, sunrise/set
Rich Abel
Posts: 104
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
0
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.
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.
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. I read your comments by the variable declarations and missed the part down below.
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:
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. ) It?s irrelevant as it has nothing to do with ASTRO_CLOCK.
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......
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