ПР205

Цитата:

---

Сообщение от Dimensy

Не, ну я читал, что на кофеварке запускали Doom, но давайте, все таки, отделять мухи и котлеты. ПР предназначены для малых задач автоматизации и никогда не станут в ровень с ПЛК - задачи и цена разные. А то что вы хотите микросекунды ловить на ПР - у вас, что там, система управления реального времени? Нужны микросекунды, многопотоковость и прерывания - берите ПЛК

---

>> ПР предназначены для малых задач автоматизации и никогда не станут в ровень с ПЛК

Хи-хи. :)

Мне в 10 лет, купили велосипед взрослый.
А по вашему нужен детский.


Так кто не дорос?

1. Кому купили.
2. Велосипед плохой.
3. Вы.


Подрастайте! :)

Цитата:

---

Сообщение от zakhar81

Вот, можете почитать:
https://mizakona.ru/kak-rabotaet-mex...-svyazi-v-tcp/
В нашем случе и у Павля с овен облаком я думаю те же грабли происходят

---

Я разобрался.

Облако тупо молотит по своему таймингу.

Пришлось подстроиться мне под алгоритм облака.

Цитата:

---

Сообщение от zakhar81

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

---

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

Код:

---

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

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

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


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

---

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

Цитата:

---

Сообщение от ПавелП

>> ПР предназначены для малых задач автоматизации и никогда не станут в ровень с ПЛК

Хи-хи. :)

Мне в 10 лет, купили велосипед взрослый.
А по вашему нужен детский.


Так кто не дорос?

1. Кому купили.
2. Велосипед плохой.
3. Вы.


Подрастайте! :)

---

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

Цитата:

---

Сообщение от Dimensy

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

---

Вы не правы.

Я под рамой может с неделю катался, в потом...
А потом я начал "расти" - ездил как взрослый,
доставая по очереди педали.

И за лето хорошо подрос.

Не спорьте.
У этой железяки (ПР205) есть ресурс, и его надо вытянуть.
Главное, чтоб окружение отчаянно не тормозило...

Цитата:

---

Сообщение от ПавелП

Вы не правы.

Я под рамой может с неделю катался, в потом...
А потом я начал "расти" - ездил как взрослый,
доставая по очереди педали.

И за лето хорошо подрос.

Не спорьте.
У этой железяки (ПР205) есть ресурс, и его надо вытянуть.
Главное, чтоб окружение отчаянно не тормозило...

---

Я в первый день как научился натер себе...

Цитата:

---

Сообщение от МихаилГл

Я в первый день как научился натер себе...

---

Вы неправильно используете ПР205... :(

Цитата:

---

Сообщение от ПавелП

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

Код:

---

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

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

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


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

---

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

---

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

Цитата:

---

Сообщение от zakhar81

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

---

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

ЗЫ вот же

Цитата:

---

Сообщение от zakhar81

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

---

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

Так еще и сам механизм передачи TCP предусматривает гарантированную доставку пакетов, и вот если ответ не пришел мастеру ModBusTCP через время ожидания/паузу которые в настройках то мастер посылает следующий запрос. Таким образом, если пакеты на которые не было ответа "застряли" в буферах сетевого оборудования то вот этот механизм обеспечит их доставку как только разгрузка произойдет по траффику и на ПР они могут потом прилететь все сразу