Вид для печати
Павел у вас в каких случаях из меню вылетает с ресетом?Цитата:
Сообщение от ПавелП
У нас тоже такие глюки проскакивают с ресетом и в том числе при попытке изменения переменных на экране, но это не основной косяк а побочка
Но про ваши вылеты и ресеты тоже было бы неплохо информацию добавить
КН экранные - это финишь.Цитата:
Сообщение от zakhar81
Женщина не может выбрать из ниспадающего меню,
не срабатывает, или по "ВК" переходит на другой пункт.
Это механика. Во втором ПР приоткрывается панель при "<<" кнопке.
Это они моментально исправили!!! :)Цитата:
Сообщение от zakhar81
Сейчас вылеты при работе с переменной разрешением/запретом в облако.
Я выловил момент, когда периодически, через пару минут, рессетится.
При условии что разрешение включается по Sek.1 (счётчик секунд, по второму биту).
Такого быстрого управления ПР205 не переносит...
Просто увеличил продолжительность включения до 30 сек, через 5 мин.
И как прочитать из облака туда записанные переменные для верификации?
P.S. "- А в остальном, прекрасная маркиза, всё хорошо...
Всё хорошо-о..." :)
Ну вот Кирилл (Королев из ОВЕНа) обратите внимание что у Павла тоже ресетится при работе с перемнной из облака при частоте обновления 1 сек
Я думаю что это не совпадение, у нас тоже при частоте чтения и записи в ПР205 через WAN по ModBusTCP аналогичная хрень происходит периодически
Мы сделали 5 сек, если меньше то все, кроме ресета там съезжают и другие переменки еще
Я думаю что это баг связанный с обмен через WAN в целом и не только с нашим сервером но и соблаком овена
Вот тема где наш косяк при работе через WAN обсуждаем:
https://owen.ru/forum/showthread.php?t=38960&page=7
Они собрали нашу схему одного из узлов как у нас для имитации из 4-х ПР205 и так ничего и не дождались, глюка который у нас имеет место, за что им отдельное спасибо, но собрали они её в локальной сети и их сервер который опрашивал эту группу ПР205 он тоже был в локальной сети, а наш сервер опрашивает из через Инет.
Но придется собирать все таки схему для обмена через WAN, косяк кроется именно в этом
Моё предположение таково, что в случаях непродолжительных (до 5 сек) проблемах связи через интернет, при её восстановлении ПР205-й закидывает в моменте недоставленными пакетами. В подтверждение этого у меня было пару раз такая ситуация что при перезагрузке роутера который в узловой точке стоит уже в непосредственной близости с ПР205 в одной локалке с которым ПР205, последний тоже уходит в перезагрузку следом, как только инет появляется. Как буд то ему прилетают все те недоставленные пакеты, видимо все сразу.
Немного из информационных материалов касаемо протоколов TCP и UDP
1. TCP протокол подразумевает повторную передачу пакетов по которым не пришло подтверждения доставки от удаленного хоста, при чем неоднократно 12 попыток с экспоненциальным увеличением периода каждой последующей повторной отправки вплоть до 64 сек, потом сброс и выставление флага о недоступности
http://dan.spb.ru/tcp_ip/tcp21.html
2. Маршрутизатор или роутер при маршрутизации пакетов может помещать их в стек своей оперативной памяти или в так называемую очередь и потом чуть позже их "выплевывать" в сеть
https://www.geeksforgeeks.org/packet...ng-in-routers/
Из этого можно сделать вывод, как я предполагал выше, в одном из своих сообщений, что при потерях связи и её восстановлении эти пакеты могут пачками одним разом прилететь на ПР205 и его аппаратная часть или программно аппаратная часть с этим не справляется. В локальной сети такие проблемы при испытаниях будет проблематично имитировать, потому как если тупо выключить питание или выдернуть сетевой кабель у коммутатора, то ясен пень он там из буфера никакие пакеты не выплюнет, у него это не предусмотрено функционально в отличии от маршрутизатора или роутера. А вот связь через интернет (WAN) имеет достаточно много узловых точек с маршрутизаторами и при потерях связи механизм повторной передачи пакетов я думаю пытается обеспечить их доставку и долбит наш ПР205 как надо, после восстановления связи после таймаутов. У нас их на одном объекте только два наших, не считая провайдера местного и маршрута через остальные узлы самой WAN.
Если на форуме есть специалисты в области сетевых технологий опровергните или подтвердите то что я тут написал
Мы сделали 5 секунд ожидание ответа от ПР205 в настройках нашего сервера и частоту опроса тоже 5 секунд, и при такой конфигурации для работы без перезагрузок стало достаточно для тех нескольких узлов что сейчас в работе через Интернет
А какой у вас цикл показывает ПР205?Цитата:
Сообщение от zakhar81
У меня 8 мс с "вылетами" до 12 мс через каждые 3-5 сек.
А так как сложность программы на ST возрастёт кратно,
то необходимо по циклам раскидывать мою программу.
Такая возможность у меня есть, но необходим счётчик мкс,
чтоб принимать решения, сколько выполнить в первом цикле,
втором, и т.д.
Сейчас доступны: Ms, Sek, Min, Hour.
нужен регистр mks
Посмотрим что завтра скажут представители ОВЕН.
Пару моментов помню когда было и 18мс и 23 мс
После вылета при попытке подключения для отладки ОЛ выдает сообщение о несоответствии программы которая исполняется в ПР205 к которому подключаешься. Поэтому смотрю овенконфигуратором те переменные которые я раскидал по регистрам
Вылез глюк с сетевой переменной,
причём обнаружился случайно...
Оказалось разделение на экранные и сетевые несоответствия.
Объявляется же сетевая как целочисленная.
Сетевая целочисленная на экран выводит 16 бит.
Обычная целочисленная на экран выводит 32 бита.
Обе объявляются как целочисленные...
Я в курсе.Цитата:
Сообщение от kondor3000
В том то и дело, что я её не трогал.
Всё работало.
Целочисленная, и отображала на экране 1234567 нормально.
Сейчас запустил на экран через "обычную", не сетевую, переменную.
Так это не глюк ПР205, это фича ЛоджикаЦитата:
Сообщение от ПавелП