Experimental Physics and
| |||||||||||||||||
|
Something very weird just happened here and we are still trying to figure out why. Are you guys running the standard R3.14.x version of base/src/libCom/osi/os/vxWorks/iocClock.c or does General Time just register itself as a time provider using iocClockRegister()? If the latter then the code it's running is all yours... Running iocs were updated by just setting the TIMEZONE environment variable and all is fine. We had R3.14 IOCs with both the correct and the old settings for EPICS_TIMEZONE, and both behaved as I expected them to, but we're not using a timing system with these, they're just soft timing slaves. The vxWorks version of the iocClockInit() routine that runs at iocInit() looks to see if the TIMEZONE variable is set and if so it uses that, but if not it copies the setting of EPICS_TIMEZONE to the TIMEZONE environment variable. After iocInit() EPICS_TIMEZONE will be ignored, and any adjustments at runtime have to be made directly to TIMEZONE. If you set TIMEZONE before iocInit(), does it still have the same value afterwards or is it being overwritten somehow? Is General Time or your hardware event receiver driver making any use of local time? It probably shouldn't be. - Andrew -- The right to be heard does not automatically include the right to be taken seriously. -- Hubert H. Humphrey
| ||||||||||||||||
ANJ, 10 Nov 2011 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |