ПР205

[ПавелП]

Добрый вечер
В моей теме все разбежались
Еще раз настаиваю на проверке закидывания ПР205 пакетами при появлении связи после её потери
Нужна защита от этого, это имеет место быть
Мы выбрали интервал 5 сек и время ожидания 5 сек, но ПР205 и через 100 мс отвечает неплохо, но стоит прервать связь и потом тысячи пакетов недоставленных кладут Пр205 набок и он перезагружается и переменные в памяти обнуляются или съезжают, видимо из за переполнения буфера в памяти отводимого под прием с порта.
Я больше никак не могу объяснить такое поведение, нужно сделать защиту от прилета кучи пакетов
При цикле 5 сек при замирании связи ПР205 видимо как то вывозит прилетающие недоставленные пакеты, но все же иногда перезагружается и всегда при этом я не могу запустить отладку на таких перезагруженных ПР-ах, в них не та программа что в ОЛ, про это я писал неоднократно.
Проблема не решена, увеличив цикл мы вставили костыль, но это не решение
Испытайте все таки уже обмен через интернет а не по локалке.

Я ещё тогда призадумался, и порылся в документации.

F1\Настройка прибора\Обмен по сети\Modbus\Работа по протоколу Modbus

Автоподстройка времени цикла программы   

Приборы могут подстраивать время работы цикла программы в зависимости от сложности алгоритма.
Автоподстройка времени цикла программы влияет на работу интерфейса связи,
так как запросы обрабатываются в оставшееся после выполнения программы время цикла.


Согласно алгоритму подстройки времени цикла, минимальное число вызовов Master составляет до 50 раз в секунду.
Если Master не успевает опросить все устройства, то необходимо внести изменения в алгоритм для оптимизации количества запросов.

Где-то тут собака порылась.
Происходит "нахлёст" по времени.
Меняйте алгоритм.

[zakhar81]

Я ещё тогда призадумался, и порылся в документации.

F1\Настройка прибора\Обмен по сети\Modbus\Работа по протоколу Modbus

Автоподстройка времени цикла программы   

Приборы могут подстраивать время работы цикла программы в зависимости от сложности алгоритма.
Автоподстройка времени цикла программы влияет на работу интерфейса связи,
так как запросы обрабатываются в оставшееся после выполнения программы время цикла.


Согласно алгоритму подстройки времени цикла, минимальное число вызовов Master составляет до 50 раз в секунду.
Если Master не успевает опросить все устройства, то необходимо внести изменения в алгоритм для оптимизации количества запросов.

Где-то тут собака порылась.
Происходит "нахлёст" по времени.
Меняйте алгоритм.

Тестировал Инет, он там нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит
Я не могу за овен разбираться что происходит с буфером приемным (программным и физическим) если прилетает огромное количество пакетов TCP
Инет нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
А интернет он всегда такой будет и сетевое оборудование может перезагружаться или отваливаться кратковременно и периодически, раз два в сутки
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит

[capzap]

Тестировал Инет, он там нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит
Я не могу за овен разбираться что происходит с буфером приемным (программным и физическим) если прилетает огромное количество пакетов TCP
Инет нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
А интернет он всегда такой будет и сетевое оборудование может перезагружаться или отваливаться кратковременно и периодически, раз два в сутки
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит

Модбас сам по себе протокол запросов и ответов, зачем слать очередной запрос если не пришел ответ на предыдущий запрос, откуда куча пакетов может быть если по идее мастер должен на первом не отвеченном запросе остановится

ЗЫ вот же

Конечно позволяет, таймаут это максимальное время ожидания ответа, после которого ожидание ответа заканчивается и выставляется флаг ошибки, у меня он 15 сек, а цикл опроса 10 сек он же и есть пауза между запросами

если срабатывание таймаута позже чем частота запросов то мастер ни когда не обнаружит что данные не дошли до слейва, таймаут должен быть меньше напроцетов 10 чтоб программа успела обарботать ошибку и принять по ней решение, а не послать в этом же цикле очередной запрос сбросив счетчик таймаута

[zakhar81]

Модбас сам по себе протокол запросов и ответов, зачем слать очередной запрос если не пришел ответ на предыдущий запрос, откуда куча пакетов может быть если по идее мастер должен на первом не отвеченном запросе остановится

ЗЫ вот же


если срабатывание таймаута позже чем частота запросов то мастер ни когда не обнаружит что данные не дошли до слейва, таймаут должен быть меньше на процентов 10 чтоб программа успела обработать ошибку и принять по ней решение, а не послать в этом же цикле очередной запрос сбросив счетчик таймаута

Сейчас так
5 секунд цикл
Ожидание еще 5 сек или пауза у некоторых называется, потом сброс и дальше поехали
Таким образом при просадке скорости или связи после ёё восстановления уже не такое большое число пакетов долетает до ПР и более менее стабильно себя ведет, иногда ресетится но в памяти хотя бы переменные не съезжают
При этом после ресета один фиг подключиться с отладкой невозможно, ОЛ пишет что программа в приборе отличается от той что в ОЛ, что происходит с ним фиг знает
Поэтому нужно устранять, так работать не возможно

[capzap]

Сейчас так
5 секунд цикл
Ожидание еще 5 сек или пауза у некоторых называется, потом сброс и дальше поехали
Таким образом при просадке скорости или связи после ёё восстановления уже не такое большое число пакетов долетает до ПР и более менее стабильно себя ведет, иногда ресетится но в памяти хотя бы переменные не съезжают
При этом после ресета один фиг подключиться с отладкой невозможно, ОЛ пишет что программа в приборе отличается от той что в ОЛ, что происходит с ним фиг знает
Поэтому нужно устранять, так работать не возможно

Если Вы с терминами не разобрались, просто выкладывайте лог обмена и станет все понятно, где есть ответы на запросы, а где не дождавшись ответа сыпется очередной запрос, по времени сразу станет ясно какой там аут подойдёт для настроек мастера