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

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

26.06.2012, 08:47
JIexa21

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

Всем привет!

И чтобы не было глупых вопросов, сразу отмечу: модуль 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.
26.06.2012, 09:13
Николаев Андрей

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

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

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

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

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

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

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

у меня нет 110 и меркуриев, так что я пас :)
26.06.2012, 14:33
Николаев Андрей

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

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

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

Цитата:

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

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

я вот засомневался что все правильно, после этой фразы. Надеюсь сперва перепрошили, а потом таргеты поставили
26.06.2012, 15:22
JIexa21

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

Вложений: 1

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

Цитата:

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

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

Если речь об увеличении минимального времени цикла, то этот параметр влияет только на то, что даже если все ПОУ выполнили свою работу, переход на следущий цикл не наступит пока не пройдет минимальное время. Если же проход по всей программе занимает больше минимального времени, то переход к следущему циклу наступит после окончания "прохода" программы. Злая же собака наступает, если превышает максимальное время цикла, которое по умолчанию стоит в КДС2.3 одну секунду.
Тут дело скорее всего в асинхронном запросе к микросхеме последовательного порта, ушел запрос на получение байта, а программа посчитала, что все ПОУ выполнены и перескочила на следующий цикл, а так как принять байт в предыдущий цикл не получилось, а в начале текущего цикла предположу происходит обнуление буффера контроллер зависает в ожидании значения, которое уже ни когда не придет, отсюда и срабатывания собаки. А когда увеличиваете мин.вр.цикла, тем самым гарантируете получение байта на уровне конфигурации и зависаний не происходит. И как я понял чем более новее модель ПЛК тем это время меньше
05.07.2012, 09:10
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) скорости поменяны на противоположные.
А как этот косяк прокомментируют разработчики? :)