You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.
... we will see that the difference in times is ~7200 (2h difference between GMT+2 and GMT)
This has already manifested itself at least as the following problems:
If a taurus trend a/b/c/d eval:1 is run on M1, the values from a/b/c/d and eval:1 attributes are plotted with a time shift of 2h
If running taurus form a/b/c/d in M1 and then changing the value of the attribute, the read value may not be refreshed unless we set taurus.tauruscustomsettings.FILTER_OLD_TANGO_EVENTS=False. This is because said filter will use a local (M1) timestamp to compare with a timestamp obtained with lastval.time.totime() where lastval is the last attr value cached from a read of M2. The latter will always be "newer" (by ~7200s) and the polled attribute will be discarded.
While I do not find it terrible to force the time zone matching requirement, It may be nice to find a way of relaxing this requirement.
The text was updated successfully, but these errors were encountered:
Taurus implicitly assumes that all machines of a given distributed control system are:
If the second condition is not met, we may run into some unexpected issues. Consider an scenario with 2 machines:
Then, if on M1 we run :
... we will see that the difference in times is ~7200 (2h difference between GMT+2 and GMT)
This has already manifested itself at least as the following problems:
If a
taurus trend a/b/c/d eval:1
is run on M1, the values froma/b/c/d
andeval:1
attributes are plotted with a time shift of 2hIf running
taurus form a/b/c/d
in M1 and then changing the value of the attribute, the read value may not be refreshed unless we settaurus.tauruscustomsettings.FILTER_OLD_TANGO_EVENTS=False
. This is because said filter will use a local (M1) timestamp to compare with a timestamp obtained withlastval.time.totime()
wherelastval
is the last attr value cached from a read of M2. The latter will always be "newer" (by ~7200s) and the polled attribute will be discarded.While I do not find it terrible to force the time zone matching requirement, It may be nice to find a way of relaxing this requirement.
The text was updated successfully, but these errors were encountered: