Тема / Topic: Атрибут "Подключение" для каналов OPC
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Почему для каналов, осуществляющих связь по OPC, не работает атрибут "Подключение"?
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Атрибут Подключение отключает канал от источника данных, но не отключает обмен. Вам нужно использовать атрибут Состояние.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Немного конкретизирую свой вопрос.
Обменом, конечно же, занимается OPC сервер. Для каналов он является источником/приемником данных. Так вот, для входных каналов атрибут подключение работает, т.е. значение замораживается, опрос тега OPC останавливается. Иначе обстоит дело с выходными каналами. Выставляем в 1 Подключение, меняем значение в канале, обмен с OPC продолжается, т.е. тег соответственно меняет свое значение. Получается, что при обмене с OPC сервером атрибут Подключение отключает канал от источника данных, но не делает этого с приемником данных для выходных каналов. А ведь OPC сервер формирует посылку в устройство так же как и в ТМ, т.е. по изменению значения. С чем бы это могло быть связано?
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Приемником данных для выходных каналов с подтипом OPC является OPC сервер. Так вот атрибут Подключение таких каналов не отключает канал от приемника данных . Почему - не понятно. А использовать Состояние нам не удобно, т.к. крутится трансляция.
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
В том то и дело, что приемником не ОРС-сервер является, а внутренний обработчик обмена по ОРС. А зачем Вам Трансляция данных, которых нет?
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Что значит нет данных - данных то как раз полно, ведь входной канал непрерывно опрашивает OPC сервер. Хотя, сейчас, не хотелось бы заниматься описанием задачи - да и не в этом дело. Понятно, что эту проблему можно обойти, но:
Все-таки я никак не пойму, хоть убейте. Пусть приемником данных является внутренний обработчик OPC обмена, но почему канал от него не отключается при выставлении в 1 атрибута Подключение? Разъясните пожалуста. Ведь, например, при использовании выходного канала обмена по Modbus приемником данных также, наверняка, является какой-нибудь внутренний обработчик обмена по modbus (или некий драйвер). Но при выставлении в 1 атрибута Подключение для этого канала - формирование запросов все-таки прекращается. На наш взгляд, похоже, что это нарушения идеологии: на одних каналах Подключение работает, на других - не работает.
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Для ОРС - Подключение не отключает сам обмен, а лишь отключает канал от внутреннего источника ОРС.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
К сожалению, опять ничего не понял. Попробую задать вопрос так: 1. Есть входной канал, привязанный к OPC тегу. Если выставить в 1 Подключение, увидим ли мы изменение значения канала при изменении значения тега? 2. Есть выходной канал, привязанный к OPC тегу. Если выставить в 1 Подключение, увидим ли мы изменение значения тега при изменении значения канала?
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Наконец-то! В том то и дело, что: 1) нет 2) да В этом то и вопрос: почему в случае 2)да?
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Наконец-то проверили!
Видимо как следствие этого и не работает установка на резервном МРВ 5-го бита канала Системный Ввод-вывод, т.е. теги OPC продолжают обновляться.
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ATMosphere
Forum Member / Участник форума
Участник № / Member № 115
отправлено / posted
Добрый день!
Разрешите поинтересоваться, сделано ли что-нибудь для устранения озвученных выше ошибок. Когда можно ожидать исправлений?
Сообщения / Posts 45 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
В связи с подготовкой выхода 6-й версии - все работы по 5-й пока временно приостановлены на неопределенный срок. Ориентировочно - середина августа, но это только "ориентировочно", возможно, что и этот срок будет перенесен... Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
В продолжение темы - имею похожую проблему, но со своими нюансами, а именно: 1. Есть OPC - сервер счетчиков Логика, которые опрашиваются достаточно медленно. 2. Есть две задачи, одна из которых ТМ5, которые являются OPC-клиентами, причем ТМ5 - DA, а другая задача - HDA. 3. Для того, чтобы задачи не мешали друг другу, каналы в режиме DA нужно опрашивать не чаще раза в минуту - этого можно добиться, если OPC-клиент при подключении создаст на OPC-сервере группу с соответствующим периодом.
В результате оказывается, что ТМ5 создаёт на OPC-сервере группу с периодом узла (задаем 1 мин), вследствие чего скорость реакции на действия оператора становится неприемлимой.
Видится два пути выхода из кризиса (первый очень желателен): 1. Заставить ТМ создавать на OPC-сервере группу с заданным периодом, не зависящим от периода узла (лучше всего в файле конфигурации node_opcN.cnf). 2. Периодически отключаться от OPC-сервера, чтобы позволить другому клиенту получить свои данные.
отправлено / posted
В Трейс Моуд 5 пока не планируется производить работы по усовершенствованию ее характеристик и расширению функций. В качестве альтернативы можно предложить запрашивать данные у OPC-сервера в режиме ADVISE. При этом OPC-сервер вообще самостоятельно решает вопрос реализации потоков ответов. Сколько успевает послать клиенту (Трейс Моуд), столько и пошлет. Встречный вопрос. Какими средствами Вы контролируете OPC-обмен? Существуют ли у Вас программные средства для трассировки OPC-обмена, как локального, так и сетевого? Если да, перешлите их нам, пожалуйста, на адрес техподдержки (если возможно).
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Kramarenko Stanislav
Forum Professor / Завсегдатай форума
Участник № / Member № 119
отправлено / posted
OPC я не диагностирую. В данной ситуации от режима OPC ничего не зависит - проверено. Когда клиент подключается, то независимо от режима группа на сервере создаётся, а при создании всегда указывается её период.
Сервер сделан так, что опрашивает устройства с периодом группы, заведенной на нем, а он должен это делать значительно реже.
отправлено / posted
Максимальный период для OPC-группы наш клиент может установить только 1 секунда (если для каналовзадать период опроса в секундах). Параметр этот задан в коде. Переписывать клиента для Трейс Моуд 5 мы не планируем.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[duno / незнайка]](graemlins/duno.gif)
