ПР205 Зависания и перезагрузки каждые сутки

[In_Da_Cher_A]

я в принципе оказался прав - ПР не вывозит обмен с такой дискретностью
ранее спрашивал - что вам даёт 1 секунда, почему вы "настаиваете" именно на такой частоте опроса
что за высокоскоростные процессы в ИТП происходят, которые надо контролировать, не отводя глаз?
и что у вас за сеть между ПР и АРМ?

Испытайте все таки уже обмен через интернет а не по локалке.

интернет у всех разный
увы я подозреваю, что ответ будет таким - это проблемы в вашей сети. треш-DDOS атака переполняет какой-то буфер? тяните оптику

[zakhar81]

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

[melky]

zakhar81 нет. я не про timeout а именно про паузу сверх timeout...
Короче, запрос - время ожидания ответа - пауза - новый запрос. То есть если в течении отведенного времени (timeout) прибор не ответил, сперва выдерживается пауза и только потом новый запрос. Как-то так.

Еще есть вариант, которым можно поиграться на некоторых системах (RapidScada). У нее есть возможность выставить параметрами разрывать соединение после каждого опроса или оставаться на связи.
На некоторых преобразователях интерфейсов очень помогает, особенно на не очень хорошем интернете.

Интересно, что в ПР205 применили в качестве Ethernet? какой-то преобразователь встроен наверняка, у процессора же нет Ethernet напрямую. Так что возможно тут какие-то коллизии идут
у меня нет ПР205, но при работе с различными устройствами через различные преобразователи замечал потери связи, но вот чтобы устройство перегружалось такого ни разу не видел.

[zakhar81]

В локалке если работают то и между собой они обмениваются и с мастером и сами если какие девайсы опрашивают то норм.
Проблемы начались именно когда сервак наш в качестве мастера начал их через интернет опрашивать
При этом с памятью у после этого что то происходит, переменки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?
Сейчас подобрали так: 5 секунд цикл, плюс ожидание 5 секунд и перезапуск опроса еще 5 сек (таймаут)
При таком раскладе хотя бы значения переменных в памяти ПР205 не сбрасываются и не съезжают после перезагрузок, но перезагрузки остались, правда не такие частые и без последствий
Есть мысль овен OPC запустить и проверить работу через него, чтобы претензий со стороны ОВЕНа не было в кривости нашего опроса
Но повторюсь, в локалке работает без этих приколов
Рассматривали тоже вариант такой, чтобы следующий запрос отправлялся после получения ответа, но есть одно но, а если мы не дождемся ответа вообще, то что у нас сервак наш мастер может вообще не отправить следующий запрос в какой нибудь момент, если ответа так и не придет. Тоже крайность
Тогда нужно получать ответ что узел не доступен типа как при пинге и принимать решение
Короче в любом случае это изврат какой то
Нужно решать первопричину проблемы

[capzap]

Есть мысль овен OPC запустить и проверить работу через него, чтобы претензий со стороны ОВЕНа не было в кривости нашего опроса

это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, вобщем это всё наводит на мысль что кривость присутствует в методах опроса ПРки, а не в слейве

[zakhar81]

это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, в общем это всё наводит на мысль что кривость присутствует в методах опроса ПРки, а не в слейве

Вы внештатный сотрудник ОВЕНа что ли?
Все пользователи негодяи вокруг а ОВЕН-овцы д'артаньяны
Я конечно поддерживаю отечественного производителя но нужно реагировать и перепроверять то о чем пользователи пишут
У нас не самописный сервер, работает с другими девайсами тоже, хотя даже не в этом суть, поэтому заявлять о кривости софта или запросов не выяснив подробности как то тоже как вы выражаетесь кривовато

[capzap]

Вы внештатный сотрудник ОВЕНа что ли?
Все пользователи негодяи вокруг а ОВЕН-овцы д'артаньяны
Я конечно поддерживаю отечественного производителя но нужно реагировать и перепроверять то о чем пользователи пишут
У нас не самописный сервер, работает с другими девайсами тоже, хотя даже не в этом суть, поэтому заявлять о кривости софта или запросов не выяснив подробности как то тоже как вы выражаетесь кривовато

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

[zakhar81]

это вот здравая мысль, только будет наоборот, докажет что кривой у вас опрос, потому что такие объяснения про какой то цикл, какое то ожидание, какой то перезапуск названный таймаутом, хотя время должно отсчитываться с момента посылки, в общем это всё наводит на мысль что кривость присутствует в методах опроса ПР-ки, а не в слейве

Выкладываю логи и настройки запущенного от 31 января овен OPC
Например: 31-го числа с 15:02:46 по 15:25:42 была потеря связи с узлом, после это связь восстановилась и ПР205 после этого 6 раз перезагрузился и при подключении из ОЛ опять выдает сообщение о несоответствии программы в ПР205 и проекта открытого в ОЛ, т.е. с памятью что то произошло.
Сегодня отключили, запустили обратно наш сервер
Далее наверно буду пробовать в локалке устраивать разрывы соединения чтобы выявить в каких случаях будет воспроизводится косяк с перезагрузками при разрывах соединения, если вообще воспроизведется
Времени нет на испытания господа, работать некогда

[capzap]

ПР205 после этого 6 раз перезагрузился

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

[In_Da_Cher_A]

И вот если ежесекундно опрашивать ПР205 то он не от этого конечно же ложится, а вот именно после замирания обмена на несколько десятков секунд или минуту - две, с последующим восстановлением. Ведь после восстановления все недоставленные пакеты за это время прилетают на ПР205 и кладут его вплоть до перезагрузки

ну так или иначе - ПР не может работать при, в общем-то обычных, коллизиях в сети. Я вот несколько раз писал, про ПЛК110 и СП315, которые также не восстанавливают обмен при каких-то перезапусках/перезагрузках сети/мастера, но все начинали вопить про мои кривые руки

При этом с памятью у после этого что то происходит, перемнки могут съехать или обнулится и при попытке отладки ОЛ выдает что программа в приборе отличается от той что в ОЛ, это то как объяснить?

это какой-то хардкорнософтовый баг, а не фича, что косвенно и означает, что ПР не вывозит.

Пинги идут от 20-до 60 мс по сетевому оборудованию

а какая у вас сетка? что стоит в железе по "длине" сетки? может нужна какая-то хардовая маршрутизация, чтобы обойти "домовые" узлы или делать "VPN" какой-то напрямую?