Опять про самопроизвольную остановку ПЛК110

[JIexa21]

Всем привет!

И чтобы не было глупых вопросов, сразу отмечу: модуль Button стоит!

На объекте уже неоднократно было замечена остановка ПЛК110-60М.
Вот лог загрузки после нажатия сброса:


DATAFLASH initialized successful

Welcome to the OWEN program loader 1.3
Kernel found...
Loading kernel...
Reseting...
Checksum OK!
Load PLC core...
Main oscilator clock=15998976
Processor clock=179988480
Master clock=59996160
Waiting for check power...
Power status OK
Initialization of Power control completed
at 20080004, s=12
Initialization of Timer0 completed
Module Id=1 found
Module Id=2 found
Module Id=3 found
Module Id=103 found
Module Id=104 found
Module Id=120 found
Module Id=131 found
Module Id=190 found
Module Id=199 found
Module Id=200 found
Module Id=2000 found
Module Id=2050 found
Module Id=2051 found
Module Id=2052 found
Module Id=2053 found
Module Id=2054 found
Module Id=2055 found
Module Id=2056 found
Module Id=2057 found
Module Id=2058 found
Module Id=2059 found
Module Id=2060 found
Module Id=2061 found
Module Id=2062 found
Module Id=2063 found
Module Id=2064 found
Module Id=2065 found
Module Id=201 found
Module Id=202 found
Module Id=203 found
Module Id=210 found
Module Id=2100 found
Module Id=211 found
Module Id=250 found
Module Id=302 found
Module Id=303 found
Module Id=450 found
Module Id=451 found
Module Id=452 found
Module Id=562 found
Module Id=563 found
Module Id=570 found
Module Id=571 found
Module Id=599 found
Module Id=600 found
Module Id=601 found
Module Id=602 found
Module Id=650 found
Module Id=130 found
Module Id=221 found
Module Id=300 found
Module Id=531 found
Module Id=400 found
Module Id=402 found
Module Id=401 found
Initialization of Timer5 completed
Initialization of Timer4 completed
Test Complited USB slot is present in PLC!!!
Host is not connected
Start init USB driver !!!
Start init USB - Serial number OK.
Initialization of USB device CDC completed
Begin search and initialize I2C devices
Check for adress 77 ...DEVICE FOUND!
MCP9800 #0 OK!
Check for adress 72 ...FAILED!
Check for adress 6 ...DEVICE FOUND!
PIC upper initialized!
at 20080038, s=4
Read Flash: .at 20080040, s=4
at 20080048, s=4
..........................at 20080050, s=4
.................................................. ........................
DATAFLASH READ OK

Flash read takes 3485 ms
Start mounting FFS
Flash check takes 4699 ms
It is 0 bad blocks
Mounting of FFS completed!
Mounting takes 2654 ms
Total size of filesystem is 3145728 bytes
It is 5704 blocks
It is 440 used blocks
It is 0 bad blocks
Maximum wear level is 175 times

Reset status information.......................
PLC was reset by reset button!

Last run module Id =190
Last post module Id =131
Total control code =18
Max cache utilisation =4
local_status =4
run_level =1
Run levels stack: ff ff ff ff ff 0 0 0 0 0 0 0 0 0 0 0
................................................
at 200800a0, s=28
PLC model MODEL PLC 110-60
Binary VERSION 2.14.0
Need Target version 2.10
Compiled: 14:33:07 Apr 28 2011
MAC 6A:77:00:01:0C:E1
IP 10.0.0.4
GATE 10.0.0.1
MASK 255.255.255.0
PIC upper version is 15
Licence unlimited

Loading PLC core completed!

Start CoDeSys initialization secuence
Initialization of USB device CDC completed
Special cable detected...
Switch top RS to CoDeSys mode...

Смущает одна строка: Check for adress 72 ...FAILED!
Ну и вообще что с ним не так?

Программа в основном работает с модулем UNM: опрашивает два контроллера по MODBUS, один МВА8 и два счетчика Меркурий. При отладке были перезагрузки при работе, но вылечилось установкой пауз при опросе контроллеров и введением задержки в 1 мс при начале прослушки линии после отправки запроса по MODBUS. Глюк выражался в том что в буфер прилетала какая-то ерунда, предположительно от счетчиков, т.к. после их отключения, проблема с этими "левыми" байтами пропадала. Сама программа проверена уже неоднократно - перекрываний областей памяти нет. Так что корень проблемы видимо в работе UNM.

[Николаев Андрей]

С логом все нормально.
72 модуль - он в ПЛК с аналоговым входом.
Причина остановки не ясна, и надо разбираться. Если Button стоит - дело не в этом.
Считайте пожалуйста из ПЛК файлы Log.txt и Debug.txt и вышлите на a.prikhodko@owen.ru

[capzap]

Каков минимальный цикл работы контроллера? Просто у меня с библиотекой UNM на плк100 меньше 10мс проект не запускался, а на 150 уже хватало 5мс. Может здесь тоже что то с этим связано

[JIexa21]

Логи получится считать не скоро... Я там сам смогу на месте по ним диагностировать причину?

Цикл 1 мс. Увеличение (даже 2 мс) начинает давать сбои при работе с UNM - начинаются пропуски байтов...

Николаев Андрей и capzap - могу отправить файл программы. Сможете глянуть? :)
Тут выложить не могу - проект коммерческий и еще не сдан.

Кстати один интересный (и может быть важный) момент: когда были перезагрузки, то контроллер не всегда стартовал. Приходилось нажимать F5. Он же вроде должен сам выйти в тот режим в котором был до перезапуска?

PS Сначала грешили на разводку питания. Проверили. Нашли косяки монтажников. Переделали. Не помогло.

[capzap]

у меня нет 110 и меркуриев, так что я пас :)

[Николаев Андрей]

Файлы можно получить не мешая работе ПЛК. Подключиться CoDeSys и в ПЛК Браузере командой считать - получить оба файла.
На месте не сможете - я не уверен, что смогу. Надо показывать программистам.

Если контроллер не стартовал после перезагрузки причины в 90% всего две:
Не создан загрудочный проект, но тогда бы никогда не запускался.
Таки не стоит Button или почему то не перехватил управление. Попробуйте проверить версию Target файла, и удалить и заново поставить данный модуль.
Проект присылайте, но я не силен в программировании...

[JIexa21]

И проект загрузочный и батон стоит - ну я же не первый день программирую... :)
Таргеты проверял, переустанавливал, заодно перешивал ПЛК - этот этап уже пройден.
Кстати когда этот проект (в начальной стадии) гонял на ПЛК150 - все летало и не глючило. Только контроллер и счетчик были по одной штуке - просто модули по два раза опрашивали одни и те же адреса.
Уже склоняюсь к тому что сам контроллер не исправен - не понятно откуда берется мусор на RS485...

[capzap]

Таргеты проверял, переустанавливал, заодно перешивал ПЛК - этот этап уже пройден.
я вот засомневался что все правильно, после этой фразы. Надеюсь сперва перепрошили, а потом таргеты поставили

[JIexa21]

Прошивка и таргеты - немного разные программы. :)
Вообще в контроллере была залита последняя прошивка, таргет ставился тоже последний, который именно для этой прошивки. Контроллер перешивался уже просто от безысходности.
И если была бы несостыковка связки "прошивка-таргет", то перезагрузки были бы постоянны. Я как-то экспериментировал с соткой - контроллер даже не мог загрузится.
Сегодня узнавали - пока без перезагрузки стоит с пятницы. Простоял бы он с неправильным таргетом столько дней?

[JIexa21]

Вот логи. По debug.txt перезагрузка из-за "собаки". Попробовал увеличить время цикла, немного изменив таймауты. Хотя все равно какой-то "мусор" присутствовал (как раз его и убрал таймаутами), но перезагрузок и отключений вчера не наблюдалось. Т.к. в самой программе зависания исключены - нет бесконечных циклов и т.д., то подозреваю что ошибка где-то в работе самого UNM. Может он у вас там прерывания запрещает при приеме очередного байта? При скорости 9600 один байт будет приниматься более 1 мс (старт+стоп+8бит ~0,001042 c) и тогда можем и уложиться в один цикл, а можем и нет... Если это так, то надо этот момент внести в документацию.

[capzap]

Попробовал увеличить время цикла... ...При скорости 9600 один байт будет приниматься более 1 мс (старт+стоп+8бит ~0,001042 c) и тогда можем и уложиться в один цикл, а можем и нет... Если это так, то надо этот момент внести в документацию.

Если речь об увеличении минимального времени цикла, то этот параметр влияет только на то, что даже если все ПОУ выполнили свою работу, переход на следущий цикл не наступит пока не пройдет минимальное время. Если же проход по всей программе занимает больше минимального времени, то переход к следущему циклу наступит после окончания "прохода" программы. Злая же собака наступает, если превышает максимальное время цикла, которое по умолчанию стоит в КДС2.3 одну секунду.
Тут дело скорее всего в асинхронном запросе к микросхеме последовательного порта, ушел запрос на получение байта, а программа посчитала, что все ПОУ выполнены и перескочила на следующий цикл, а так как принять байт в предыдущий цикл не получилось, а в начале текущего цикла предположу происходит обнуление буффера контроллер зависает в ожидании значения, которое уже ни когда не придет, отсюда и срабатывания собаки. А когда увеличиваете мин.вр.цикла, тем самым гарантируете получение байта на уровне конфигурации и зависаний не происходит. И как я понял чем более новее модель ПЛК тем это время меньше

[JIexa21]

Может быть и так. Кстати более-менее устойчивой работы программы удалось добиться только после того как сделал паузу в 1мс после отправки запроса и до начала приема байтов из UNM. Что-то где-то все равно работает не правильно. Причем на уровне самого контроллера. Видел похожую тему, где именно ПЛК110-60М перегружался при опросе МВА8 через UNM. Вылечилось увеличением скорости обмена. У меня это не прокатит - счетчики работают на 9600.
Кстати, пробовал такой вариант: сделал в конфигурации два модуля UNM, но на один и тот же порт (485-1). У одного скорость 9600, у второго 57600. Значит у одного адрес 0, у второго 1. В конце опроса делал releasedevice, который нормально отрабатывает.
Чисто логически должно было работать: захватили модуль 0, опросили на 57600, освободили, захватили модуль 1, опросили на 9600, освободили... И т.д.
Но не работает. Т.е. всегда опрашивается только модуль 0!!! Проверяется легко: на нулевом модуле при скорости 9600 опрашивается только то что на 9600, а если сменить на 57600, то только то что на 57600. Естественно что на втором (1) скорости поменяны на противоположные.
А как этот косяк прокомментируют разработчики? :)