As promised, I've created a TimeSync package and uploaded it to SourceForge.
Almost three weeks ago, I posted a packaged version of TimeSync, fairly easy to make work in an existing system using i!-TimeManager. Several folks were having problems with it, and running my version (with much richer debugging) would allow me to diagnose the issue.
Well, it's been pretty quiet since then. Has anyone tried this version? Is anyone with problems interested in isolating what's going on and getting the problem fixed?
(FWIW: I'm not having problems, and never have, so I really need help to isolate what's going on)
I've tried setting up the code and compiling it as you have suggested and I am having a bit of trouble. Can you help me with more detailed instructions?
I have been trying to implement the Syslog portion of the code with problems. Do you have more detailed intructions on how tomake it work.
How would i set up a connection to a Linux machine to remotely log Syslog messages from the amx devices?
I'm not sure the kit included the SyslogMod module file (just the .AXI file).
I'd suggest first getting the module to work without syslog. Once that's done, adding in syslog is as simple as adding the SyslogMod.tko module file, adding a DEFINE_MODULE, and you're done.
If you have further problems, please be VERY specific with what the problem is - I can't help without a detailed problem. Also, look at the sample program in my installation kit; it uses the TimeSyncMod stuff just fine.
-- Jeff
P.S. You shouldn't need to compile anything except the mainline code (after minor edits for name server address, etc). Everything else is compiled and set to go (although, if you want, sources are on SourceForge).
Sheldon Samuels was bit by this problem, and he picked up my module off of SourceForge (the customer was royally pissed and wanted the control of time - critical for their application - to be more under Sheldon's control).
In working with my module, I believe he's identified the problem. If there is a corrupted NTP packet (quite possible in an Internet environment, but not nearly as likely in an Intranet environment), then NetLinx will accept the corrupted packet and improperly adjust the system clock. Furthermore, due to field overflows, if the time goes too far into the future, it won't even be able to adjust it back once it gets a corrected packet. Argh!
Give us a little time; I expect to have my module on SourceForge fixed soon. Hopefully I'll be able to have AMX incorporate those changes into their copy of my module.
I'll be traveling next week, but you should expect more news soon.
Comments
Almost three weeks ago, I posted a packaged version of TimeSync, fairly easy to make work in an existing system using i!-TimeManager. Several folks were having problems with it, and running my version (with much richer debugging) would allow me to diagnose the issue.
Well, it's been pretty quiet since then. Has anyone tried this version? Is anyone with problems interested in isolating what's going on and getting the problem fixed?
(FWIW: I'm not having problems, and never have, so I really need help to isolate what's going on)
Thanks,
-- Jeff
I have been trying to implement the Syslog portion of the code with problems. Do you have more detailed intructions on how tomake it work.
How would i set up a connection to a Linux machine to remotely log Syslog messages from the amx devices?
I've tried setting up the code and compiling it as you have suggested and I am having a bit of trouble. Can you help me with more detailed instructions?
I'd suggest first getting the module to work without syslog. Once that's done, adding in syslog is as simple as adding the SyslogMod.tko module file, adding a DEFINE_MODULE, and you're done.
If you have further problems, please be VERY specific with what the problem is - I can't help without a detailed problem. Also, look at the sample program in my installation kit; it uses the TimeSyncMod stuff just fine.
-- Jeff
P.S. You shouldn't need to compile anything except the mainline code (after minor edits for name server address, etc). Everything else is compiled and set to go (although, if you want, sources are on SourceForge).
Sheldon Samuels was bit by this problem, and he picked up my module off of SourceForge (the customer was royally pissed and wanted the control of time - critical for their application - to be more under Sheldon's control).
In working with my module, I believe he's identified the problem. If there is a corrupted NTP packet (quite possible in an Internet environment, but not nearly as likely in an Intranet environment), then NetLinx will accept the corrupted packet and improperly adjust the system clock. Furthermore, due to field overflows, if the time goes too far into the future, it won't even be able to adjust it back once it gets a corrected packet. Argh!
Give us a little time; I expect to have my module on SourceForge fixed soon. Hopefully I'll be able to have AMX incorporate those changes into their copy of my module.
I'll be traveling next week, but you should expect more news soon.
-- Jeff