I used to not use the Automated Clock Check feature in LoggerNet, but over the past couple of months I started using it. So far I've been pleased. I have all my dataloggers set to clock check on a daily basis and they will automatically sync with the server clock if deviation is greater than 59 seconds.
Well in preparation for the change back to DST, I wanted to make sure I wasn't going to lose any data. So I found that there are LoggerNet clock settings that will ignore daylight saving time adjustments.
A couple of days before the switch to DST, I went into LoggerNet and selected
"Use local time without correction for daylight saving time".
After the switch, I verified that my server time in LN was indeed still -5 GMT instead of -4 GMT and thought all was good.
For most of my dataloggers, all was good, but there are several that LoggerNet messed up on. LN set the clock forward on one CR206, then set it back on the same day.
So, at 2300 on 14 March 2010, LN set the clock forward by one hour. Then at 0100 on 15 March 2010, LN sets the clock back an hour. Here are the timestamps for that logger.
3/14/2010 22:45
3/14/2010 23:00
3/15/2010 0:15
3/15/2010 0:30
3/15/2010 0:45
3/15/2010 1:00
3/15/2010 0:15
3/15/2010 0:30
And it appears to be doing this every day now.
Any ideas on what might be going wrong? I checked the clock settings for the affected and unaffected loggers and they are identical, so I'm not sure why this issue is affecting some loggers and not others.
EDIT: Another piece of information. I have four different PakBusPorts, the problems are occurring on three of the four PakBusPorts. The fourth PB Port has not had any clock problems. I checked the associated IPPort and PakBusPort settings and they are the same for all except for the PakBus addresses for the PakBusPorts.
* Last updated by: lespedeza on 3/18/2010 @ 1:16 PM *
What version of LoggerNet?
Could there be some conflict with another computer setting time in the datalogger?
In the C:\Campbellsci\LoggerNet\Logs directory there is a Trans*.log that contains information on clock set and clock check events. In those events, the first clock value is the datalogger clock, the second value is the LoggerNet server clock, and the following value is the offset, in seconds, between the two clocks. Looking at these values may help to provide insight into what is going on.
Dana W.
Thanks Dana. That was it...you refreshed my memory. I didn't connect the dots until you mentioned it.
I was out on Friday, and in my absence someone opened LoggerNet on our old LN server to check on things and never closed it down. The old LoggerNet had the correction for DST and the two LN's were correcting each other's clock changes. This not only caused this clock problem but also caused a bunch of communication failures.
I didn't realize that the old LN was running until I logged onto my old LN server yesterday. I shut down LN on that machine, so after tonight all should be good.
Thanks again for your assistance, Dana, I appreciate it.
Jimmy
Hi Jimmy,
In the future, if you need to operate with two computers connecting to the dataloggers, make sure the PakBus addresses of the LoggerNet servers are set to different values.
The default value is 4094. One server can be left at 4094, but change the other one to a value between 4000 and 4088 (other software of ours uses 4089-4093). Anything above 4000 is a broadcast address and any device in the network will respond to "hello requests" from these addresses.
Glad it was something simple to resolve. Thanks for letting me know.
Dana W.
In the future, if you need to operate with two computers connecting to the dataloggers, make sure the PakBus addresses of the LoggerNet servers are set to different values.
I should clarify that this is likely the reason for the communication failures. But if all PakBus devices in the network have different addresses, they should all "play nicely" together (as long as the link you are on supports simultaneous connections).
Dana W.
Dana,
That was definitely it. All clocks were checked, but none were set last night. And my communication failures are gone. I currently don't have a need for simultaneous comm, but will keep your advice in mind if I ever do. The old LN server had the same setup as the new LN, so the duplicate PB addresses were probably causing the communication failures.
Thanks again,
Jimmy