Просмотр полной версии : ПР205 Зависания и перезагрузки каждые сутки
zakhar81
09.01.2024, 04:29
ПР205 зависают и/или перезагружаются каждые сутки - двое
Вот тема где этот вопрос изначально обсуждался:https://owen.ru/forum/showthread.php?t=38746&page=4
Сначала были просто перезагрузки которые не напрягали, но проблема была в исчезновении значений переменных или их подмены на значения котрые например были в прошлой прошивке или на соседние по списку!
После проделанных экспериментов с переменными и макросами пришли к выводу что проблема сама по себе не в этом а в чем то другом, так как в последнее время зависания участились и ПР205 уже перестали перезагружаться
Я уже боюсь предположить что у них что то с памятью происходит и ситуация ухудшается со временем
Предполагаю что ПР205 не вывозит обмена через Modbus TCP в качестве слэйва, т.е. сервера, плюс что то с памятью еще.
Так как те ПР205, что менее нагружены обменом и у которых список сетевых переменок мал те дольше работают без зависания и перезагрузок, а у тех что имеют списки сетевых раз в 5 и более у тех продолжительность работы не более суток, у одного у которого самый большой список не более суток и потом висяк!
Отключить их от обмена нельзя с внешним сервером, поскольку там жилые дома и это управление их ИТП по погоде,
Частота опроса у всех одинаковая не чаще 1 сек, запросы групповые, не по одному регистру.
При этом одна группа на чтение, другая на запись, а запись только при изменении
И вот в некоторых случаях, как раз после запросов на запись происходит перезагрузка, а зависание иногда происходит после прошествии 1-2 суток, потом идет электрик и тупо перезагружает все, так как подключиться уже к ПР205 невозможно, он отваливается или вовсе не отвечает.
Даже в нормальном режиме когда по сети их все из ОЛ пытаешься мониторить в онлайн отладке и то периодически отваливаются, а те что с большим списком сетевых вообще мигает коннект/дисконнект каждые 3- секунд, это явно косяк
Пробовал гасить сервак, мониторил связь с ПР205-ми, да чуть лучше связь была, видимо снимает часть нагрузки, но все равно разрывы.
В локалке тоже связь теряется и при отключенном и при включенном сервере, хотя чуть лучше чем через WAN.
При попытке подключения к некоторым ПР205 которые уже явно подвисли для онлайн отладки из ОЛ видим вот это: https://owen.ru/forum/attachment.php?attachmentid=72776&d=1704450136
Переменки правда остаются вроде бы те что из энергонезависимых, не те что были введены последними, но при этом при попытке отладки пишет что программа не та залита
А вот скриншот из овен конфигуратора, при попытке подключиться к таким подвисшим ПР205: https://owen.ru/forum/attachment.php?attachmentid=72775&d=1704442720
Т.е. проблема системная и мы очень ждем её решения от Вас
С нас неустойку уже пытаются удержать из за этих косяков, ситуация печальная.
zakhar81
09.01.2024, 04:37
Проекты посылали к вам на почту, если нужно можем еще раз все 6 выслать
Один из ПР205 доступен для проверки через WAN со штатным 502 портом, в письме тоже дали информацию с IP для подключения и проверок если нужно
Другие ПР205 на другом адресе, но там маршрутизацию через другие порты сделали и чтобы подключиться из ОЛ нужно сначала на роутере настройки поменять потом подключаться
Тимур Назарбоев
09.01.2024, 10:20
Проекты посылали к вам на почту, если нужно можем еще раз все 6 выслать
Один из ПР205 доступен для проверки через WAN со штатным 502 портом, в письме тоже дали информацию с IP для подключения и проверок если нужно
Другие ПР205 на другом адресе, но там маршрутизацию через другие порты сделали и чтобы подключиться из ОЛ нужно сначала на роутере настройки поменять потом подключаться
Добрый день, если вы направляли проекты , то можете ожидать ответа по почте в течении некоторого времени. Если ответа долго не будет, то можете повторно выслать ваш запрос.
zakhar81
10.01.2024, 10:43
Решение проблемы выходит за рамки наших проектов, и ответом я думаю должна быть следующая системная прошивка ПР205 без глюков в работе - зависаний и перезагрузок
Я думаю Вы понимаете о чем идет речь
zakhar81
17.01.2024, 17:59
Уважаемые господа разработчики добрый вечер!
Новая версия 2.5.343 она не про нас?
Удалось воспроизвести хоть что то из того что мы описывали?
Это бесполезно! Глюков в оборудовании ОВЕН очень много. Кризис ...
Я сам год назад бился с новым ПЛК110-60:
если проект сразу сделать загрузочным, после сброса все работает
при попытке залить как обычно, зависает напрочь (хоть как - через USB, RS232, Ethernet)
zakhar81
18.01.2024, 11:21
Так так, что значит загрузочным сделать?
Подскажите пожалуйста что вы имели ввиду
zakhar81 в данном случае речь не о ПР про загрузочный проект, а о ПЛК.
С нас неустойку уже пытаются удержать из за этих косяков, ситуация печальная.
так а зачем использовать не доведенный по сути до ума прибор на таких объектах.
Его еще года 2 в чувство приводит будут, как минимум.
так а зачем использовать не доведенный по сути до ума прибор на таких объектах.
Его еще года 2 в чувство приводит будут, как минимум.
Это понятно, но ОВЕНы его ведь не бесплатно распространяют, я думаю? Я и сам бы хотел ПР205 поиспользовать, но почитаю вот такие отзывы и жду дальше.
zakhar81
18.01.2024, 12:41
У нас и на этот год уже они заложены в проектах
Я боюсь теперь делать с поставкой в отдаленные уголки нашей необъятной
Нужно что то решать
zakhar81
18.01.2024, 12:46
Есть подозрение что вешает его внешний обмен, но клиентов то 2, соседний ПР205 и внешний сервер
Внешний сервер отключить не можем, поскольку потеряем вообще контроль за состоянием и вовремя не увидим когда все колом встает
Он запросы раз в 1 сек посылает и у того контроллера что каждые сутки в перезагруз уходит со слетом переменных и автозагрузкой не пойми какой программы (так как я писал ранее что после таких перезагрузок при попытке подключиться с онлайн отладкой ОЛ выдает сюрприз - программа в приборе не соответствует той что я открыл) у него список переменных больше чем у всех остальных
Для остальных такой глюк только позже по времени ну или не с той частотой, раз в трое суток или в пять
У меня подозрение что при формировании в памяти STM32 неких стеков/буферов для обмена ModBus TCP происходит переполнение и наезд на соседние адреса где переменки, тем самым происходит то что происходит со всеми вытекающими
Вообще может такое несоответствие быть если в рабочей программе только переменные поменялись или обнулились после перезагрузки?
С другой стороны если сам его перезагружаю по питанию например или переменные меняю с экрана то онлайн отладка не выдает таких сообщений о несоответствии
В данном случае что то с памятью происходит или еще какие то изменения не только в области переменных
Это понятно, но ОВЕНы его ведь не бесплатно распространяют, я думаю? Я и сам бы хотел ПР205 поиспользовать, но почитаю вот такие отзывы и жду дальше.
Да здесь основной вопрос не в косяке Овена, а в том что они установлены на ИТП многоквартирных домов т.е в данной ситуации, заложниками принятого решения (установки сырого контролера) становится люди живущий там (и думается это не 10, и даже не 100 человек)
А они - с нас деньги пытаются снять, за косяки, решение проблемы выходят за рамки наших проектов и т.е.
In_Da_Cher_A
18.01.2024, 13:12
Внешний сервер ....запросы раз в 1 сек посылаетне слишком часто? что там такого надо мониторить, чтобы в диспетчерской раз в секунду видеть параметры теплосети в ИТП?
уменьшайте частоту, ваша АСУ ТП явно не вывозит весь этот объём, и ПР всё-таки это не ПЛК, вам надо разделять функции, которые навалили на ПР - управление ИТП это одно, а сбор данных с других ИТП и обмен с сервером - это другое
In_Da_Cher_A
18.01.2024, 13:18
поскольку потеряем вообще контроль за состоянием и вовремя не увидим когда все колом встаетчто вам даст, что всё встало в 12 часов 43 минуты 26 секунд или просто в 12:44?
вам надо разделять функции, которые навалили на ПР - управление ИТП это одно, а сбор данных с других ИТП и обмен с сервером - это другое
А зачем им показывать то что и так вроде на поверхности лежит. Ведь изначально виноват Овен
Решение проблемы выходит за рамки наших проектов, и ответом я думаю должна быть следующая системная прошивка ПР205 без глюков в работе - зависаний и перезагрузок
Я думаю Вы понимаете о чем идет речь
In_Da_Cher_A
18.01.2024, 13:57
А зачем им показывать то что и так вроде на поверхности лежит. Ведь изначально виноват Овеня про то, как сейчас облегчить положение, тем более - когда сейчас всё внимание у всех приковано к теплоснабжению в городах.
То, что у ОВЕН есть проблемы, это мало им поможет в устранении зависания, и договорными проблемами
Никто в ОВЕН не парится, что у тебя что-то зависло, и не пашет 24х7 надо новой прошивкой
сейчас надо оперативно принимать меры по снижению зависания, а это лечится только снижением частоты и разгрузкой программы и конфигурации, я бы вообще сейчас подкинул вместо самого проблемного ПР какой-нибудь ПЛК, пока не закончится отопительный сезон
я про то, как сейчас облегчить положение, тем более - когда сейчас всё внимание у всех приковано к теплоснабжению в городах.
То, что у ОВЕН есть проблемы, это мало им поможет в устранении зависания, и договорными проблемами
Никто в ОВЕН не парится, что у тебя что-то зависло, и не пашет 24х7 надо новой прошивкой
сейчас надо оперативно принимать меры по снижению зависания, а это лечится только снижением частоты и разгрузкой программы и конфигурации, я бы вообще сейчас подкинул вместо самого проблемного ПР какой-нибудь ПЛК, пока не закончится отопительный сезон
Если бы они это просили, народ-люди мерзнут, может где косяк, вот и так у нас сделано - думаете тут на форуме не помогли бы. А им больше нужен ответ от Овена, что проблема есть, они распечатали бы его, и всем показывали - видите мы хорошие, а это все Овен.
ну стоит все таки открыть РЭ на прибор и прочитать там черным по белому, что Овен не несет ответственности. Вроде раньше это было в документации или похожие слова...
ну стоит все таки открыть РЭ на прибор и прочитать там черным по белому, что Овен не несет ответственности. Вроде раньше это было в документации или похожие слова...
Согласен, но это слова для разбора уже после так скажем полета. А до этого все средства хороши)))
In_Da_Cher_A
18.01.2024, 14:22
А им больше нужен ответ от Овена, что проблема есть, они распечатали бы его, и всем показывали - видите мы хорошие, а это все Овен.это не прокатит, когда им выставят претензии по договору, где ОВЕН не значится никак и никаким боком его не прислонишь как виновника проблемы
здесь, имхо, скорее вина ОВЕН в том, что начинают из ПР делать эконом-ПЛК, и под радостные вопли выкатывают приблуды типа вот вам ST, потом Ethernet, потом цветной дисплей
в результате народ радостно хватает прибор и грузит ПР как самосвал, хотя больше садовой тачки туда не влезает
а потом стоны про зависания, про глюки и прочие приколы нашего городка
не удивлюсь пресловутому переключателю Старт/Стоп и внедрению какого-нибудь параметра button чтобы местные кочегары не тыркали переключатель :)
это не прокатит, когда им выставят претензии по договору, где ОВЕН не значится никак и никаким боком его не прислонишь как виновника проблемы
С нас неустойку уже пытаются удержать из за этих косяков, ситуация печальная.
Но если показать бумажку, где Овен подтверждает что есть проблема - адекватный заказчик вполне возможно сменить гнев на милость.
вот вам ST, потом Ethernet, потом цветной дисплей
Попытку Овена сделать конфетку можно только приветствовать.
в результате народ радостно хватает прибор и грузит ПР как самосвал, хотя больше садовой тачки туда не влезает
а потом стоны про зависания, про глюки и прочие приколы нашего городка
Но тут больше проблема в квалификации исполнителя - у нас счас как, посмотрел вебинар - вход выход соединил, светодиодом поморгал, привет мир написал - все, программист АСУТП, инженер КИПиА - нужное подчеркнуть.
Но если показать бумажку, где Овен подтверждает что есть проблема - адекватный заказчик вполне возможно сменить гнев на милость.
Не соглашусь. Ответственность за выбор комплектующих на проектировщике. Если только в ТЗ не прописана конкретное изделие.
Не соглашусь. Ответственность за выбор комплектующих на проектировщике. Если только в ТЗ не прописана конкретное изделие.
А проектировщик машет РЭ от Овена, где говориться что он так может работать.
Есть подозрение что вешает его внешний обмен, но клиентов то 2, соседний ПР205 и внешний сервер
Внешний сервер отключить не можем, поскольку потеряем вообще контроль за состоянием и вовремя не увидим когда все колом встает
Он запросы раз в 1 сек посылает и у того контроллера что каждые сутки в перезагруз уходит со слетом переменных и автозагрузкой не пойми какой программы (так как я писал ранее что после таких перезагрузок при попытке подключиться с онлайн отладкой ОЛ выдает сюрприз - программа в приборе не соответствует той что я открыл) у него список переменных больше чем у всех остальных
Для остальных такой глюк только позже по времени ну или не с той частотой, раз в трое суток или в пять
У меня подозрение что при формировании в памяти STM32 неких стеков/буферов для обмена ModBus TCP происходит переполнение и наезд на соседние адреса где переменки, тем самым происходит то что происходит со всеми вытекающими
Вообще может такое несоответствие быть если в рабочей программе только переменные поменялись или обнулились после перезагрузки?
С другой стороны если сам его перезагружаю по питанию например или переменные меняю с экрана то онлайн отладка не выдает таких сообщений о несоответствии
В данном случае что то с памятью происходит или еще какие то изменения не только в области переменных
А может все гораздо проще. Может сбои в работе ПР205 происходят из за электромагнитных помех или скачков напряжения в питающей сети. Вы бы схему шкафа с ПР205 выложили.
В РЭ на 205 есть предупреждения, что нельзя питать некоторые цепи от одного БП. Вчера смотрел web версию.... посмотрите внимательнее в эту сторону.
Mix4lich
19.01.2024, 10:22
У меня ситуация не с перезагрузками,ПР205 просто не загружается,после заливки программы.Моргает красным диодом и все.Причем явной причины не удалось выявить,проект который минуту назад работал как положено,после минимальных изменений,мог уже завесить ПР.Наткнувшись на эту тему,решил для пробы уменьшить количество Сетевых переменных.Удалил одну,проект заливается,ПР стартует.Возвращаю - зависание при загрузке.НО! Вчера этот проект работал без проблем,со всеми переменными.По проекту -ПР205 читает по Modbus RTU показания прибора и передает данные дальше,уже по Modbus TCP.Все.Входящих значений 15,исходящих так же.
In_Da_Cher_A
19.01.2024, 11:46
Вчера этот проект работал без проблем,со всеми переменными.вчера Венера была в Стрельце
читает по Modbus RTU показания прибора и передает данные дальше,уже по Modbus TCPРТУ мастер, а ТСР - слейв?
чисто из интереса - не проще было конвертер интерфейса поставить, какуюнибудь Моху? и уже обрабатывать на верхней стороне?
Mix4lich
19.01.2024, 11:53
вчера Венера была в Стрельце
РТУ мастер, а ТСР - слейв?
чисто из интереса - не проще было конвертер интерфейса поставить, какуюнибудь Моху? и уже обрабатывать на верхней стороне?
Звучит бредово,но говорю как есть.
In_Da_Cher_A
19.01.2024, 11:53
Но если показать бумажку, где Овен подтверждает что есть проблема ОВЕН никогда не напишет - вон в соседней ветке народ стонет, в обновах ОЛ отлетели термосопротивления, отзывы обновлений и прочие приколы - ОВЕН не несёт ответственности за твои проблемы
Попытку Овена сделать конфетку можно только приветствовать.но похоже только боком всё вышло. 205 откровенно глючный продукт, в проекты это ставить только после обкатки всего-всего на стенде
In_Da_Cher_A
19.01.2024, 11:57
Может сбои в работе ПР205 происходят из за электромагнитных помех или скачков напряжения в питающей сети. Вы бы схему шкафа с ПР205 выложили.вот да, крайне интересно как схема собрана и от чего питается
где-то по осени была тема, где какая-то ПР стояла в шкафу с частотниками и тоже глючило, не помню чем закончилось
ОВЕН никогда не напишет - вон в соседней ветке народ стонет, в обновах ОЛ отлетели термосопротивления, отзывы обновлений и прочие приколы - ОВЕН не несёт ответственности за твои проблемы
Но опять же пользователи сам лезут вперед паровоза, на кой спрашивается обновлять, если по сути это бета. Что Овен под пушкой заставляет? Нарушают первое правило: работает - не тронь!!!
In_Da_Cher_A
19.01.2024, 14:04
Но опять же пользователи сам лезут вперед паровоза, на кой спрашивается обновлять, если по сути это бета. Что Овен под пушкой заставляет? Нарушают первое правило: работает - не тронь!!!так ОЛ сам ищет обнову и подсовывает тебе установку, ты же не знаешь, бета это или рабочая альфа, кто не вникает во всю кухню с ОЛ или недавно - тот жмёт Да и влетает в головняк на ровном месте
zakhar81
22.01.2024, 05:14
Это бесполезно! Глюков в оборудовании ОВЕН очень много. Кризис ...
Я сам год назад бился с новым ПЛК110-60:
если проект сразу сделать загрузочным, после сброса все работает
при попытке залить как обычно, зависает напрочь (хоть как - через USB, RS232, Ethernet)
Да, ошибся, не разглядел перепутал с ПР110
Есть проекты с ПЛК210+Мастерскада-3 на котлы тэц, а на ПЛК100 не работал, есть китайцы аналогичные в 3-4 раз дешевле и без глюков
Все по задачам определяется
zakhar81
22.01.2024, 05:29
У меня ситуация не с перезагрузками,ПР205 просто не загружается,после заливки программы.Моргает красным диодом и все.Причем явной причины не удалось выявить,проект который минуту назад работал как положено,после минимальных изменений,мог уже завесить ПР.Наткнувшись на эту тему,решил для пробы уменьшить количество Сетевых переменных.Удалил одну,проект заливается,ПР стартует.Возвращаю - зависание при загрузке.НО! Вчера этот проект работал без проблем,со всеми переменными.По проекту -ПР205 читает по Modbus RTU показания прибора и передает данные дальше,уже по Modbus TCP.Все.Входящих значений 15,исходящих так же.
Добрый день
Вот давайте тестировать вместе!
Овен просто залил мой проект и оставил на 3 дня и ни каких перезагрузок, я у себя тоже самое сделал тоже все ок
Поэтому нужно тестировать сетевой обмен, нагружать и тестировать
Обмен не через порт RS485 а а через Ethernet
Косяк в сетевом обмене.
У меня тоже самое как у вас.
Снизил частоту чтения регистров с 1 сек до 15 сек, все успокоилось!
У ПР205 как я и подозревал, в последних сообщениях писал про это, там память переполняется из формирования буферов для стека буфера обмена, при этом это отражается и на переменных проекта
Я на STM32 сам пробовал с библиотекой модбас работать, там есть нюансы работы с памятью, можно накосячить и потом все это залезет на твои переменные проекта
Но те, которые тут писали, что это не полноценный ПЛК и вы пытаетесь из него выжать невозможное, с этим не соглашусь, я пытаюсь 5% хотя бы получить от заявленного и то не выходит!
Так что давайте в крайности не будем заезжать, если у меня 45 переменных и я их тремя группами читаю раз в секунду - это детский утренник!
Даже если бы я 100 переменных читал это бы составило 2,5% от заявленного количества для ПР205!
Вы о чём?
Производителем заявлено:
Регистров 4095 штук, у нас 45, это 1%
Клиентов, поддерживаемых одновременный обмен с ПР205 не более 5, у нас 2, один ПР205 в локальной сети, второй сервер диспетчеризации через Интернет
zakhar81
22.01.2024, 07:12
вчера Венера была в Стрельце
РТУ мастер, а ТСР - слейв?
чисто из интереса - не проще было конвертер интерфейса поставить, какую нибудь Моху? и уже обрабатывать на верхней стороне?
У меня тоже один из ПР205 в качестве Slave TCP с диспетчерским сервером, а в качестве мастера по RS485 работает c частотником, управляет заданием ПИДчастотника и командует его запуском остановом с контролем его фактического состояния.
И с какого перепуга я буду с диспетчерского сервера ломится на этот частотник напрямую, если он в контуре управления/регулирования участвует?
Т.е. по вашей схеме как вы советуете можно сделать так что при потере WAN у вас система в разнос пойдет!
zakhar81
22.01.2024, 07:24
Господа разработчики собирайте экспериментальный проект из хотя бы пару ПР205 которые между собой обмениваются и плюс внешний опрос, меняйте нагрузку читайте групповыми запросами и обычными, разными функциями и увидите результат
Нужны испытания во всех комбинациях и интенсивностях обмена ModBusTCP и отловите баги
Королев Кирилл
22.01.2024, 09:49
Господа разработчики собирайте экспериментальный проект из хотя бы пару ПР205 которые между собой обмениваются и плюс внешний опрос, меняйте нагрузку читайте групповыми запросами и обычными, разными функциями и увидите результат
Нужны испытания во всех комбинациях и интенсивностях обмена ModBusTCP и отловите баги
Добрый день!
На выходных стояла связка из 5 штук ПР205, которые обменивались между собой (IP-адреса в Ваших проектах 102->101->100->103->104) и Owen OPC. Зависаний и перезагрузок не наблюдалось. Переменные при этом изменяли по сети и с экрана. Настроен групповой опрос с периодом в 1 с.
zakhar81
22.01.2024, 11:16
Скажите чем опрашивали?
Опрашивали их в локалке?
zakhar81
22.01.2024, 11:23
Попробуйте на 4 групповых разделить, у нас 3 группы на чтение и 1 на запись, при чем сейчас на запись только если значения поменяют
Из этих трех групп у одной частота в 100 раз меньше, у двух других 1 сек была
Регистры не по порядку были и мы разделили на группы
А мы попробуем сделать один групповой и частоту опроса вернуть обратно на 1 сек
Я тестовый тоже собираю с большим количеством регистров только, чтобы быстрее добиться того же эффекта
Возможно еще есть нюансы обмена через WAN поскольку мы их не из LAN опрашиваем
Mix4lich
22.01.2024, 14:52
Добрый день
Вот давайте тестировать вместе!
Добрый,у меня проблема решилась откатом ПО на старую версию.И ПР и среда разработки на версию ниже последней.У себя я нашел момент когда ПР 100% не грузилось после обновления программы.Как только я выносил на схему больше 6 сетевых переменных (именно НА СХЕМУ,т.е. графически обозначил ее в проекте) - всё,после заливки висит.Сами переменные не удалял,как было 15,так и оставалось.Тут уже понял,что что-то не так с ПО.Откатил - заработало.
In_Da_Cher_A
22.01.2024, 14:58
И с какого перепуга я буду с диспетчерского сервера ломится на этот частотник напрямую, если он в контуре управления/регулирования участвует? Т.е. по вашей схеме как вы советуете можно сделать так что при потере WAN у вас система в разнос пойдет!что за бред-то? я писал про его случай, а у него датчик стоит
In_Da_Cher_A
22.01.2024, 15:05
Добрый день
Снизил частоту чтения регистров с 1 сек до 15 сек, все успокоилось!
Так что давайте в крайности не будем заезжать, если у меня 45 переменных и я их тремя группами читаю раз в секунду - это детский утренник!
так детский утренник или всё-таки раз в секунду не вывозит? :D
я сказал своё мнение
а тыкать в описание, что ОВЕН написал 4095 и 5 соединений - так тоже самое как и с Модбас РТУ - пишут про 115200 и про 1200 метров, только, как говорится "Но, Петька, есть один нюанс"
zakhar81
23.01.2024, 15:30
Всем добрый вечер
После увеличения периода опросов, даже до 10 секунд полет нормальный, вторая неделя идет
Следующий шаг - возврат к 1 секундной частоте опроса но с одним групповым на чтение на все 45 регистров
Нужно выявить корень зла чтобы знать как на эти грабли не наткнуться в дальнейшем
Возможно 4 групповых опроса с частотой 1 секунда закидывают ПР205 с результирующей частотой уже не 1гц а в 4 раза выше и он не справляется
Кирилл написал что у них трое суток отработало по нашей схеме с внешним опросом и все Ок, правда не сказал чем опрашивали
Королев Кирилл
23.01.2024, 15:45
Все добрый вечер
После увеличения периода опросов, даже до 10 секунд полет нормальный, вторая неделя идет
Следующий шаг - возврат к 1 секундной частоте опроса но с одним групповым на чтение на все 45 регистров
Нужно выявить корень зла чтобы знать как на эти грабли не наткнуться в дальнейшем
Возможно 4 групповых опроса с частотой 1 секунда закидывают ПР205 с результирующей частотой уже не 1гц а в 4 раза выше и он не справляется
Кирилл написал что у них трое суток отработало по нашей схеме с внешним опросом и все Ок, правда не сказал чем опрашивали
Добрый день!
Опрашивали Owen OPC (https://owen.ru/product/new_opc_server) по локальной сети. Настройки параметров опроса для всех устройств идентичны, прикладываю их:
73058
zakhar81
24.01.2024, 16:01
Вот еще немного информации
Внутри локальной сети все работает на бешенных скоростях и с бОльшим количеством регистров
Через интернет в разных точках работает по разному, видимо в зависимости от пропускной способности и помех (искажению пакетов TCP)
Вот я склоняюсь к тому что пакеты какие то искажены так, что и наблюдается то подвисания ПР205 и его перезагрузка, то не пойми какие значения попадают в переменные
zakhar81
24.01.2024, 16:03
На последнее обновление ОЛ 2.5.344 можно переходить?
Там судя по всему новая прошивка для ПР205?
Там исправили проблему с нерабочим вариантом аналогового входа по измерению сопротивления?
Кто нибудь уже проверил?
zakhar81 каким боком искажение пакета и перезагрузка? Если прибор принял пакет искаженным - он просто не ответит. Если принял чистый, ответил а клиент его получил искаженным, клиент снова отправит пакет запроса.
А если имеет место быть перезагрузка, то это не лады с чем-то другим.
zakhar81
24.01.2024, 16:29
Ну факт остается фактом, снизили цикл все прекратилось
Запустили опрос узла в LAN а не через WAN тоже безобразие это прекратилось
А если через WAN не снижать опрос, а просто увеличить паузу между запросами? если ПО позволяет конечно.
zakhar81
24.01.2024, 16:36
Для TCP есть особенность в отличие от UDP в том что есть механизм повторной передачи пакетов при их потере(пропусках) в моменты перегрузок сетевого оборудования
https://russianblogs.com/article/64722230277/
Возможно при больших таймаутах в итоге на ПР205 прилетают куча потерянных пакетов и он не может этого пережить
Я не гуру в этой области но я не знаю как это объяснить
zakhar81
24.01.2024, 16:39
А если через WAN не снижать опрос, а просто увеличить паузу между запросами? если ПО позволяет конечно.
Ну вот я вообще думаю динамически это менять со стороны мастера (сервера), читать секунды с ПР205 или с другого устройства за маршрутизатором в той же локалке что и ПР205 и менять цикл опроса в зависимости от пропускной способности
я не про таймауты. Тем более у вас ПР205 сервер, то есть слейв. А клиент некий ПК со Scada или чем там? Если Scada позволяет, сделайте циклический опрос или не реже раза в 1с , но с паузой между запросами и все это через WAN.
Мастер это как раз клиент, а Сервер это ПР.
zakhar81
25.01.2024, 16:26
я не про таймауты. Тем более у вас ПР205 сервер, то есть слейв. А клиент некий ПК со Scada или чем там? Если Scada позволяет, сделайте циклический опрос или не реже раза в 1с , но с паузой между запросами и все это через WAN.
Мастер это как раз клиент, а Сервер это ПР.
Добрый вечер
Под сервером я подразумевал диспетчерский сервер на котором запущен мастер ModBusTCP который опрашивает слейвы - ПР205 через WAN
Но сам ПР205 он же слейв котрый функционально является сервером ModBusTCP для нашего мастера который запущен на диспетчерском сервере (в том смысле что он является тоже сервером у которого, в свою очередь есть уже группа клиентов получающих данные с него.
Короче каламбур со словами получился и все запутались!)
У меня так и было, как Вы говорите, с интервалом 1 сек диспетчерский сервер опрашивал ПР205-ые, через WAN, у которых фиксировались описанные выше в этой теме глюки с перезагрузками
И после всяческих опытов и переделок уменьшили интенсивность запросов до периода 30 секунд и глюки все как рукой сняло
В локалке к с тати работает без проблем с циклом 100 мс
Сейчас 10 секунд сделали интервал между запросами со стороны сервака тоже нормально
Запросы на запись группы регистров вообще сделали только по изменению параметров
Почему так работает через WAN не понятно, видимо влияет пропускная способность сетевого оборудования, но почему это приводит к обнулению или попаданию не пойми каких значений в переменные и перезагрузке ПР205 я не понимаю.
Тут кто то писал что разводка неправильная, ну пусть она была бы не правильная, но при чем тут глюки со значениями переменных? Это только программная часть не физическая
А что касается разводки или схемотехники, то у нас все развязано гальванически. Источник питания на дискретную периферию отдельный, сигналы с этой периферии дискретной (реле давления и т.п.) на обмотки реле а контактные группы этих реле используют 24В с внутреннего источника ПР205 и на его же дискретные входы сигнал коммутируют. Аналоговые выходы тоже с внутреннего источника так же питаются через барьеры 4-20мА на внешние управляемые краны уходят, и соответственно не связаны гальванически с их источником питания. Аналоговые входы - термометры сопротивления, тоже ни с чем не связаны
Короче нужно разбираться с сетевым обменом TCP через WAN но времени нет на лабораторные эксперименты
Может наши разработчики из овена соберутся силами и проведут испытания с обменом ПР205 через WAN и чего нибудь отловят
я говорю не про интервалы запросов, а про паузу между ними.
zakhar81
25.01.2024, 19:25
я говорю не про интервалы запросов, а про паузу между ними.
У меня не пачка из 45-ти запросов для 45-ти регистров, у меня один запрос на все 45-регистров длиной 118 байт, максимально разрешенная длина 125 (регламентируемая для протокола ModBus TCP)
Поэтому у меня интервал и пауза это одно и тоже, как в ШИМ сигнале
Если бы я каждый регистр отдельно опрашивал то у меня была бы пачка из 45 запросов с каким то временным промежутком между ними или точнее сказать смещением каким то аппаратным (не поддающимся настройкам) и циклом или паузой между отправкой запросов/пакетов
zakhar81
25.01.2024, 19:47
Немного из информационных материалов касаемо протоколов TCP и UDP
1. TCP протокол подразумевает повторную передачу пакетов по которым не пришло подтверждения доставки от удаленного хоста, при чем неоднократно 12 попыток с экспоненциальным увеличением периода каждой последующей повторной отправки вплоть до 64 сек, потом сброс и выставление флага о недоступности
http://dan.spb.ru/tcp_ip/tcp21.html
2. Маршрутизатор или роутер при маршрутизации пакетов может помещать их в стек своей оперативной памяти или в так называемую очередь и потом чуть позже их "выплевывать" в сеть
https://www.geeksforgeeks.org/packet-queuing-and-dropping-in-routers/
Из этого можно сделать вывод, как я предполагал выше, в одном из своих сообщений, что при потерях связи и её восстановлении эти пакеты могут пачками одним разом прилететь на ПР205 и его аппаратная часть или программно аппаратная часть с этим не справляется. В локальной сети такие проблемы при испытаниях будет проблематично имитировать, потому как если тупо выключить питание или выдернуть сетевой кабель у коммутатора, то ясен пень он там из буфера никакие пакеты не выплюнет, у него это не предусмотрено функционально в отличии от маршрутизатора или роутера. А вот связь через интернет (WAN) имеет достаточно много узловых точек с маршрутизаторами и при потерях связи механизм повторной передачи пакетов я думаю пытается обеспечить их доставку и долбит наш ПР205 как надо, после восстановления связи после таймаутов. У нас их на одном объекте только два наших, не считая провайдера местного и маршрута через остальные узлы самой WAN.
Если на форуме есть специалисты в области сетевых технологий опровергните или подтвердите то что я тут написал
не надо рассказывать лишнего. Банальный пример. Циклический опрос с таймаутом, достаточным при приеме ответа даже при задержках + пауза между запросами скажем 300мс.. Используемое вами ПО вообще позволяет так настроить?
Пусть в сумме это будет не раз в 1с а чуть больше. Будут перезагрузки ПР или прекратятся ?
zakhar81
26.01.2024, 11:38
Конечно позволяет, таймаут это максимальное время ожидания ответа, после которого ожидание ответа заканчивается и выставляется флаг ошибки, у меня он 15 сек, а цикл опроса 10 сек он же и есть пауза между запросами
Нет, пауза между запросами это другое. При опросе раз в 10 сек на нее плевать, а вот при циклическом или раз в 1с это может повлиять.
таймаут у вас бешенный, обычно столько не требуется даже в радио преобразователе RS485 вполне хватало 3с.
zakhar81
28.01.2024, 10:08
Не сразу понял про вашу паузу, это время ожидания ответа на запрос, и да у некоторых это действительно пауза называется, в том числе у овеновского OPC
Пробовал разные варианты, от 1 секунды до 5 секунд, наиболее устойчиво работает начиная от 5 секунд, т.е цикл 5 сек и ожидание (пауза) еще 5 секунд
При тестировании сети в разные дни бывает не одного пакета не теряется и ответы на запросы прилетают через 30-80 мс, не пинги узла а именно ответы от ПР205.
А бывает что и 5 секунд не хватает, тогда через таймаут (он тоже настраивается) наш сервак (мастер) срабатывает сессию и запускает пакеты заново.
zakhar81
29.01.2024, 19:37
Добрый вечер
Еще раз настаиваю на проверке закидывания ПР205 пакетами при появлении связи после её потери
Нужна защита от этого, это имеет место быть
Мы выбрали интервал 5 сек и время ожидания 5 сек, но ПР205 и через 100 мс отвечает неплохо, но стоит прервать связь и потом тысячи пакетов недоставленных кладут Пр205 набок и он перезагружается и переменные в памяти обнуляются или съезжают, видимо из за переполнения буфера в памяти отводимого под прием с порта.
Я больше никак не могу объяснить такое поведение, нужно сделать защиту от прилета кучи пакетов
При цикле 5 сек при замирании связи ПР205 видимо как то вывозит прилетающие недоставленные пакеты, но все же иногда перезагружается и всегда при этом я не могу запустить отладку на таких перезагруженных ПР-ах, в них не та программа что в ОЛ, про это я писал неоднократно.
Проблема не решена, увеличив цикл мы вставили костыль, но это не решение
Испытайте все таки уже обмен через интернет а не по локалке.
Вот, можете почитать:
https://mizakona.ru/kak-rabotaet-mex...-svyazi-v-tcp/
In_Da_Cher_A
29.01.2024, 22:09
я в принципе оказался прав - ПР не вывозит обмен с такой дискретностью
ранее спрашивал - что вам даёт 1 секунда, почему вы "настаиваете" именно на такой частоте опроса
что за высокоскоростные процессы в ИТП происходят, которые надо контролировать, не отводя глаз?
и что у вас за сеть между ПР и АРМ?
Испытайте все таки уже обмен через интернет а не по локалке.интернет у всех разный
увы я подозреваю, что ответ будет таким - это проблемы в вашей сети. треш-DDOS атака переполняет какой-то буфер? тяните оптику
zakhar81
30.01.2024, 06:24
Инет нормальный, не самый говеный в тех точках, но замирания есть иногда, когда в домах люди активно лезут в инет видимо
Пинги идут от 20-до 60 мс по сетевому оборудованию, но несколько раз в сутки при больших нагрузках, ответ может замирать
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки
Вот от такой коллизии и нужно защищать ПР205
Сам ПР205 прекрасно работает, даже с интервалом 100 мс, если сеть не замирает, например в локалке, как Овеновцы испытывали
А интернет он всегда такой будет, я же на всей планете не поменяю провода на оптику!
Нужно продумать механизм защиты ПР205 от сверхбольшого объема пакетов прилетающих к нему в буфер, он этого не вывозит
zakhar81 нет. я не про timeout а именно про паузу сверх timeout...
Короче, запрос - время ожидания ответа - пауза - новый запрос. То есть если в течении отведенного времени (timeout) прибор не ответил, сперва выдерживается пауза и только потом новый запрос. Как-то так.
Еще есть вариант, которым можно поиграться на некоторых системах (RapidScada). У нее есть возможность выставить параметрами разрывать соединение после каждого опроса или оставаться на связи.
На некоторых преобразователях интерфейсов очень помогает, особенно на не очень хорошем интернете.
Интересно, что в ПР205 применили в качестве Ethernet? какой-то преобразователь встроен наверняка, у процессора же нет Ethernet напрямую. Так что возможно тут какие-то коллизии идут
у меня нет ПР205, но при работе с различными устройствами через различные преобразователи замечал потери связи, но вот чтобы устройство перегружалось такого ни разу не видел.
zakhar81
30.01.2024, 09:38
В локалке если работают то и между собой они обмениваются и с мастером и сами если какие девайсы опрашивают то норм.
Проблемы начались именно когда сервак наш в качестве мастера начал их через интернет опрашивать
При этом с памятью у после этого что то происходит, переменки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?
Сейчас подобрали так: 5 секунд цикл, плюс ожидание 5 секунд и перезапуск опроса еще 5 сек (таймаут)
При таком раскладе хотя бы значения переменных в памяти ПР205 не сбрасываются и не съезжают после перезагрузок, но перезагрузки остались, правда не такие частые и без последствий
Есть мысль овен OPC запустить и проверить работу через него, чтобы претензий со стороны ОВЕНа не было в кривости нашего опроса
Но повторюсь, в локалке работает без этих приколов
Рассматривали тоже вариант такой, чтобы следующий запрос отправлялся после получения ответа, но есть одно но, а если мы не дождемся ответа вообще, то что у нас сервак наш мастер может вообще не отправить следующий запрос в какой нибудь момент, если ответа так и не придет. Тоже крайность
Тогда нужно получать ответ что узел не доступен типа как при пинге и принимать решение
Короче в любом случае это изврат какой то
Нужно решать первопричину проблемы
In_Da_Cher_A
30.01.2024, 10:05
И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузкину так или иначе - ПР не может работать при, в общем-то обычных, коллизиях в сети. Я вот несколько раз писал, про ПЛК110 и СП315, которые также не восстанавливают обмен при каких-то перезапусках/перезагрузках сети/мастера, но все начинали вопить про мои кривые руки
При этом с памятью у после этого что то происходит, перемнки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?это какой-то хардкорнософтовый баг, а не фича, что косвенно и означает, что ПР не вывозит.
Пинги идут от 20-до 60 мс по сетевому оборудованиюа какая у вас сетка? что стоит в железе по "длине" сетки? может нужна какая-то хардовая маршрутизация, чтобы обойти "домовые" узлы или делать "VPN" какой-то напрямую?
Есть мысль овен OPC запустить и проверить работу через него, чтобы претензий со стороны ОВЕНа не было в кривости нашего опроса
это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, вобщем это всё наводит на мысль что кривость присутствует в методах опроса ПРки, а не в слейве
zakhar81
30.01.2024, 18:47
Для теста пока 6 тэгов накидал из 45-ти для одного из ПР который самый проблемный (с наибольшим количеством регистров относительно других в этом узле), запустил, увидел что примерно в среднем раз в 5-10 минут вот такие виды ошибок уже пролетают:
Неверный id транзакции, в сообщениях всех с таким содержанием id различается на единичку
Ответ устройства не соответствует запросу
Нет ответа от устройства
Пауза ваша в настройках никак не влияет на количество ошибок, остальное все так же, период опроса и время ожидания ответа с количеством попыток
Это оказывается OPC DA а нам бы хотелось UA, работать не получится через него, только тестировать
zakhar81
30.01.2024, 18:53
ну так или иначе - ПР не может работать при, в общем-то обычных, коллизиях в сети. Я вот несколько раз писал, про ПЛК110 и СП315, которые также не восстанавливают обмен при каких-то перезапусках/перезагрузках сети/мастера, но все начинали вопить про мои кривые руки
это какой-то хардкорнософтовый баг, а не фича, что косвенно и означает, что ПР не вывозит.
а какая у вас сетка? что стоит в железе по "длине" сетки? может нужна какая-то хардовая маршрутизация, чтобы обойти "домовые" узлы или делать "VPN" какой-то напрямую?
Наш сервер который Мастер в одном городе а узлы со слейв ПР-ми в двух других городах
Думал да про ВПН, но с учетом ужесточения контроля, хотя у мене пару сеток работает, даже WireGuard есть, ну ток не через буржуйский сервер а через наш на территории РФ, не блочат вроде бы
zakhar81
30.01.2024, 18:58
это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, в общем это всё наводит на мысль что кривость присутствует в методах опроса ПРки, а не в слейве
Вы внештатный сотрудник ОВЕНа что ли?
Все пользователи негодяи вокруг а ОВЕН-овцы д'артаньяны
Я конечно поддерживаю отечественного производителя но нужно реагировать и перепроверять то о чем пользователи пишут
У нас не самописный сервер, работает с другими девайсами тоже, хотя даже не в этом суть, поэтому заявлять о кривости софта или запросов не выяснив подробности как то тоже как вы выражаетесь кривовато
Вы внештатный сотрудник ОВЕНа что ли?
Все пользователи негодяи вокруг а ОВЕН-овцы д'артаньяны
Я конечно поддерживаю отечественного производителя но нужно реагировать и перепроверять то о чем пользователи пишут
У нас не самописный сервер, работает с другими девайсами тоже, хотя даже не в этом суть, поэтому заявлять о кривости софта или запросов не выяснив подробности как то тоже как вы выражаетесь кривовато
лог обмена будет у Вашего профессионального сервера, если не самописный то давно бы уже выложили, чтоб подтвердить Ваши слова
... в 5-10 минут вот такие виды ошибок уже пролетают:
Неверный id транзакции, в сообщениях всех с таким содержанием id различается на единичку
Ответ устройства не соответствует запросу
Нет ответа от устройства
..
Можно как-то в хронологии? После хорошей серии какая ошибка самая первая?
zakhar81 вы бы ПО озвучили, раз оно не самописное.
И таки я бы проверил другим ПО, другой Scada. Их на просторах валом. Вот прям советовал бы RapidScada погонять и в настройках канала TCP клиент убрать настройку "Оставаться на связи".
И еще там есть "Отключаться при ошибке" - очень было бы интересно как себя поведет тот же циклический опрос когда после каждого сеанса будет отключение клиента?
In_Da_Cher_A
31.01.2024, 02:33
Наш сервер который Мастер в одном городе а узлы со слейв ПР-ми в двух других городахлично я бы не стал делать такую конфигурацию сети, "основанную" на ежесекундном опросе удалённых узлов и без "своей" сети, чисто на шароварном интернете
тут и без сюрпризов от ОВЕНа, полно возможностей умереть вашей сетке по самым тупейшим бытовым причинам
и спрашивал уже, но вы не отвечаете - а какая железная конфигурация сети? и зачем АРМу, да ещё в другом городе, такая частота опроса?
если уж настолько всё серьёзно и ответственно, то почему не сделать резервную линию? конечно это стоит денег, но сетка здесь играет важнейшую роль и так, и на мои фломастеры - над многими техрешениями надо бы подумать лучше на стадии проектирования
сейчас, если уж более менее ситуация нормализована и состояние "больного" тяжёлое, но стабильное, я бы не ждал чудес от ОВЕНа и проработал решения по обеспечению надёжности работы сети - вплоть до отдельного договора с провайдером и/или организацией резервного канала/кольца
.. я бы не ждал чудес от ОВЕН...
... но также пока и от ТС не видно подтвержений что его клиент не чудит.
zakhar81
01.02.2024, 07:50
это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, в общем это всё наводит на мысль что кривость присутствует в методах опроса ПР-ки, а не в слейве
Выкладываю логи и настройки запущенного от 31 января овен OPC
Например: 31-го числа с 15:02:46 по 15:25:42 была потеря связи с узлом, после это связь восстановилась и ПР205 после этого 6 раз перезагрузился и при подключении из ОЛ опять выдает сообщение о несоответствии программы в ПР205 и проекта открытого в ОЛ, т.е. с памятью что то произошло.
Сегодня отключили, запустили обратно наш сервер
Далее наверно буду пробовать в локалке устраивать разрывы соединения чтобы выявить в каких случаях будет воспроизводится косяк с перезагрузками при разрывах соединения, если вообще воспроизведется
Времени нет на испытания господа, работать некогда
zakhar81
01.02.2024, 07:54
Логи и картинка с настройками
ПР205 после этого 6 раз перезагрузился
Вы можете создать пустой проект, который бы так же перегружался чтоб сюда выложить, не затрагивая Вашу интеллектуальную собственность?
Логи и картинка с настройками
ну вот смотрите, по Вашим логам ответ приходит в среднем через 40мс, соответственно можно подождать по времени в раз пять, получается около 200мс секунд и понять что с кaналом связи что то неладно и выдать ошибку, поэтому поставив Время ожидания ответа 200мс, а не 5000мс как у Вас, Вы сразу же диагностируете проблему, а не "завалите" слейв ненужными пакетами
несколькг метров архива хорошо, но как то время/строку где есть проблема обозначить не мешало бы
zakhar81
01.02.2024, 13:38
несколько метров архива хорошо, но как то время/строку где есть проблема обозначить не мешало бы
Я в сообщении своем написал как раз диапазон времени где был сбой с перезагрузкой
https://owen.ru/forum/showthread.php?t=38960&p=428038&viewfull=1#post428038
"31-го числа с 15:02:46 по 15:25:42 была потеря связи с узлом, после это связь восстановилась и ПР205 после этого 6 раз перезагрузился и при подключении из ОЛ опять выдает сообщение о несоответствии программы в ПР205 и проекта открытого в ОЛ, т.е. с памятью что то произошло."
zakhar81
01.02.2024, 13:50
Вы можете создать пустой проект, который бы так же перегружался чтоб сюда выложить, не затрагивая Вашу интеллектуальную собственность?
Я вас умоляю, какая нафиг интеллектуальная собственность)))
Могу прям тот проект, который там работает выложить, я овеновцам высылал, там ничего военного нет, три ПИД регулятора и температурный график
На остальных ПР205, только сетевых переменных меньше
По поводу танцев с бубнами с переменными, экранными и сетевыми и их обновлением, то в попытке снять подозрение на это все комбинации были перепробованы, поскольку думал что дело в этом
А так обмен работает не плохо, более 100 мс я не видел, но в моменте может пару тройку раз в сутки замирать, но это ж WAN
Работает сейчас в принципе более менее, после того как 5 секунд цикл сделали
Раньше мог повиснуть когда цикл был 1 сек
И даже после перезагрузки вроде бы редко когда в памяти переменные съезжают, только ОЛ ругается на несоответствие программы в приборе той что открыта в ОЛ
Но косяк имеет место быть
пофигу на времена, устройство не должно перегружаться. типа не ответить, ответить на предыдущий запрос и всякое такое, но никак не уходить в перегруз.
zakhar81
01.02.2024, 14:09
пофигу на времена, устройство не должно перегружаться. типа не ответить, ответить на предыдущий запрос и всякое такое, но никак не уходить в перегруз.
Ну я о том же
Хотелось бы так
Но сейчас думаю следующие несколько ближайших проектов организуем так что ПР205 будут мастерами а наш сервак в качестве сервера (слэйва) будем смотреть как такая конфигурация будет работать
Я думаю это более устойчивый вариант получится
У меня несколько самодельных ESP32 так работали с этим же сервером и со сторонним, но там был MQTT
zakhar81
01.02.2024, 14:20
Вот пожалуйста
Никаких секретов нет, проект школьного уровня.
Может кто косяк найдет, переделает проект, так что ПР205 не будет перезагружаться, гоотов даже за вознаграждение с моей стороны!
Работает сейчас в принципе более менее, после того как 5 секунд цикл сделали
да совершенно не корректно все работает, в логе за 10 секунд четыре запроса, ни как не укладывается что период опроса пять секунд. Ожидание убирайте до 200мс и паузу до 20мс, ну или экспериментируйте чтоб орс выдавал два запроса за 10 секунд, а не четыре
zakhar81
01.02.2024, 15:53
Наш сервак каждые 5 секунд, сегодня если успею лог выложу, или завтра
А вот овеновский OPC да у него пролетает почему то иногда и каждую секунду, с ним как раз и произошли перезагрузки в первые же сутки, а на нашем работал неделю до этого с 5-ти секундным циклом
Наш сервер опроса не самопальный, SCADA внесена в реестр ПО РФ, просто рекламировать систему или разводить тут диалог на тему какую SCADA лучше выбрать не хотелось, тему замусорят
Но и на Node RED можно запустить опрос, это не принципиально, хоть на андроид
zakhar81 вам никто Scada менять не предлагает, а просто проверить другими, где есть Modbus. SimleLite, RapidScada и другими где есть возможность как оставаться на связи так и с разрывом соединения после каждого опроса.
То есть понять, будут ли перезагрузки устройства в тех или иных режимах.
Вроде как Scada системы позволяют от 16-ти переменных опрашивать в бесплатном варианте. Хуже конечно если час работы всего без ограничений, смотреть надо по характеристикам.
если вам при этом нужны данные в вашей системе, ну временно настройке OPC UA и забирайте через него к себе.
А все эти тесты на Modpoll это только с ручным тестированием сидеть и пялиться.
kondor3000
01.02.2024, 19:51
Вот пожалуйста
Никаких секретов нет, проект школьного уровня.
Может кто косяк найдет, переделает проект, так что ПР205 не будет перезагружаться, гоотов даже за вознаграждение с моей стороны!
Ткнул пару раз и весь проект улетел как фанера над Парижем. Проект откровенно сырой.
Допустим отвалился датчик уличной температуры или по Модбас не правильно передалось, поставил Т наруж. воздуха 60 градусов, макрос PLA улетел в не число 73242
Следом за ним все ПИДЫ в не число 73243 и все выходы в не число 73244
Даже 41 градус, будет тот же эффект.
Вот вам сбой всего и сразу.
макрос PLA улетел в не число.
division by zero наше всё
А сколько живой цикл занимает с такой математикой?
И что такое
Перезапрос после ошибки device:
в контексте TCP?
zakhar81
02.02.2024, 04:24
На столе лежит в локальной сети ПР205 с "нечислом", так как у него датчики не подключены
Запустил позавчера для экспериментов, буду ставить его как подопытный тоже в какую нибудь точку чтобы доступ через WAN (интернет) был
И я его опрашиваю с циклом 0,5 сек и не улетает как фанера ....
В блоке sqale4 нужно maxQ исправить 50 на 40, они (блоки масштабирования) как раз для этого случая туда и вставлены чтобы ПИДы не встали если датчики отвалятся
Сбой происходит при реконекте (восстановлении сегмента сети) после нескольких минут пропадания связи с этим узлом через WAN (подчеркиваю через WAN не через LAN)
Мы тут не об этом, давайте по сути вопроса
zakhar81
02.02.2024, 05:48
division by zero наше всё
А сколько живой цикл занимает с такой математикой?
И что такое
в контексте TCP?
Овен конфигуратором когда их смотрю, 12 ms показывает на том который мы тут обсуждаем на остальных тож +/-
Отладкой не могу посмотреть, поскольку со временем, как я говорил, после перезагрузки из за сбоя в его памяти ОЛ ругается на не соответствие загруженной в него программы и той что открыл в ОЛ
а 187 проблем, это их хвостик на скрине?
а 187 проблем, это их хвостик на скрине?
нет это проблемы конвертации и версий библиотек, вот в гугле чтоб не беспокоило 73269
это я все к тому, что проблемы с модбасом могут быть не причиной перезагрузки устройства, а следствие т.к. устройство смотрит наружу в интернет и не предназначено защищаться от сетвых проблем, вполне возможно кто то добивается отказа в обслуживании, как минимум надо за NAT-ом держать с пробросом портов
Да это понятно. Заинтересовало образование вот этого:
Неверный id транзакции, в сообщениях всех с таким содержанием id различается на единичку
Ответ устройства не соответствует запросу
Нет ответа от устройства
Таймаут увидели. Бывает. А сдвиг (как понял -1, если id делает ++) означает что клиент не взял ответ. А на новый запрос взял что есть - а там ответ от предыдущего, и так и пошло..
В рамках TCP как-то странно, пакеты могут бродить как угодно - поток приемника совпадает с потоком отправителя 1:1
zakhar81
04.02.2024, 05:59
нет это проблемы конвертации и версий библиотек, вот в гугле чтоб не беспокоило 73269
это я все к тому, что проблемы с модбасом могут быть не причиной перезагрузки устройства, а следствие т.к. устройство смотрит наружу в интернет и не предназначено защищаться от сетевых проблем, вполне возможно кто то добивается отказа в обслуживании, как минимум надо за NAT-ом держать с пробросом портов
Так и сделано, за NAT, внешние порты в локалку проброшены только с IP сервера есть доступ
Последние настройки для нашего сервера опроса: 5 секунд, ожидание ответа 100ms и перезапуск только через минуту (ну или разрыв соединения на минуту), и с того момента когда ОВЕН OPC сервером для теста опрашивали с "некорректными" настройками, с ПР-ами проблем не было.
Сейчас еще появился другой ПР205, для него сделал ежесекундный опрос, там пока в ручном режиме все работает и я решил над ним поиздеваться
Решили, что для следующих объектов сделаем ПР205 мастерами и пусть они все на сервер сами кидают свои данные и читают с него настройки
Хотя не знаю какие еще могут быть подводные камни
Но эти оставлю пока так, хочется до истины докопаться
zakhar81
04.02.2024, 08:51
Тут еще на одном объекте роутер как то странно глюканул, как раз с портами проброшенными косяк вышел, первый раз такое вижу чтобы некоторые проброшенные порты не гоняли пакеты, после перезагрузки работа через эти порты восстановилась
Вопрос тоже какие лучше роутеры ставить на объектах, с одной стороны супер дорогие ставить смысла тоже особого нет, трафик то смехотворный, чисто для ПР205 который, других устройств там в этих узлах нет в локалке уже за роутерами только ПР205-е, с другой стороны говно всякое глючное тоже нет желания ставить чтоб потом проблемы выхватывать
Может кто поделится какие используете для таких решений когда оборудование раскидано и связь через провайдера местного используется
Банкоматы всякие тоже же через инет работаю, но там всякие ВПНы для безопасности и т.д.
Провайдер говорит что выше по сетке ихние свичи управляемые используются, какие не говорит, ну и все равно это разные объекты и разные провайдеры и территориально разные все
Вариант когда ПР205 сам будет на сервер отправлять запросы более безопасен будет в любом случае, порты на них открыты не будут из вне
ВПНы городить тоже смысла нет, ну кому нужно перехватывать трафик с этого оборудования, кому он нафиг нужен
наблюдалась похожая с ТС проблема. Версия OL 2.5.344.0 соответственно версия ПО ПР205 последняя.
Объект работал месяц, заехал обновиться неделю назад и заодно поставил роутер для диспетчеризации и на всякий пожарный.
Законфигурировал по-быстрому опрос облаком как автоопределяемый прибор
Всякий пожарный наступил вечером того же дня.. Через 4 часа пропала связь с облаком и по TCP тоже к регистрам не смог достучаться. Связь с объектом была. Начал копаться дальше: ОL и конфигуратор определил, что проект ПУСТОЙ! Благо ничем критичным не управлял и о том, что что-то там слетело знаю только я.
Удаленно успешно перекрошился, убрал опрос из облака как "автоопределяемый прибор", теперь опрашиваю прибор как "Универсальный Modbus" 8 регистров.
5 день -полет нормальный
Тут еще на одном объекте роутер как то странно глюканул, как раз с портами проброшенными косяк вышел, первый раз такое вижу чтобы некоторые проброшенные порты не гоняли пакеты, после перезагрузки работа через эти порты восстановилась
Вопрос тоже какие лучше роутеры ставить на объектах, с одной стороны супер дорогие ставить смысла тоже особого нет, трафик то смехотворный, чисто для ПР205 который, других устройств там в этих узлах нет в локалке уже за роутерами только ПР205-е, с другой стороны говно всякое глючное тоже нет желания ставить чтоб потом проблемы выхватывать
Может кто поделится какие используете для таких решений когда оборудование раскидано и связь через провайдера местного используется
tp-link TL-MR100 - дешево и сердито =)
мне нравятся - связь 24/7 стабильно, если не глубоко в подвале оборудование.
zakhar81
06.02.2024, 09:02
Ну вот хоть кто то тоже с аналогичной бедой попался
Спасибо что заглянули и написали!
У нас роутеры TP-LINK TL-WR844N с родной прошивкой подкидывают вышеописанные глюки с нарушением обмена через настроенные порты, приходится перезагружать
А например стародревние TP-LINK TL-WR841 с OpenWRT прошивкой работают отлично без глюков
Недавно попался Xiaomi Mi Router 4C он тоже очень дешевый но работает стабильно уже месяц
У вас опрос как модбас устройство с восьмью регистрами с какими настройками не расскажите?
zakhar81
06.02.2024, 09:05
Господа разработчики обратите внимание что у человека с облаком глюк произошел с выносом прошивки у ПР205
zakhar81
06.02.2024, 09:07
Вы там на февраль анонс делали что будет обновление прошивки для ПР205 так вот хотелось эти глюки бы отловить все таки как то
zakhar81
06.02.2024, 09:32
Кто нибудь с облаком через интернет испытывал ПР205 отзовитесь
У вас опрос как модбас устройство с восьмью регистрами с какими настройками не расскажите?
Вы про облако какие настройки? На скрине
73489
А у OPC сервера было время опроса 3 сек, ожидание ответа 1000мс
zakhar81
12.02.2024, 11:36
наблюдалась похожая с ТС проблема. Версия OL 2.5.344.0 соответственно версия ПО ПР205 последняя.
Объект работал месяц, заехал обновиться неделю назад и заодно поставил роутер для диспетчеризации и на всякий пожарный.
Законфигурировал по-быстрому опрос облаком как автоопределяемый прибор
Всякий пожарный наступил вечером того же дня.. Через 4 часа пропала связь с облаком и по TCP тоже к регистрам не смог достучаться. Связь с объектом была. Начал копаться дальше: ОL и конфигуратор определил, что проект ПУСТОЙ! Благо ничем критичным не управлял и о том, что что-то там слетело знаю только я.
Удаленно успешно перекрошился, убрал опрос из облака как "автоопределяемый прибор", теперь опрашиваю прибор как "Универсальный Modbus" 8 регистров.
5 день -полет нормальный
Уважаемые господа разработчики
Проверьте со своим облаком через интернет, как "автоопределяемый прибор", может удастся глюк выловить еще быстрее
Кто нибудь с облаком через интернет испытывал ПР205 отзовитесь
Да. Две недели в бубен стучал, не смог. Правда у меня ПМ210 и ПР205. Постоянно выскакивает ошибка 255 и висит, соответственно далее данных нет. При включении всё работает, обмен идёт, иногда несколько минут, а иногда и восемь часов. Сделал кучу опытов и нашёл закономерность, не работает в связке именно ПР205 и ПМ210 нового образца. Если к ПР205 ставлю ПМ210 в старом корпусе - всё работает как надо. Беру ПМ210 (нового образца который с ПР205 не хочет) ставлю с любым другим ПР200 - всё работает без сбоев.
zakhar81
13.02.2024, 06:57
Да. Две недели в бубен стучал, не смог. Правда у меня ПМ210 и ПР205. Постоянно выскакивает ошибка 255 и висит, соответственно далее данных нет. При включении всё работает, обмен идёт, иногда несколько минут, а иногда и восемь часов. Сделал кучу опытов и нашёл закономерность, не работает в связке именно ПР205 и ПМ210 нового образца. Если к ПР205 ставлю ПМ210 в старом корпусе - всё работает как надо. Беру ПМ210 (нового образца который с ПР205 не хочет) ставлю с любым другим ПР200 - всё работает без сбоев.
Так у ПР205 уже встроенный функционал работы с облаком, нет необходимости в использовании модуля ПМ210
Попробуйте напрямую сконфигурировать работу с облаком из ПР205
Отпишитесь потом если не сложно, как будет работать
МихаилГл
13.02.2024, 07:10
Так у ПР205 уже встроенный функционал работы с облаком, нет необходимости в использовании модуля ПМ210
Попробуйте напрямую сконфигурировать работу с облаком из ПР205
Отпишитесь потом если не сложно, как будет работать
А если у ТС не проводное подключение к сети интернет?
zakhar81
13.02.2024, 08:14
GPRS модем
А если у ТС не проводное подключение к сети интернет?
Так и есть.
Попробуйте напрямую сконфигурировать работу с облаком из ПР205
Честно уже надоело, пока бросил, надо снова щит на стенд ставить... Думаю этот щит скорее всего оставлю со старой версией ПМ210, а на ПР205 большой и жирный крест поставлю, с ним по мимо всего ещё хватает замечаний. Вообще объектов таких на данный момент два, вот теперь и не знаю, на каком железе второй делать, надо было одинаково как-то, на одном железе, а тут такой конфуз. Техподдержка заколебала, две недели на разных людей перекидывали, вводные внимательно не читают, попросил самих сделать тест - вообще слились.
GPRS модем
Что-то не понял, как?
а на ПР205 большой и жирный крест поставлю
сложно надеяться на работу с ПР205 если она еще не в стабильной стадии 73534
zakhar81
13.02.2024, 13:32
Вот думаю ребята пока замолчали (слились) и пометку поставили * в разработке, поскольку при работе с облаком те же глюки примерно что и при работе в целом через интернет как с модбас устройством.
А мы сейчас следующие проекты делаем ПР205 мастером а сервер слэйвом, чтобы они туда писали и от туда читали все что нужно сами, за одно и закрываем проблему необходимости в публичных IP на самих объектах без ВПНов
Поом отпишусь как будет работать по такой схеме
сложно надеяться на работу с ПР205 если она еще не в стабильной стадии 73534
Красивая стадия! Что-то на главной странице ни слова, а чёткое обозначение по работе с облаком, и цена настоящая в полный рост.
73553
Красивая стадия! Что-то на главной странице ни слова, а чёткое обозначение по работе с облаком, и цена настоящая в полный рост.
73553
это документация к облачному сервису, а не к ПР. И с облаком данное реле может общаться и по другим интерфейсам, не обязательно как автоопределяемый прибор, а просто модбас устройство, если есть претензии озвучте
это документация к облачному сервису, а не к ПР. И с облаком данное реле может общаться и по другим интерфейсам, не обязательно как автоопределяемый прибор, а просто модбас устройство, если есть претензии озвучте
По моему я всё озвучил выше. Давайте не будем сто постов писать в пустую, а то мусору и так на форуме полно и Вы постираете половину - будет неразбериха.
ЗЫ: Всё это напоминает договор с мелким шрифтом внизу. Думаю все знают о чём я.
Николаев Андрей
14.02.2024, 20:19
Смотрю все мои любимые форумчане подтянулись.
Отвечу и тут. Почему прибор виснет - будем разбираться. Согласен, что даже если есть проблемы с сетевым обменом - виснуть не должен.
На сколько я знаю - мы пока не смогли повторить. Завтра уточню у наших ребят.
zakhar81, можно попросить консолидировать по итогу проблематику и рекомендации что и в каких режимах проверить. Если честно - немного запутался в 12 страницах.
* В разработке - просто не убранная инфа. Алгоритм связи с облаком у ПР205 ровно такой же как у ПР103.
zakhar81
19.02.2024, 10:43
Смотрю все мои любимые форумчане подтянулись.
Отвечу и тут. Почему прибор виснет - будем разбираться. Согласен, что даже если есть проблемы с сетевым обменом - виснуть не должен.
На сколько я знаю - мы пока не смогли повторить. Завтра уточню у наших ребят.
zakhar81, можно попросить консолидировать по итогу проблематику и рекомендации что и в каких режимах проверить. Если честно - немного запутался в 12 страницах.
* В разработке - просто не убранная инфа. Алгоритм связи с облаком у ПР205 ровно такой же как у ПР103.
Добрый день
Ну времени потрачено конечно много на описание и теперь все за нового)))
Основные проблемы это работа ПР205 через WAN в качестве модбас сервера (слэйва).
Через месяц запустим ПР205 который будет мастером и сам будет писать и читать на удаленный сервер, посмотрим как он справится с этой задачей
Аналогичные проблемы и при подключении к вашему облаку как автопределяемого устройства
При разрывах связи и не только наблюдается висяк, перезагрузка и ПР205 с вылетом значений переменных или вообще прошивки в целом
В наших случаях когда опрос ПР295 был ежесекундный то после разрыва связи на несколько минут
Запускали с Owen opc в том числе, косяк наблюдается сразу после провалов и восстановления связи. Логи тут выкладывали
Если запросы к примеру идут реже, например раз в 5 или 10 сек, то все не так фатально, но прибор все равно ресетится иногда с потерей части значений переменных, при этом прошивку не выносит совсем, но, при подключении к нему для удаленной отладки ОЛ выдает всегда сообщение о несоответствии программы в приборе и той что открыли в ОЛ для удаленной отладки
Проблема не воспроизводится в рамках локальной сети, ваши уже проверили
Но поскольку тут два человека уже отписались что с облаком аналогичная беда происходила, если установить прибор как авто определяемое устройство, с выносом прошивки напрочь, то вы можете оттестить это дело со своим облаком сами, у нас времени нет на это.
zakhar81
19.02.2024, 14:19
Мое предположение, что при обмене через WAN при восстановлении связи ПР закидывает недоставленными TCP пакетами, поскольку протокол TCP, по своей сути подразумевает гарантированную их доставку. И чем чаще был опрос тем большее число пакетов может прилететь при восстановлении связи. С облаком возможно такая же картина.
zakhar81
19.02.2024, 15:20
Добрый вечер
Попробовал включить в настройках ПР205-го Owen Cloud, все разрешил во вкладке доступа к параметрам, но он так и не появился на связи
В аккаунте его добавил как ПЛК (пункт ниже после авто определяемого прибора), номер перепроверил еще раз чуть позже, все Ок, ошибок нет
Конфигуратором в локалке все вижу и список параметров ModBus Slave и статус подключения к Owen Cloud отображается как "Работа"
Делал как на видео https://youtu.be/9u_CQz0Zwy0?si=6ekFiG6r64ZtzOO_
Адрес в сети там в самом низу карточки настроек это что?
zakhar81
19.02.2024, 15:47
Минут через 15 прибор всё таки появился, ура!
Королев Кирилл
19.02.2024, 15:49
Добрый вечер
Попробовал включить в настройках ПР205-го Owen Cloud, все разрешил во вкладке доступа к параметрам, но он так и не появился на связи
В аккаунте его добавил как ПЛК (пункт ниже после авто определяемого прибора), номер перепроверил еще раз чуть позже, все Ок, ошибок нет
Конфигуратором в локалке все вижу и список параметров ModBus Slave и статус подключения к Owen Cloud отображается как "Работа"
Делал как на видео https://youtu.be/9u_CQz0Zwy0?si=6ekFiG6r64ZtzOO_
Адрес в сети там в самом низу карточки настроек это что?
Добрый вечер! Добавляйте прибор как "МХ210 через Modbus"
73681
Включили ли доступ в настройках прибора?
73682
zakhar81
19.02.2024, 16:42
Добрый вечер! Добавляйте прибор как "МХ210 через Modbus"
73681
Включили ли доступ в настройках прибора?
73682
Подключили именно так как авто определяемый контроллер, поскольку хотим воспроизвести косяк как у двух участников форума, которые в ветке описывали косяк как у нас но только при работе через OwenCloud
Правда этот ПР205 обновлен до последней версии, и может вы что то уже подправили и мы не сможем воспроизвести то что тут описывал например в этом сообщении: https://owen.ru/forum/showthread.php?t=38960&p=428439&viewfull=1#post428439
Королев Кирилл
19.02.2024, 16:48
Подключили именно так как авто определяемый контроллер, поскольку хотим воспроизвести косяк как у двух участников форума, которые в ветке описывали косяк как у нас но только при работе через OwenCloud
Правда этот ПР205 обновлен до последней версии, и может вы что то уже подправили и мы не сможем воспроизвести то что тут описывал например в этом сообщении: https://owen.ru/forum/showthread.php?t=38960&p=428439&viewfull=1#post428439
Тестировали работу прибора с облаком, который был добавлен как "Автоопределяемый прибор ОВЕН" при прерывании связи. Перезагрузок и проблем, подобных описанным, не наблюдали.
zakhar81
20.03.2024, 18:54
Всех приветствую!!!
Да, действительно стало лучше, но блин как всегда ни кто не сказал что все таки что то исправляли в этой части
Теперь другой косяк, невозможно обновить прошивку с версии 1.2.1 до последней 1.4.0
Те что "из коробки" с более ранней версией прошивки обновляются до последней, а что делать если прошивка 1.2.1 не знаем
Пробовали устанавливать ранние версии, те что доступны с сайта 2.4.335, 2.5.344, тоже самое, процесс прерывается на 17%, потом начинается проверка и вываливается сообщение о невозможности обновить.
Поэтому просим разобраться и предложить решение этой проблемы
Открываем новую тему по этой проблеме, возможно кто то еще столкнется с этой проблемой
zakhar81
19.10.2024, 07:12
Проблемы с обновлением в данный момент связаны с этой темой что мы тут пытались донести до разработчиков
Действительно прибор и по сей день не вывозит обмен со стороны WAN, опрос со стороны мастера через интернет
Овеновцы тестировали такой обмен данными тогда когда мы открыли эту тему только в рамках LAN
Мы решили проблему только изменив структуру системы, т.е. ПР205 работают с сервером как мастер устройства, Пишут туда свои измеренные значения и читают настройки
Несколько таких узлов еще осталось, и в данный момент обновление прошивки возможно если отключить опрос прибора со стороны сервера
Так же прям очевидна разница при переходе на другую схему обмена данными. Когда сервер был мастером по отношению к ПР205, прибор перезагружался, как только сменили прошивку и конфиг на сервере на противоположную, сервер стал слэйвом а ПР205 мастером перезагрузки сразу прекращались
Так что господа тестируйте обмен с прибором через интернет, увидите много нового
Кривые TCP пакеты вешают его, у него буфер или что то еще там переполняется и он сам в перезагрузку уходит, но в последних версиях хотя бы прошивка остается, ранее писал что программа в приборе отличается от той что открыта для отладки
Напомню сразу что обмен не столь интенсивный был, раз в 1 секунду
zakhar81
19.10.2024, 07:15
С облаком то у вас наверное прибор работает как мастер клиент если так можно сказать, поэтому все более менее норм
zakhar81
25.04.2025, 04:59
Предположительно причиной зависаний ПР205 все таки является обмен по Ethernet в виду отсутствие фильтрации TCP пакетов на аппаратном уровне, из за которой ПР205 вешается достаточно быстро, даже при опросах раз в 10 сек или даже раз в минуту.
Так как TCP предполагает гарантированную доставку пакетов данных при сбоях в сети и при восстановлении связи может завалить ПР205 просто на раз два три, так же как и прилетающие поврежденные или вообще левые пакеты могут забить ему буфер если их не отфильтровывать сразу
Это происходит когда ПР205 работает как ModBus сервер и его опрашивают через WAN
Вы тестировали ПР205 просто в локальной сети, когда мы просили о решении этой проблемы, но в локалке такого безобразия с кривыми TCP пакетами у вас в лабораторных условиях конечно же воспроизвести не удалось и по итогу вы нас ни чем не порадовали.
Нам пришлось менять схему информационного обмена где ПР205 выступает в роли Master устройства ну или клиента, и кидает на сервер данные сам, так же как и читает от туда настройки.
При такой реализации схемы обмена данными ПР205 не уходит в зависания
Такая схема обмена данными сравнима с работой через облачный сервис где контроллер выступает клиентом/мастером
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot