Цитата:
Сообщение от Ilya J.
Думал когда-то над этим, но при наличии скады в общем интерес к синхронизации пропадает. Зачастую инженеры халатно относятся к коррекции времени и записям в журнал. В то же время скада регистрирует в реальном времени регистрирует нужные аварии.
Если продолжать вашу мысль, то можно попробовать избавиться от смарта, оформить в два макроса(чтобы можно было легко и безболезненно добавить этот макрос в проект), один макрос добавляется в мастер, другой в слейв, и надо проверять наличие отсутствие связи и рассинхронизацию. Количество блоков и переменных можно уменьшить, использовав преобразование времени в unixtime.
|
Я как-то бегло читал на форуме про unixtime. Там ребята жаловались, что время идет некорректно, отложилось в памяти. Сейчас немного посмотрел в чем фишка. Там урезан год, поэтому укладываемся в одно слово из 32 разрядов. В справке диапазон указан от 1970 по 2038г до 38 рукой подать, по сравнению с тем, что прошло от 1970, хотя этими разрядами можно дотянуть и до 2098-го года). Именно поэтому я пошел более честным путем. В моем случае точно никто не дотянет до 4096-го в отличие от 2038-го. Кроме того, я "запихнул" сигнал изменения даты в это же слово.
Насчет рассинхронизации согласен, это беда, но с появлением обмена слейв через сутки своего времени будет иметь точное время мастера и без захода в меню "Время и Дата" мастера, а без обмена пропишет нули)). Здесь как раз не проблема справиться с этим явлением.
В основном это и было задумано для исключения халатности при вводе времени в процессе пусконаладки.
Со СКАДА мне не приходилось работать на объектах: клиенты прижимистые. Так для себя иногда балуюсь. Поэтому мой вариант бюджетный)