ПЛК 110-60[м2] + МВ110-24.32ДН modbus переодическое возникновение ошибки 81

Вид для печати

25.10.2016, 13:13
leming495

Вложений: 2

ПЛК 110-60[м2] + МВ110-24.32ДН modbus переодическое возникновение ошибки 81

День добрый

Есть ПЛК 110-60[м2] и расширение МВ110-24.32ДН
Расширение подключено к ПЛК по RS485 через конфигуратор.
Вложение 27261
Вложение 27262
все прекрасно работает данные получаем анализируем и т.п.

Но если на расширении не происходит изменения (т.е. не замыкаются входы) через некоторое время (которое пак я понял = maxtimeout*amountrepeat)
Происходит потеря соединения с расширением т.е. возникает ошибка 81

Физически лечится перезапуском ПЛК (если отключить по питанию расширение соединение не восстанавливается).
Возможно ли каким либо образом программно перезапустить соединение modbus созданное в конфигураторе ?
25.10.2016, 13:15
leming495

Конфигурация ПЛК

PLCInfo
PLC model MODEL PLC 110-60
Binary VERSION 0.3.56
Need Target version >= 3.07
Compiled: 13:17:45 Aug 29 2016
STM32 binary version 114
MAC 6A:77:00:FF:FB:31
IP 192.168.0.154
GATE 192.168.0.1
MASK 255.255.255.0
26.10.2016, 12:30
Филоненко Владислав

amountrepeat==100???
Режим both для входов - это зачем?
поставьте по таймеру и 1 повтор.
07.11.2016, 11:54
leming495

Режим both стоит для того чтобы опрос происходил и по времени и по событию.
Количество повторов поставлено максимально возможное для минимизации отвалов соединения.
В этой конфигурации оно хоть как-то работает пока замыкаются входы в определенный лимит времени.

По поводу поставить просто по времени с 1м повтором - пробовали если входы не замыкаются в обозначенный тайм аут как и было описано возникает ошибка 81 после чего ее убрать можно только перезапуском ПЛК.

Ну и вопрос собственно не в том, как должен происходить опрос по таймеру или по событию или и так и так, а в том как при данной ошибке ее сбросить и заново программно инициировать соединение.
07.11.2016, 12:13
Спорягин Кирилл

Поставьте PollingTime не 10 мс, а хотя бы 50 мс (лучше 100 мс). Вы просто терроризируете модуль посылками опроса. Проводил эксперименты. На ответ модуль МВ110-32ДН тратит где-то 11 мс на скорости 115200. Плюс все что написал Владислав Филоненко.
07.11.2016, 12:33
Филоненко Владислав

Цитата:

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

Режим both стоит для того чтобы опрос происходил и по времени и по событию.
Количество повторов поставлено максимально возможное для минимизации отвалов соединения.
В этой конфигурации оно хоть как-то работает пока замыкаются входы в определенный лимит времени.

По поводу поставить просто по времени с 1м повтором - пробовали если входы не замыкаются в обозначенный тайм аут как и было описано возникает ошибка 81 после чего ее убрать можно только перезапуском ПЛК.

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

Какому событию? Для входа такой режим означает, что как только поменялось значение на входе модуля и ПЛК его прочитал, ПЛК сразу вход снова читает.
100 повторов - это террор линии. опрашивает 1 параметр/прибор, а остальные могут и подождать. Особенно "полезно", если прибор не работает.
07.11.2016, 12:41
leming495

Т.е. при частых запросах модуль просто повисает или что ?
Я бы конечно согласился с этим если бы не одно но.
Модуль отдельно от ПЛК при возникновении данной ошибки перезагружался по питанию. Связь после перезапуска не восстанавливалась.
При этом если перезапустить ПЛК а модуль не трогать все нормально. Т.е. проблемма на стороне ПЛК.

И опять же почему тогда работает при замыкающихся входах? И ни разу не хочет отваливаться ?
А вот если событий нет то после тайм аутов связь рвется сразу.

И насколько я понимаю данная ситуация будет возникать и в описанных вами настройках просто с другими тайм аутами при отсутствии событий на модуле.
В принципе у нас события на модуле генерируются постоянно поэтому в продакшене ошибка практически не возникает (т.е. ооочень редко). Возникает именно на тесте когда мы не замыкаем контакты на модуле.

Поэтому вопрос в данном случае остается тот же - как программно перезапустить соединение и возможно ли это в принципе.
07.11.2016, 14:24
Спорягин Кирилл

Цитата:

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

Т.е. при частых запросах модуль просто повисает или что ?

Любому устройству необходимо какое-то время чтобы выполнить некоторые действия. Модулю для ответа на 1 запрос нужно около 11 мс.
А Вы пытаетесь слать ему ему запросы каждые 10 мс. Очевидно, что это не верно. И во всяком случае нет смысла.

Цитата:

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

Я бы конечно согласился с этим если бы не одно но.
Модуль отдельно от ПЛК при возникновении данной ошибки перезагружался по питанию. Связь после перезапуска не восстанавливалась.

Я не понимаю, что значит "перезагрузка по питанию". Попробуйте установить рекомендованные настройки и проверить будет ли работать?
07.11.2016, 16:53
leming495

Цитата:

Сообщение от Спорягин Кирилл

Любому устройству необходимо какое-то время чтобы выполнить некоторые действия. Модулю для ответа на 1 запрос нужно около 11 мс.
А Вы пытаетесь слать ему ему запросы каждые 10 мс. Очевидно, что это не верно. И во всяком случае нет смысла.

Ну это не совсем так т.к. по ответу техподдержки на ответ у данного модуля тратится 3,6мс поэтому 10 мс это вполне в пределах нормы. А мне по задачам ответ нужен максимально быстро.

Цитата:

Сообщение от Спорягин Кирилл

Я не понимаю, что значит "перезагрузка по питанию".

Перезапуск по питанию означает что питание отключаем у модуля (ну или плк) ждем 10 сек включаем обратно.

Цитата:

Сообщение от Спорягин Кирилл

Попробуйте установить рекомендованные настройки и проверить будет ли работать?

Т.к. в продакте оно более менее живет с тек настройкой то подождем доставку запасного контроллера для экспериментов.
Однако если я правильно помню он отваливался с дефолтными настройками кодесиса у которых PollingTime=100мс там правда amountrepeat=0 был.
Но сути дела оно не меняет. т.к. проблема в данном случае не в количестве опросов в ед времени. А в том что при отсутствии замыкания на контактах теряется связь с модулем.

Потому еще раз повторюсь вопрос не в настройках параметра модуля в конфигураторе (с этим как раз все понятно) вопрос в том можно ли это соединение както программно перезапустить без выключения ПЛК.
07.11.2016, 19:29
Спорягин Кирилл

Цитата:

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

Ну это не совсем так т.к. по ответу техподдержки на ответ у данного модуля тратится 3,6мс поэтому 10 мс это вполне в пределах нормы. А мне по задачам ответ нужен максимально быстро.

Тех. поддержка ошибается. Ответ от модуля МВ110-32ДН занимает от 9 до 12 мс (в среднем 11 мс) на скорости 115200.
Они, видимо, сообщают Вам теоретическое время опроса, т.е. время полученное из расчета: кол-во байт в запросе-ответе / скорость сети.
Но практическое время всегда выше теоретического (см. тут). В приведенном примере, правда, в качестве слейва выступал контроллер S7-1214. Но тенденция сохраняется и для модулей ОВЕН.

Цитата:

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

Т.к. в продакте оно более менее живет с тек настройкой то подождем доставку запасного контроллера для экспериментов.
Однако если я правильно помню он отваливался с дефолтными настройками кодесиса у которых PollingTime=100мс там правда amountrepeat=0 был.
Но сути дела оно не меняет. т.к. проблема в данном случае не в количестве опросов в ед времени. А в том что при отсутствии замыкания на контактах теряется связь с модулем.

Потому еще раз повторюсь вопрос не в настройках параметра модуля в конфигураторе (с этим как раз все понятно) вопрос в том можно ли это соединение както программно перезапустить без выключения ПЛК.

Если, действительно, "при отсутствии замыкания на контактах теряется связь с модулем", то модуль нужно в ремонт.

Но все же попробуйте установить рекомендованные настройки.
08.11.2016, 10:06
leming495

Цитата:

Сообщение от Спорягин Кирилл

Тех. поддержка ошибается. Ответ от модуля МВ110-32ДН занимает от 9 до 12 мс (в среднем 11 мс) на скорости 115200.
Они, видимо, сообщают Вам теоретическое время опроса, т.е. время полученное из расчета: кол-во байт в запросе-ответе / скорость сети.
Но практическое время всегда выше теоретического (см. тут). В приведенном примере, правда, в качестве слейва выступал контроллер S7-1214. Но тенденция сохраняется и для модулей ОВЕН.

Спасибо за информацию весьма полезно, некоторые вещи открыл для себя заново.
Но приведенный пример не совсем корректен как мне показалось там ведь вы либу используете а не конфигуратор. Перечитал всю ветку но не нашел временной статистики для конфигуратора. (если кто то мерял ткните пожалуйста)
По опыту теста (когда писался проект) и того и того либа работает вроде как медленнее конфигуратора. Цели такой правда не стояло замерять скорость с точностью до мс но всетаки.
Если говорить про либу то да я с вами соглашусь ответ там занимает больше 10мс. Но речь то не про нее.

Цитата:

Сообщение от Спорягин Кирилл

Если, действительно, "при отсутствии замыкания на контактах теряется связь с модулем", то модуль нужно в ремонт.

Т.е. по сути как я понимаю соединение созданное через конфигуратор перезапустить невозможно? А подобная ситуация в принципе возникать не должна при нормальной работе контроллера и модуля?
Как пример:
Есть плк связан с модулем ввода 2 проводами.
Пьяный водопроводчик обрывает провода шины и все это дело стоит день 2 пока не придет саппорт и не подключит их обратно. (и плк и сам модуль работают - питание подается)
Все эти день -2 ПЛК не видит слейва естесно и возникает ошибка 81.
Вопрос подключится ли модуль обратно при восстановлении проводки или нет ? Т.е. ситуация таже что и описана вначале вопроса. (К слову сказать так тоже тестировал)

Цитата:

Сообщение от Спорягин Кирилл

Но все же попробуйте установить рекомендованные настройки.

Попробуем конечно как придет запаска обязательно отпишусь.
08.11.2016, 10:23
Спорягин Кирилл

Цитата:

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

Спасибо за информацию весьма полезно, некоторые вещи открыл для себя заново.
Но приведенный пример не совсем корректен как мне показалось там ведь вы либу используете а не конфигуратор. Перечитал всю ветку но не нашел временной статистики для конфигуратора. (если кто то мерял ткните пожалуйста)
По опыту теста (когда писался проект) и того и того либа работает вроде как медленнее конфигуратора. Цели такой правда не стояло замерять скорость с точностью до мс но всетаки.
Если говорить про либу то да я с вами соглашусь ответ там занимает больше 10мс. Но речь то не про нее.

Я задумывался над тем, чтобы сделать замеры через конфигуратор. Но мне не понятно как это сделать. Проблема в том, что в поле LastAdress (как я понимаю!) устанавливается адрес последнего опрошенного модуля, но уже после опроса. Т.е. нам неизвестен момент начала опроса.
Вместе с тем, из общих соображений понятно, что время опроса так и так должно быть одинаково. Это я утверждаю несмотря на то, что общепринятая точка зрения заключается как раз в обратном, а именно, что опрос через конфигуратор дольше. Но такая точка зрения связана главным образом с тем, что опрос модулей с большим числом опрашиваемых регистров (например, аналогового ввода) через конфигуратор ведется с помощью множественных запросов, а через библиотеку можно организовать групповые запросы. Подробнее можно почитать в этих темах - №1 и №2.

Цитата:

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

Т.е. по сути как я понимаю соединение созданное через конфигуратор перезапустить невозможно? А подобная ситуация в принципе возникать не должна при нормальной работе контроллера и модуля?
Как пример:
Есть плк связан с модулем ввода 2 проводами.
Пьяный водопроводчик обрывает провода шины и все это дело стоит день 2 пока не придет саппорт и не подключит их обратно. (и плк и сам модуль работают - питание подается)
Все эти день -2 ПЛК не видит слейва естесно и возникает ошибка 81.
Вопрос подключится ли модуль обратно при восстановлении проводки или нет ? Т.е. ситуация таже что и описана вначале вопроса. (К слову сказать так тоже тестировал)

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

По крайней мере мне не известен способ перезапуска соединения, но мне кажется, что он и не нужен.
В описанной Вами ситуации после подключения проводов модуль начнет опрашиваться как ни в чем не бывало. Можете попробовать такую ситуацию на стенде.
08.11.2016, 11:36
Трофимов Артем

leming495 , Вы должны понимать, что когда вы ставите тип опроса "Both" , который включает в себя и "By_pool_time" и "By_value_change" - второй элемент по изменению значения означает событие внутри программы контроллера( изменение значения в программе) а не факт замыкания или размыкания входа модуля. получается, что Вы с частотой 10 мс опрашиваете модуль, при изменении значения входов ПЛК по настройке Both тут же начинает снова опрос этого же модуля.
настройки Both и по изменению значения применимы к модулям управления ( к выходным модулям) , но не к вводным модулям. число перезапросов в 100 - это очень большая величина. 3 раза достаточно, но как пишут коллеги достаточно 0 или 1, т.к. конфигурация ПЛК пойдёт опрашивать модули дальше, что прописаны Вами и в конечном итоге вернётся к модулю ввода и попытается его опросить снова, если в очередной раз не получится, снова опрашиваются другие модули и происходит возврат к модулю ввода. Так работает конфигурация , она не забывает модуль, который не отвечает.
08.11.2016, 12:37
Спорягин Кирилл

leming495, так совпало, что я как раз занимался экспериментами по опросу модулей.
Думаю, что это будет интересно.
14.12.2016, 17:15
leming495

Собственно как и обещал отписываюсь после получения запаски.
Выставили параметры
Work mode "By_pool_time"
Polling time 100
Amount Repeat 3

Точно также столкнулись с ситуацией когда расширение отвалилось и на ПЛК появилась ошибка 81 правда заняло это гораздо большее время чем при выставленном Polling time 10 или Polling time 20
Сразу скажу проверялось на разных модулях ввода купленных в разных поставках. (такое ощущение что дело не в модуле)
16.12.2016, 01:00
osipov86

Имеется схожая проблема. Есть 3 ПЛК: 110-60, 110-32, 110-32. 110-60 выступает мастером сети. 110-32 слейвы. (сами проекты несколько сложнее) И при подключении одного плк 110-32, связь работает как надо. Но при подключении второго 110-32 через какое-то время появляется ошибка 81. Прошивку менял, рекомендации саппорта ОВЕНа выполнил, ничего не помогает(((
16.12.2016, 13:08
Вольд

Цитата:

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

Имеется схожая проблема. Есть 3 ПЛК: 110-60, 110-32, 110-32. 110-60 выступает мастером сети. 110-32 слейвы. (сами проекты несколько сложнее) И при подключении одного плк 110-32, связь работает как надо. Но при подключении второго 110-32 через какое-то время появляется ошибка 81. Прошивку менял, рекомендации саппорта ОВЕНа выполнил, ничего не помогает(((

Вот здесь http://www.owen.ru/forum/showthread.php?t=13585 (пункт 9) радикальное решение проблемы.
16.12.2016, 13:46
Crusash

Цитата:

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

Имеется схожая проблема. Есть 3 ПЛК: 110-60, 110-32, 110-32. 110-60 выступает мастером сети. 110-32 слейвы. (сами проекты несколько сложнее) И при подключении одного плк 110-32, связь работает как надо. Но при подключении второго 110-32 через какое-то время появляется ошибка 81. Прошивку менял, рекомендации саппорта ОВЕНа выполнил, ничего не помогает(((

организую собственный WatсhDog, а на системную ошибку даже не смотрю, много крови попортила в свое время (появлялась даже если связь по факту в норме). А ,например, с МВА8 смотрю регистр счетчика опроса какогонить канала, если счетчик не обновляется сигнализирую обрыв связи.
19.12.2016, 13:30
leming495

Цитата:

Сообщение от Вольд

Вот здесь http://www.owen.ru/forum/showthread.php?t=13585 (пункт 9) радикальное решение проблемы.

Через бибу понятное дело что все решится, т.к. там связь организовывается самостоятельно со своей обработкой ошибок. Но вопрос был не про бибу ;)

Цитата:

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

организую собственный WatсhDog, а на системную ошибку даже не смотрю, много крови попортила в свое время (появлялась даже если связь по факту в норме). А ,например, с МВА8 смотрю регистр счетчика опроса какогонить канала, если счетчик не обновляется сигнализирую обрыв связи.

Хм ну так то оно так.
Только мы тоже не по самой ошибке судим (по этой ошибке у нас просто лампа загорается для индикации).
По большому счету нам эта ошибка так чисто для информации ну и просто совпадает она с прекращением связи.
Мы смотрим по отсутствию инкремента счетчика по всем каналам. т.к. циклы замыканий у нас от 7 до 20 сек какой нить да замкнется на одном из каналов в течении 5 мин.

Судя по всему как я понимаю вариант только 1н в данном случае это писать самому по П9. А штатное средство не подходит для этого из за нестабильности.