А вот "кино"( с самого включения практически) про отвал модуля
собственно лажает и второй модуль( .20), который в щадящем режиме опрашивается
P.S. а я думал что это он в прошлый раз не помер - ПЛК то в стопе был! А в рабочем режиме стабильно мин за 10 падает.
1. Обмен с периферией через конфигурацию не отключается и в стопе.Сообщение от pt200
А вот "кино"( с самого включения практически) про отвал модуля
собственно лажает и второй модуль( .20), который в щадящем режиме опрашивается
P.S. а я думал что это он в прошлый раз не помер - ПЛК то в стопе был! А в рабочем режиме стабильно мин за 10 падает.
2. В логе я вижу регулярно, 2 подряд запроса от ПЛК к модулю с разрывом 2 мкс! с разными командами и разными №транзакции.
Это очень странно.
Отключите повторы опроса, 2 мастера и пр., увеличьте таймаут ожидания ответа. Добейтесь, чтобы модуль отвечал на тот запрос, который ему шлют без ещё кучи запросов.
Еще раз, ретрансмиты для 485 интерфейса, на TCP они бессмысленны и даже вредны.
А так по логу модуль отвечает в течении единиц мс. Причем есть модуль с IP 20, где обмен настроен нормально.
Теперь обрывы: Ясно видны 2 одновременных потока данных к модулю, создающихся синхронно (разрыв 2 мкс! стабильно, время работы стека IP), причем обращение идут к одному и тому же регистру. Зачем? Только уменьшаете в 2 раза поток обмена. Если хочется проверять - то анализируйте коды ошибок и если есть ошибка - то тогда прочитывайте.
Причем при записи в режиме polling новое значение прилетит, я полагаю, раньше, чем запустится процедура исправления битого пакета, т.е. в режиме polling исправлять ошибки вообще лишено смысла.
Возможно, в таком необычном режиме модуль и может зависнуть, так мы никогда не тестировали, но проверить что он действительно завис просто:
3 теста:
1. разъедините ethernet-кабель на 20 секунд - восстановилось?
2. Перегрузите модуль - восстановилось?
3. Перегрузите программу ПЛК - восстановилось?
Тролль-наседка, добрый, нежный и ласковый
Ваши права
Ответить с цитированием