Нет, пауза между запросами это другое. При опросе раз в 10 сек на нее плевать, а вот при циклическом или раз в 1с это может повлиять.
таймаут у вас бешенный, обычно столько не требуется даже в радио преобразователе RS485 вполне хватало 3с.
Вид для печати
Нет, пауза между запросами это другое. При опросе раз в 10 сек на нее плевать, а вот при циклическом или раз в 1с это может повлиять.
таймаут у вас бешенный, обычно столько не требуется даже в радио преобразователе RS485 вполне хватало 3с.
Не сразу понял про вашу паузу, это время ожидания ответа на запрос, и да у некоторых это действительно пауза называется, в том числе у овеновского OPC
Пробовал разные варианты, от 1 секунды до 5 секунд, наиболее устойчиво работает начиная от 5 секунд, т.е цикл 5 сек и ожидание (пауза) еще 5 секунд
При тестировании сети в разные дни бывает не одного пакета не теряется и ответы на запросы прилетают через 30-80 мс, не пинги узла а именно ответы от ПР205.
А бывает что и 5 секунд не хватает, тогда через таймаут (он тоже настраивается) наш сервак (мастер) срабатывает сессию и запускает пакеты заново.
Добрый вечер
Еще раз настаиваю на проверке закидывания ПР205 пакетами при появлении связи после её потери
Нужна защита от этого, это имеет место быть
Мы выбрали интервал 5 сек и время ожидания 5 сек, но ПР205 и через 100 мс отвечает неплохо, но стоит прервать связь и потом тысячи пакетов недоставленных кладут Пр205 набок и он перезагружается и переменные в памяти обнуляются или съезжают, видимо из за переполнения буфера в памяти отводимого под прием с порта.
Я больше никак не могу объяснить такое поведение, нужно сделать защиту от прилета кучи пакетов
При цикле 5 сек при замирании связи ПР205 видимо как то вывозит прилетающие недоставленные пакеты, но все же иногда перезагружается и всегда при этом я не могу запустить отладку на таких перезагруженных ПР-ах, в них не та программа что в ОЛ, про это я писал неоднократно.
Проблема не решена, увеличив цикл мы вставили костыль, но это не решение
Испытайте все таки уже обмен через интернет а не по локалке.
Вот, можете почитать:
https://mizakona.ru/kak-rabotaet-mex...-svyazi-v-tcp/
я в принципе оказался прав - ПР не вывозит обмен с такой дискретностью
ранее спрашивал - что вам даёт 1 секунда, почему вы "настаиваете" именно на такой частоте опроса
что за высокоскоростные процессы в ИТП происходят, которые надо контролировать, не отводя глаз?
и что у вас за сеть между ПР и АРМ?
интернет у всех разныйЦитата:
Испытайте все таки уже обмен через интернет а не по локалке.
увы я подозреваю, что ответ будет таким - это проблемы в вашей сети. треш-DDOS атака переполняет какой-то буфер? тяните оптику
Инет нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
А интернет он всегда такой будет, я же на всей планете не поменяю провода на оптику!
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит
zakhar81 нет. я не про timeout а именно про паузу сверх timeout...
Короче, запрос - время ожидания ответа - пауза - новый запрос. То есть если в течении отведенного времени (timeout) прибор не ответил, сперва выдерживается пауза и только потом новый запрос. Как-то так.
Еще есть вариант, которым можно поиграться на некоторых системах (RapidScada). У нее есть возможность выставить параметрами разрывать соединение после каждого опроса или оставаться на связи.
На некоторых преобразователях интерфейсов очень помогает, особенно на не очень хорошем интернете.
Интересно, что в ПР205 применили в качестве Ethernet? какой-то преобразователь встроен наверняка, у процессора же нет Ethernet напрямую. Так что возможно тут какие-то коллизии идут
у меня нет ПР205, но при работе с различными устройствами через различные преобразователи замечал потери связи, но вот чтобы устройство перегружалось такого ни разу не видел.
В локалке если работают то и между собой они обмениваются и с мастером и сами если какие девайсы опрашивают то норм.
Проблемы начались именно когда сервак наш в качестве мастера начал их через интернет опрашивать
При этом с памятью у после этого что то происходит, переменки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?
Сейчас подобрали так: 5 секунд цикл, плюс ожидание 5 секунд и перезапуск опроса еще 5 сек (таймаут)
При таком раскладе хотя бы значения переменных в памяти ПР205 не сбрасываются и не съезжают после перезагрузок, но перезагрузки остались, правда не такие частые и без последствий
Есть мысль овен OPC запустить и проверить работу через него, чтобы претензий со стороны ОВЕНа не было в кривости нашего опроса
Но повторюсь, в локалке работает без этих приколов
Рассматривали тоже вариант такой, чтобы следующий запрос отправлялся после получения ответа, но есть одно но, а если мы не дождемся ответа вообще, то что у нас сервак наш мастер может вообще не отправить следующий запрос в какой нибудь момент, если ответа так и не придет. Тоже крайность
Тогда нужно получать ответ что узел не доступен типа как при пинге и принимать решение
Короче в любом случае это изврат какой то
Нужно решать первопричину проблемы
ну так или иначе - ПР не может работать при, в общем-то обычных, коллизиях в сети. Я вот несколько раз писал, про ПЛК110 и СП315, которые также не восстанавливают обмен при каких-то перезапусках/перезагрузках сети/мастера, но все начинали вопить про мои кривые рукиЦитата:
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
это какой-то хардкорнософтовый баг, а не фича, что косвенно и означает, что ПР не вывозит.Цитата:
При этом с памятью у после этого что то происходит, перемнки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?
а какая у вас сетка? что стоит в железе по "длине" сетки? может нужна какая-то хардовая маршрутизация, чтобы обойти "домовые" узлы или делать "VPN" какой-то напрямую?Цитата:
Пинги идут от 20-до 60 мс по сетевому оборудованию
это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, вобщем это всё наводит на мысль что кривость присутствует в методах опроса ПРки, а не в слейвеЦитата:
Сообщение от zakhar81
Для теста пока 6 тэгов накидал из 45-ти для одного из ПР который самый проблемный (с наибольшим количеством регистров относительно других в этом узле), запустил, увидел что примерно в среднем раз в 5-10 минут вот такие виды ошибок уже пролетают:
Неверный id транзакции, в сообщениях всех с таким содержанием id различается на единичку
Ответ устройства не соответствует запросу
Нет ответа от устройства
Пауза ваша в настройках никак не влияет на количество ошибок, остальное все так же, период опроса и время ожидания ответа с количеством попыток
Это оказывается OPC DA а нам бы хотелось UA, работать не получится через него, только тестировать