Зарегистрирован: Mar 31, 2006 Сообщения: 22 Рейтинг: +0/-0 Откуда: Хохляндия
Добавлено: Чт 26 Окт, 2006 9:55:45 Заголовок сообщения: Не работает событие _StatusCommErr для тегов
Используется RSView32 7.20. На объекте работают 3 равноправные операторские станции, связь по Ethernet. Проект на всех станциях работает один и тот же, только конфигурация Nod'ов в зависимости от конкретной станции меняется. А Нодов сконфигуривано везде 6:
3 Нода для каждой станции - (RSview OPC Tag Server, remote)
и еще три нода для OPC-сервера собственного производства, который на каждой станции связывается с определенными девайсами, тоже remote. Потом на каждой станции (локальной) убирается галочка с Enable в Нодах для RSview OPC Tag Server и OPC-сервер для девайсов делается не remote, а local. По рсвьюшному OPC передаются некоторые внутренние теги (memory), ну а по второму - теги с девайсов.
Проблема в том, что если на какой-то станции перезапускается RSView, или мой OPC-сервер, то на остальных станциях ее данные не подхватываются, они как бы "замораживаюся", (на экранах показыватся последнее значение, которое было до перезапуска).
Я посмотрел в Tag Monitor'е, в момент, когда теряется связь с одной из удаленных станций, статус ее тегов становится "Error".
Поэтому решил обработать эту ситуацию так. Через скрипт VBA регистрирую событие _StatusCommErr для коллекции тегов (пары внутренних тегов с каждой станции и еще пары тегов с девайсов) и по этому событию делаю нехитрую процедуру: деактивирую и тут же активирую соответствующий Node. И все.
Я проверял: если вручную убрать и поставить галку Enable в Node Editor для Node той станции, которая перезапустилась и не подхватывается - через пару секунд значения начинают нормально передаваться. Даже кнопки такие поделал на одном экране с командами "NodeDisable Node1; NodeEnable Node1" как временную меру на случай потери связи. Теперь захотел сделать это в автомате через скрипт, но не выходит: при потере связи теги в Tag Monitor переходят в состояние "error", но процедура моя не активируется почему-то. Как будто не было события StatusCommErr. Текст процедуры привожу ниже:
Код:
Private Sub tConn_Monitor_StatusCommErr(ByVal CommErrTags As RSView32.Tags)
Dim ComErrTag As Tag
For Each ComErrTag In CommErrTags
If gNodes(ComErrTag.NodeName).Enabled = True Then
gNodes(ComErrTag.NodeName).Enabled = False
gNodes(ComErrTag.NodeName).WriteConfiguration
End If
gNodes(ComErrTag.NodeName).Enabled = True
gNodes(ComErrTag.NodeName).WriteConfiguration
Next
End Sub
tConn_Monitor - это коллекция тегов, для которых проверяется состояние связи.
В макрос, который выполняется при запуске проекта, добавил строчку:
Код:
VbaExec ConnMonitorInit
где ConnMonitorInit - процедура, в которой инициализируется коллекция тегов tConn_Monitor:
Код:
Sub ConnMonitorInit()
Dim Tgs As Variant
Dim Tg As Variant
Dim tTags As Tags
Set tTags = New Tags
Tgs = Array("NSMV1\PC_01\Ch_01", "NSMV2\PC_01\Ch_01","NSMV3\PC_01\Ch_01", _
"NSMV1\R_1", "NSMV2\R_1", "NSMV3\R_1")
For Each Tg In Tgs
tTags.Add gTagDb.GetTag(Tg)
Next
Set tConn_Monitor = tTags
End Sub
Коллекция tConn_Monitor объявлена в разделе Declarations->General так:
Я несколько раз прочёл описание проблемы, и ощущение такое, что именно что-то в системе не совсем так построено, как нужно, и нужно делать многие вещи вообще по-другому.
Начать с того, что три станции RSView32 работают в одном сегменте. Уж сколько раз твердили миру, что такие конфигурации не работают или работают медленно или плохо, однако...
Далее, мне никогда не приходило в голову передавать memory-тэги (!) из одной станции RSView в другую. (!). Даже не представляю, зачем это может понадобиться. То, что система построена именно так, говорит о том, что системная концепция выбрана не совсем оптимально.
Что Вы, скажем, будете делать, если выключится компьютер, предоставляющий memory-тэг другому? Какие значения получит в этом случае вторая и/или третья станция? И сколько времени они останутся без информации с выключенного компьютера?
Далее, Ваш самодельный ОРС-сервер: Вы уверены, что он работает корректно? Что он не конфликтует с другими компонентами? Что в системе нет конфликтов? Что сеть не перегружена?
Вы же не написали, какую операцонную систему Вы используете, с каким сервис-паком, и какие версии софта. Может причина кроется вообще в несовместимости версии СPR и версии Windows.
Судя по тому, что Вы пишете, вы уже находитесь в фазе ввода системы в действие. Не знаю, есть ли у Вас возможность и время довольно сильно переделать всё в системе, думаю, что вряд ли. Что посоветовать? Даже не знаю, что в Вашей ситуации и посоветовать. Может быть, учесть этот негативный опыт на будущее?
Начать с того, что три станции RSView32 работают в одном сегменте. Уж сколько раз твердили миру, что такие конфигурации не работают или работают медленно или плохо, однако...
Можно поподробнее, или ссылочку, а то первый раз о таком слышу
Станции эти работают в одном домене, а насчет сегмента, - и не скажу точно, может и в разных. Я сейчас не на объекте, а на память не помню.
Цитата:
Вы же не написали, какую операцонную систему Вы используете, с каким сервис-паком, и какие версии софта. Может причина кроется вообще в несовместимости версии СPR и версии Windows.
Система стоит на всех станциях Windows XP Pro RUS SP2
Что такое CPR?
RSView как я писал выше - RSView32 7.20 на 5 тыс тегов
Цитата:
Далее, мне никогда не приходило в голову передавать memory-тэги (!) из одной станции RSView в другую. (!).
В memory-тэги на каждой станции записывается режим работы насосов (строковая переменная) методом ручного ввода. Этти значения периодически скриптом сохраняются во временные переменные в качестве их значения по умолчанию. И в случае презагрузки проекта или компьютера восстанавливаются при старте проекта из этих значений по умолчанию.
На объекте нет нормальных контроллеров как класса вообще. В целях экономии завод приобрел преобразователи 12-канальные цифровые (ПЦ-12р), каждый из которых собирает данные по 12 каналам, преобразует их и индицирует на своем экранчике. Еще предоставляет доступ к этим данным по RS-485 по протоколу MTM-MODBUS (урезанный MODBUS RTU). Возможно только считывание данных, записывать ничего нельзя.
А вопрос я задавал в основном для того чтобы узнать, работал ли кто реально с событиями для тегов, в частности с _StatusCommErr? Работают ли (отлавливаются нормально) эти события и можно ли их использовать в скрипте VBA для контроля состояния связи?
Попробовал мониторить состояние связи не через VBA и события тегов, а через встроенную функцию RSView comm_err(tagname).
При нарушении связи (тупо выдергиванием шнурка Ethernet или остановкой проекта на удаленной станции) значение comm_err(memory_тег) переходит из 0 в 1.
А когда связь появляется, состояние тега так и остается Error и comm_err(memory_тег) тоже как было равно 1, так и остается 1.
То есть тут проблема не в событии _StatusCommErr, а вообще в механизме, которым RSView восстанавливает связь при ее потере.
А каким образом можно сбросить comm_err(tag)?
Я саму функцию comm_err(tag) и рассматриваю как событие: если она возвращает 1, надо обработать ошибку. Но беда в том, что это событие срабатывает только один раз.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.126 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
