Показать сообщение отдельно
Старый 14.06.2018, 19:09   #16
Grigor
Новичок
 
Регистрация: May 2018
Сообщения: 7
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
По умолчанию Ответ: Trace Mode ошибка 10054.

Цитата
Сообщение от Max2114 Посмотреть сообщение
Обратитесь в Адастру (не на форум а конкретно по телефону в техподдержку).
Хотя я сомневаюсь что вопрос решили. Лучше сразу запланировать докупить MAsterOPC... он стоит не дорого, работает надежно. Можно даже при желании реализовывать нестандарнтые протоколы связи путем написания скриптов (не раз уже выручала эта возможность).
OPC-сервер - это конечно выход из ситуации, но он похож на костыль... Любая нормальная СКАДА должна уметь работать с устройствами по протоколу Модбас, используя встроенный драйвер.

Недавно на столе появился Pixel 25xx и мне удалось потестировать опрос контроллера через Мастер OPC и Trace Mode (следил вайршарком).
Выяснил следующие моменты отражение которых в явном виде не увидел ни в данном топике, ни на форуме Адастры:
- Пиксель закрывает соединение в случае отсутствия запросов от СКАДЫ не через 3 секунды как указано выше, а через полторы (о чем производитель сообщает на 32 странице РЭ SGN.312005.05РЭ);
- В случае закрытия сокета Пиксель направляет TCP пакет, в котором есть соответствующие флаги (RST,ACK). Мастер OPC в случае появления данного пакета следующий запрос начинает с открытия сокета. Trace Mode данный TCP пакет игнорирует, что приводит к нескольким попыткам запросить информацию (это отслеживается по внутренним логам трейсмода, однако, вайршарк показывает, что при этом в сеть запросы не идут), а также выжиданию таймаута на переподключение, который по умолчанию в Trace Mode равен 30 с. Затем Трейс Мод открывает сокет и направляет запрос.

Направил в АдАстру свои наблюдения касательно реакции СКАДА-системы на сообщения о закрытии удаленного сокета, надеюсь что разработчики добавят в СКАДУ механизм аналогичный тому, что используется в Мастер OPC.

Пока со стороны Технической поддержки следующие рекомендации для улучшения ситуации:
- можно использовать конфигурационный ключ «TCP_DIFCONN09=1» , а также «TCP_DISCONN09=1». Первый из них уберет 30-ти секундный таймаут на переподключение. Второй ключ вроде как тоже нужен, но сколько не эксперементировал его суть уловить не смог… У меня с данным ключами в случае закрытия контроллером сокета очередные данные приходят через 4 цикла обработки канала в Trace Mode;
- по умолчанию в Trace Mode все Modbus-TCP устройства опрашиваются в одном потоке, соответсвенно чем больше устройств, тем больше может оказаться пауза между запросами. Однако есть возможность конфигурационными ключами разнести устройства на 16 потоков, что значительно улучшит динамику;
- Чтобы сократить число запросов нужно использовать групповые модбас-запросы, поддержка которых есть как в трэйс мод так и в Пикселе. Модбас карта адресов в Пикселе в этом плане очень хороша!
- Каналы Trace Mode которые выполняют опрос обрабатываются в порядке возрастания их ID. Предлагается создавать каналы таким образом, чтобы не сразу вытаскивать все данные с одного контроллера в сети, а по частям. Сначала опросить часть адресов на первом контроллере, потом - часть на втором, затем опять вернуться к первому и т.д. То есть не засиживаться долго на опросе одного контроллера. На мой взгляд решение рабочее, но реализация будет не простой т.к. ID канала после создания уже не поменяешь.


Добавлено через 2 минуты

Возможно ли добавить функцию изменения таймаута закрытия сокета для сетевого адаптера Pixel? Видел похожую опцию в контроллерах Wago
Grigor вне форума   Ответить с цитированием