Здравствуйте. Проблема с синхронизацией каналов OUTPUT. Запускаю RTM рабочий и резервный. На рабочем в канал ни чего не передаю, на резервном пытаюсь передать в канал новое значение (значение канала, естественно, не изменяется). Если после этого остановить рабочий RTM, то резервный передает в канал 0. Если канал изменялся на рабочем RTM до попытки передачи с резервного, сброса в 0 не происходит. Пробовал с Ломиконтом 110 и Simatic S7-300 + Merz OPC server, ошибки проявляется в обоих случаях. Синхронизация в каналах включена, @Input_Output = 16#1000.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Такая ситуация возможна, если у резервного узла были попытки изменения его значения каким-то другими средствами, не по сигналам синхронизации от Мастера. Это могут быть действия оператора или программы, или какие-то внешне сигналы. Если эти попытки имеют место, при переходе в режим Мастера узел будет посылать последнее значение этого канала.
Posted by Сергей Морозов (Участник № / Member № 2076) on :
Об этом я и говорю. Оператор ошибочно пытается ввести значение на резервном узле, сначала ничего не происходит, а потом посылка ложного значения в контроллер. Это неправильно, на реальном объекте эта ситуация может стать аварийной. На мой взгляд это недоработка. Как этого избежать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Управление каким-либо параметром с консоли резервного узла должно быть либо полностью реализуемым, либо заблокированным. Если оператор резервного узла имеет право управлять каким-либо параметром, у этого канала не должно быть признака синхронизации. Команда оператора должны сразу исполняться. Если он не имеет права управления, то соответствующие ГЭ на экране должны быть блокированы или невидимы. Следует подчеркунть, что управление одним параметров от разных операторов на реальном объекте может привести к аварии.
Posted by Сергей Морозов (Участник № / Member № 2076) on :
С DRTMом я познакомился два дня назад. Сразу наткнулся на то, что нет управления с резервного узла. Был удивлен, но принял как данность. Судя по Вашему ответу возможно одновременное управления и с основного и с резервного узлов. Почему у меня не получается? Признак синхронизации снят, статус узлов (работа/резерв) определяется правильно, @Status.CC2 на обоих узлах равен 0х40.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Под управлением каких исполнительных модулей Вы запускаете узлы? По какому выходному интерфейсу Вы пытаетесь управлять? Допускает ли этот интерфейс наличие двух мастеров в канале связи? Как Вы проверяли исполнение команд управления у резерва? Что означает "одновременное управления и с основного и с резервного узлов"? Вы действительно подаете во внешний приемник 2 разные команды от двух узлов? Меняется ли атрибут Q канала управления у резерва? "Подключен" ли канал управления у резерва к приемнику - атрибут W(8) должен быть равен 0(+)? Выставляется ли каналу управленияу резерва признак недостоверности? Если Вы управляете по последовательному интерфейсу, можете ли Вы перехватить трафик COM-порта и посмотреть, посылает ли резерв Ваши команды управления?
Posted by Сергей Морозов (Участник № / Member № 2076) on :
Работает Double Force RTM+, взят с сайта, дата в архиве 15.07.2010, IDE от той же даты. Пробовал управлять по COM Ломиконтом 110, и по MPI Симатиком S7-300. Два мастера возможны, одну из машин отключал от сети, после чего резервная переходила в режим "работа" и получала все возможности управления. Исполнение команд проверял считыванием в узел изменяемых переменных. Т.е. для каждой переменной контроллера были созданы два канала IN и OUT. Под одновременным управлением я понимаю наличие двух совершенно идентичных, равноправных узлов, синхронизированных между собой, резервный отличается только тем что сам не ведет прямого общения с переферией, а делает это через рабочий узел. Трафик COMа перехватывал, резервный узел просто молчит, пока есть основной узел. С атрибутами и недостоверностями пытаюсь разобраться. При создании проекта ничего не менял, кроме минимально необходимой настройки каналов и RTM.
Posted by Сергей Морозов (Участник № / Member № 2076) on :
Забыл уточнить версия 6.07
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Вы противоречите идее резервирования. По каждому параметру может быть или "синхронизация", или "равноправие". Вместе это не реализуется. И подчеркиваю, что "равноправное" управление от двух операторов - это возможный источник нарушений в процессе управления, вплоть до аварий.
2. Два мастера, одновременно работающие на одной последовательной шине RS - это нонсенс. Как Вы объединяли каналы связи с Ломиконтом 110 от двух узлов? У Ломиконта для каждого свой COM-порт?
3. Если Вы меняете значение управляющего канала, а перехватчик показывает, что резервный узел ничего не посылает, видимо, этот канал отключен от последовательного канала. Это должно быть видно в атрибуте 8.
Posted by Сергей Морозов (Участник № / Member № 2076) on :
С Ломиконтом все просто, он имеет 5 последовательных портов (1 в МУС2 и 4 в МИС2), два из них могут быть одновременно настроены на работу с ЭВМ. У каждого узла соответственно есть СОМ-порт с преобразователем в ИРПС. С атрибутами ситуация следующая: достоверность всегда есть, ее нет только если на рабочему узле разорвать связь. Атрубут 8 на резервном узле равен 1. Выходные значения, атрибут 9, на резервном узле изменяются.
По поводу идеи резервирования, я явно чего-то не понимаю. Я предполагаю следующие возможные варианты (далее для примера два RTM и один ломиконт с двумя портами связи). 1. Узлы полностью равноправны, каждый держит связь в контроллером, резервный синхронизирует внутренние данные узла с рабочим. 2. Узлы неравноправны. Каждый держит связь в контроллером. Резервный узел не имеет возможности управления, только контроль. 3. Только рабочий держит связь с контроллером. Резервный получает данные и отправляет управляющие воздействия через систему синхронизации с рабочим. Т.е. резервный узел транслирует команды рабочему, а рабочий принимает решение об их предаче (или не передаче, если они противоречат собственным данным рабочего узла) контроллеру. 4. Рабочий держит связь с контроллером. Резервный только получает данные через систему синхронизации с рабочим, и не имеет возможности управления.
Какая из концепций принята в TRACE MODE? Для меня желателен третий вариант, вполне приемлем четвертый. Ничего похожего на третий пока не получается. А с четвертым есть проблема, собственно с нее и началась тема.
По поводу потенциальной аварийности, я все прекрасно понимаю, и учитываю риски при разработке проекта.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Канал управления в резервном узле отключен от внешнего приемника (атрибут 8 равен 1). Поэтому он не посылает своих команд. Это происходит, видимо, потому, что Вы у этого канала не убрали в настройках свойство сихронизации.
Основная цель штатного режима резервирования - обеспечение синхронности данных в резервном узле по отношению к рабочему. Кроме варианта 3 - остальные варианты возможны. Однако, первый вариант, хотя и реализуем, но представляется непродуктивным. Если узлы полностью равноправны, кусочная синхронизация смысла не имеет и функция резервирования - тоже.
Степень автономности в варианте 2 должна быть очень четко просмотрена и запрограммирована, т.к. при собственном асинхронном мониторинге внутренние переменные у резервного узла могут быть существенно рассинхронизированы с рабочим узлом. И при переходе резервного узла в режим рабочего перехват управления может быть не вполне безударным.
Вариант 4 штатный. Но Вы должны обеспечить в операторском интерфейсе и программном управлении блокирование несинхронизированных воздействий.
Posted by Сергей Морозов (Участник № / Member № 2076) on :
Все понял. Надеюсь последний вопрос, как осуществить блокирование. И возможно ли блокировать на управление весь узел сразу.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Блокирование необходимо осуществлять программно по двум направлениям. Аргументом для программы должен быть статус собственного узла, который Вы определите с помощью соответствующей системной переменной. Выходами программы могут быть аргументы, управляющие, например, видимостью слоев экранов, на которые Вы выводите органы операторского управления. Для блокрования программного управления можно, например, просто выключать каналы CALL, вызывающие эти программы.
Естественно, канал, вызывающий программу блокирования, не должен иметь установленное свойство синхронизации.
