c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
День добрый. TM 6.05.1, базовая версия. Все аналоговые и дискретные сигналы с контроллера и на контроллер принимаются и отправляются по Modbus TCP/IP.
И всё бы было ничего, да вот только совсем недавно начались страшные тормоза с обменом данными! И сначало было непонятно, что же собственно говоря происходит!
Протанцевав с бубном целый день выяснилось, что при добавлении к какому-то числу входящих каналов Модбаса ещё хотя-бы один входящий канал, происходит следующее:
Все входящие каналы впорядке, реагируют мгновенно. Исходящие (частично, не все) принимают положение достоверности в FALSE (?!) и не могут достучаться до контроллера в течении длительного времени, затем всё таки достукиваются, и снова застревают... в итоге получается что чем больше новых входящих сигналов я добавляю в Источники Modbus, тем больше исходящих становятся недостоверными.
Вопрос: Это ограничение бесплатной версии? Глюк?
Очень обидно, когда проект над которым ТАНЦЕВАЛ 2 месяца вот так вот заходит в тупик. Хелп.
Сообщения / Posts 20 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
А если точнее, то на один новый канал, связанный с источниками/приёмниками приходится один канал, который теряет свою достоверность, причём исходящий.
отправлено / posted
В базовой версии ограничений по использованию драйверов нет. При обмене по Modbus TCP используется полудуплексный режим, поэтому все транзакции (записи и считывания) реализуются и контролируются независимо. При штатной реализации устройствами протокола Modbus TCP указанных Вами коллизий быть не должно. Однако, у нас есть сведения, что в некоторых устройствах существуют отклонения от стандарта, выражающиеся в: - увеличенной задержке ответа на команду записи по сравнению с ответом на команду чтения, - после выдачи длинных ответных кадров на запрос устройство неустойчиво реагирует на следующую команду. Более точную диагностику можно получить с помощью диагностической переменной @e_TCP_ModBus и по сообщениям об ошибках в протоколе профайлера (в релизе 6.06, который сейчас готовится к выпуску, возможности диагностики расширены). Можно предложить (согласно результатам диагностики) попытаться увеличить таймаут на ожидание ответа и уменьшить размер кадров при групповых запросах. Чтобы сократить размер группового запроса, надо нарушить последовательность индексов каналов, запрашивающих последовательные адреса переменных.
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
Так... пробую всё по очереди. Контроллер: WAGO 750-841.
- увеличенной задержке ответа на команду записи по сравнению с ответом на команду чтения
это спорно, ведь до этого всё было впорядке, но я попробую поменять время таймаута
- после выдачи длинных ответных кадров на запрос устройство неустойчиво реагирует на следующую команду
дело в том, что кроме Трейс Мода, контроллер одновременно опрашивает и графическая touch-панель, так вот, проблема с исходящими каналами появляется только в ТМ, ибо с граф панели сигнал о сбросе аварии (например) мгновенно доходит до плк, а на скаде мгновенно отображатеся соответсвующая нота, что были сброшены аварии, НО с трейс мода он отказывается сбрасывать аварии
-Более точную диагностику можно получить с помощью диагностической переменной @e_TCP_ModBus.
При e_TCP_Modbus как Input и Параметре 0:
IN: 0; C2: 255; C3: 255; C4: 255; C5: 255;
Эти значения сохраняются в любом случае, и с достоверными каналами, и при добавлении новых, которые вызывают неисправность
При параметре, установленном в 1.
In: 0; C2: 0; C3: 0; C4: 0; C5: 1, 2, 3, 4, 5 вообщем постоянно увеличивается разница во времени, хотя обмен по сути происходит между входящими и некоторыми исходящими, которые всё же остаются достоверными.
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
"...и по сообщениям об ошибках в протоколе профайлера (в релизе 6.06, который сейчас готовится к выпуску, возможности диагностики расширены)."
Единственную ошибку в протоколе профайлера которую я нашел:
-WRN_DDE:Не удается связать службу диспетчера общих баз данных (DSDM)
Не знаю какова её природа, но вряд ли это связано с данной проблемой :\
Попробовал изменить таймауты узла, и по времени ожидания ответа, и по всему что связано с сетью, даже ставил самые высокие приоритеты потокам Входной IP, Выходной IP, MODBUS, TCP/IP... ничего не помогло.
"Чтобы сократить размер группового запроса, надо нарушить последовательность индексов каналов, запрашивающих последовательные адреса переменных."
А вот тут можно поподробнее, каким образом можно нарушить последовательность индексов каналов?
P.S. Сейчас стабильно 2 исходящий сигнала недостоверны, причём каждый раз разные, смотря что первым отправить. При запуске профайлера, например можно попробовать поменять время старта и стопа вент. установки. Меняется. Но если после этого зайти в управление и сбросить аварию или поменять температуру, то именно эти два канала становятся недостоверными. И наоборот, если при запуске сначала менять температуру, или сбрасывать аварию - работает. Но тогда переменные времени принимают значение FALSE. Что же это за феномены такие?
P.S.S. Релиз 6.06 это конечно круто, но поймите меня правильно, проект нужно продолжать, и на горизонте все входящие и исходящие сигналы придётся умножить на 3, ибо сейчас идёт мониторинг всего лишь одной вент. установки, а их будет как минимум 3.
Сообщения / Posts 20 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Введите системную переменную @DEBUG (HEX, OUT) и задайте ей начальное значение 0x400. В профайлере будут отмечены ошибки сетевого обмена.
2. Групповой запрос создается для строго последовательных переменных Modbus одной функции, если индексы (ID) каналов, которые связаны с этими переменными, возрастают. Например, если переменным Rin_Word(4) с номерами переменных 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 (DEC) будут соответствовать каналы с ID 35, 36, 37, 45, 46, 38, 39, 40, 47, 48, то будут сформированы 2 групповых запроса - для переменных с адресами 1 - 5 и для переменных с адресами 6 - 10.
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
Результат @DEBUG в рамках одной сессии:
INF_RTM:ModBus-OUT Time_Start_In : IP=192.168.1.90 UNIT=2a CMD=4 CH=010e Q=0 INF_RTM:ModBus-OUT Time_Stop_In : IP=192.168.1.90 UNIT=2b CMD=4 CH=010f Q=0 INF_RTM:start time is 0.797 s INF_RTM:ModeSwitch e15=0000 e18=0000 e20=0000 INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 INF_TCP:connect to 192.168.1.90 INF_TCP:connect to 192.168.1.90 INF_TCP:connect to 192.168.1.90 INF_TCP:connect to 192.168.1.90 INF_TCP:connect to 192.168.1.90 INF_TCP:connect to 192.168.1.90 ...
Колличество строчек коннекта возрастает по мере попыток отправки в сеть. А с Rin_Word'ом вы правы, у меня действительно они идут по порядку, так что групповые запросы имеют место быть... у меня уйдёт некоторое время на перепривязку, вот только какие индексы перемешивать: Источников/Приёмников или непосредственно каналов на узле?
Сообщения / Posts 20 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
Вообщем перелопатил все адреса, поудалял половину каналов, создал заного, поперепривязал, ни одна сволочь больше не следует за другой ни по адресу в источниках, ни по ID канала в узле...
отправлено / posted
Изменить индексы каналов Вы не можете. Можно либо изменять настройки компонентов в "Источниках/Приемниках", либо менять привязки каналов.
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Пришлите, пожалуйста, проект на адрес hotline@adastra.ru. И опишите в письме, каким образом вы наблюдаете "недостоверность".
Сообщения / Posts 17114 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
Странно, у меня в исходящих лежит файл на 1.5 мега Сейчас перешлю...
Сообщения / Posts 20 | Из / From: Россия
| IP / IP: IP адрес / IP address |
c0d3m4st3r
Junior Member / Новичок
Участник № / Member № 2970
отправлено / posted
В результате долгой переписки... Отписываюсь тем, кто столкнулся с сабжем.
Всё удалось решить. Я создал тестовый проект, и групповые запросы оказались впорядке.
В самом проекте, я разгруппировал входящие и исходящие источники на 4 сокета, аля 4 "Адресса" 0x01, 0x02... для надежости. Тем самым порезал и групповые, но не до конца, и разгрузил сеть Хорошо что сказали!
Недостоверности оставались, как раз по некоторым групповым запросам, но по крайней мере они уже были статичными, понятными и никогда не менялись, а увеличив таймауты в файлике ip_modbus, по 450 (мс?) и оставив 500 мс на коннекте ВСЁ ЗАМЕЧАТЕЛЬНО заработало.
Т.к. наверное недостоверности появляются как раз появляются по таймаутам сети Впринципе правильно, что приходится увеличивать таймауты, это ведь Ethernet сеть, а не RS485 какая-нить
P.S. Наверное стоит включить в релиз 8.07 возможность отключать групповые запросы, если такие траблы имеют место быть, хотя дело оказалось не совсем в них, а в моих "прямых" руках
Printer-friendly view of this topic
![[Неодобрение / Frown]](frown.gif)
![[Улыбка / Smile]](smile.gif)
![[fun / веселый]](graemlins/fun.gif)
![[clever / умный]](graemlins/clev.gif)
![[master / мастер]](graemlins/master.gif)
![[beer / пиво]](graemlins/beer.gif)
