Просмотр полной версии : СПК207 постоянно зависает визуализация
СПК207, залита крайняя прошивка.
Проблема - постоянно (от раза в неделю до раза в сутки) зависает визуализация.
При этом продолжает работать встроенный Linux и СПК207 можно перегрузить по SSH.
Работает в ответственном месте, и такие зависания недопустимы.
Питание там не идеальное, но стоит в железном шкафу, заземлено и блок питания достаточный (meanwell стабилизированный).
Что можно сделать?
Менять на новую модель Овна или возможны те же проблемы?
как цикл стоит у задачи визуализации, задействован ли вачдог?
12ms основная задача
100мс визуализация
Про ватчдог СПК207 сказали что он просто останавливает зависший процесс, то есть визуализация все равно не будет работать, так что не используется.
Евгений Кислов
22.04.2020, 13:04
Зависает только визуализация, приложение CODESYS (логика, обмен) продолжает работать?
Зависает только визуализация, приложение CODESYS (логика, обмен) продолжает работать?
Не удавалось проверить, СПК207 быстро перегружали чтоб возобновить работу.
Пробовать уменьшать частоту вызова задачи визуализации?
p.s.
заодно хотел спросить, забывалось, в проекте в менеджере визуализации создаются 2 идентичные визуализации
"Web-визуализация" и
"WebVisualization"
Это так надо или одну можно удалить?
Заранее спасибо
Евгений Кислов
22.04.2020, 13:13
Можно удалить ненужный узел web-визуализации.
Для определения, что происходит - надо во время зависания попробовать подключиться из CODESYS и посмотреть вкладку Device - Журнал.
Там будет информация об исключениях и ошибках.
Небольшой вопрос - если я все статические элементы на визуализации заменю на единый монолитный фон, уменьшит ли это загрузку процессора панели?
И таким образом меньше время цикла и меньше вероятность зависания.
Заранее спасибо
Евгений Кислов
23.04.2020, 16:38
Небольшой вопрос - если я все статические элементы на визуализации заменю на единый монолитный фон, уменьшит ли это загрузку процессора панели?
И таким образом меньше время цикла и меньше вероятность зависания.
Заранее спасибо
Да, уменьшит.
Можно ли получить эту информацию тз каких то файлов по ssh?
В каталоге codesyssp-wrk и тп
Заранее спасибо
Евгений Кислов
08.06.2020, 08:05
Можно ли получить эту информацию тз каких то файлов по ssh?
В каталоге codesyssp-wrk и тп
Заранее спасибо
Речь о логах?
Поищите файл PlcLog.csv - в файле CODESYSControl.cfg (в CODESYS_WRK) должен быть указан путь, по которому он сохраняется.
Но логи чистятся после перезагрузки - это надо учитывать.
Речь о логах?
Поищите файл PlcLog.csv - в файле CODESYSControl.cfg (в CODESYS_WRK) должен быть указан путь, по которому он сохраняется.
Нет ни файла, а в том что есть (CoDeSysSP.cfg) - нет строчки с путем лога
49525
если выйти на уровень выше - есть каталоги
home, lib, media, root, usr - может в них?
Спасибо
Во время работы СПК207 такие ошибки (зависания пока нет):
4967649676
2. Во время мониторинга реальное время цикла визуализации достигало 320'000 нс (320мс),
при том что время цикла задано 200мс. Может ли єто біть причиной зависания азадачи?
Сколько тогда ставить время цикла? 325? 400? 500?
Евгений Кислов
18.06.2020, 06:35
Во время работы СПК207 такие ошибки (зависания пока нет)
Эти ошибки ни на что не влияют и не могут быть причиной зависания.
Во время мониторинга реальное время цикла визуализации достигало 320'000 нс (320мс),
при том что время цикла задано 200мс. Может ли єто біть причиной зависания азадачи?
Сколько тогда ставить время цикла? 325? 400? 500?
В каком столбце отображалось это значение (320 мс) ?
Эти ошибки ни на что не влияют и не могут быть причиной зависания.
В каком столбце отображалось это значение (320 мс) ?
Max. Cycle Time (nuS).
Average Cycle Time при этом 3600 nuS (3.6 мс)
Евгений Кислов
18.06.2020, 09:55
Это значение, скорее всего, появилось в момент старта проекта.
Для получения адекватной статистики - надо после загрузки проекта выполнить сброс значений онлайн-мониторинга конфигурации задач.
Это значение, скорее всего, появилось в момент старта проекта.
Для получения адекватной статистики - надо после загрузки проекта выполнить сброс значений онлайн-мониторинга конфигурации задач.
Спасибо Евгений.
Еще вопросик: среднее время цикла 1 700 нс, макс 78 642 нс.
Это у меня плохо сделан алгоритм или нормальная ситуация?
Правильно ли при этом выставлена частота задачи 15 мс (15 000 нс) ?
Заранее спасибо
Евгений Кислов
18.06.2020, 19:07
Спасибо Евгений.
Еще вопросик: среднее время цикла 1 700 нс, макс 78 642 нс.
Это у меня плохо сделан алгоритм или нормальная ситуация?
Правильно ли при этом выставлена частота задачи 15 мс (15 000 нс) ?
Заранее спасибо
О какой именно задаче вы говорите?
Вообще, когда реальное время цикла превышает заданный интервал вызова в 5 раз - это, конечно, ненормально (если только это не выброс в момент запуска проекта).
О какой именно задаче вы говорите?
MainTask.
Ок, значит надо пересматривать проект, где может быть большая задержка.
Топик-панель СПК207.CS03.WEB
Есть такая конфигурация Мобас
Modbus Serial Port 3.4.0.0
-Modbus Master Com Port 3.5.4.0, Response1 Timeout, ms
-- Modbus_Slave_COM_Port_1 3.5.4.0, Response2 Timeout, ms
-- Modbus_Slave_COM_Port_2 3.5.4.0, Response2 Timeout, ms
-- Modbus_Slave_COM_Port_3 3.5.4.0, Response2 Timeout, ms
Не могу никак понять, почему указывается 2 таймаута - один в Мастере (Response1),
другие в Слейвах - (Response2). По какому таймауту все же определяется отказ связи ?
Кроме того в Мастере неактивным серым значится "Auto restart communication" и галка снята.
Приходится в программе вручную постоянно дергать сбросы связи чтобы возобновить обмен.
Заранее спасибо
Евгений Кислов
20.06.2020, 09:06
По какому таймауту все же определяется отказ связи ?
По таймауту, задаваемому на уровне слэйва.
Кроме того в Мастере неактивным серым значится "Auto restart communication"
Надо использовать версию мастера 3.5.5.0 - в нем эта галочка активна.
Надо использовать версию мастера 3.5.5.0 - в нем эта галочка активна.
Таргет файл 3.5.4.0, читал в руководствах что большую версию чем версия таргет не использовать. Не так прочел? Спасибо
Евгений Кислов
20.06.2020, 10:00
Таргет файл 3.5.4.0, читал в руководствах что большую версию чем версия таргет не использовать. Не так прочел? Спасибо
Это одно из редких исключений для данного правила.
В приложении Г указаны все рекомендуемые сочетания версий:
https://ftp.owen.ru/CoDeSys3/11_Documentation/01_SPK/SPK_Modbus_v.1.1.pdf
Эти ошибки ни на что не влияют и не могут быть причиной зависания.Речь об ошибках Журнала Device:
Update configuration failed from driver (Компонент CmpIoMnr)
Update configuration failed from driver (Компонент CmpIoMnr)
Update configuration failed from driver (Компонент CmpIoMnr)
Перед ними ещё есть предупреждение:
Deriving touch support from operating system not supported. Touchhandling will not be active (Компонент: CmpTagetVisu)
Эти предупреждение и ошибки появляются сразу даже на "пустом проекте". Обратил на них внимание после вылета retain на СПК207 М04->М05 (прошивка и target последние, CodeSys V3.5 SP5 P5).
Евгений, можно поподробнее рассказать про эти ошибки? Что означают, откуда они и на что-то же они влияют?
Сильно уж они напрягают, т.к. наблюдаю проблемы СПК207 с постоянной разкалибровкой экрана и вылетом retain на последних прошивках.
На прошивке 9.954 тач скрин был намного стабильнее.
Выкладываю Журнал Device для "пустого проекта". Ну уж как-то очень между записями о retain находятся записи о вышеуказанных ошибках Update configuration failed from driver (Компонент CmpIoMnr) - записи № 21-23.
Евгений Кислов
06.10.2020, 14:48
Update configuration failed from driver - это, скорее всего, связано с шаблонами Mx110.
Они созданы на базе стандартного компонента Modbus Slave, но не поддерживаю весь его функционал.
Deriving touch support from operating system not supported. Touchhandling will not be active - я не помню, с чем именно это связано, но на работу тача это не влияет.
C retain это точно никак не связано.
Update configuration failed from driver - это, скорее всего, связано с шаблонами Mx110.Евгений, спасибо за ответ, но 3 ошибки Update configuration failed from driver присутствуют в любых проектах не зависимо от наличия шаблонов Mx110. В "пустом проекте", Журнал от которого я выложил, попробовал шаблоны, но "в жизни" их не использую, а ошибки в наличии.
Deriving touch support from operating system not supported. Touchhandling will not be active - я не помню, с чем именно это связано, но на работу тача это не влияет.Можно уточнить, что это за "зверь"?
Евгений Кислов
06.10.2020, 16:26
Какая у вас именно версия таргет-файла?
Если у вас в дереве есть узлы Drives, Network и т.д. - то сообщения могут быть связаны с ними, они тоже реализованы только в том объеме, в котором было нужно, и не реализуют всех методов.
Можно уточнить, что это за "зверь"?
Точно я сказать уже не могу, но скорее всего - сообщение указывает на отсутствие поддержки multitouch.
Я хотел бы повторить основную мысль - все эти сообщения не могут влиять на работу контроллера и никак не связаны с retain.
Версия target последняя 3.5.4.26.
Евгений, возможно ли перейти на предыдущий target 3.5.4.20v24 для СПК207 М04 модифицированного до М05 и с прошивкой 5.480?
Евгений Кислов
06.10.2020, 17:31
Версия target последняя 3.5.4.26.
Евгений, возможно ли перейти на предыдущий target 3.5.4.20v24 для СПК207 М04 модифицированного до М05 и с прошивкой 5.480?
Насколько я помню - да, такая можно сделать.
Евгений, спасибо за разъяснения.
Изменил target на 3.5.4.20v24 для СПК207 М04->М05 (прошивка 5.480) в CodeSys V3.5 SP5 P5. Ошибки Update configuration failed from driver пропали. Предупреждение Deriving touch support from operating system not supported. Touchhandling will not be active осталось.
Дополнительными узлами, добавленными начиная с target 3.5.4.22 не пользуюсь, их функционал можно реализовать и через библиотеки.
Интересно другое, после даунгрейда target, пропали ошибки связи с модулями МУ110. Конфигурация такая: com2 - 6 МУ110-16К, com3 - МВ110-16ДН. Были ошибки с входным модулем, что критично для процесса. Обновил с target 3.5.4.20v24 и прошивки 3.954 на target 3.5.4.26 и прошивку 5.480. Ошибки с МВ110-16ДН ушли, но появились ошибки с выходными модулями, причем все №163 (The response is not from the expected Slave). Т.е. даунгрейд target выявил, что на появление ошибок 163 с МУ110-16К повлиял target 3.5.4.26. Причем ошибки были и на "пустом проекте", и с шаблонами, и без шаблонов. Евгений, можно получить комментарий по этой ситуации от специалистов?
В архиве есть еще такой target: 3.5.4.20v23. Возможно узнать его отличия от 3.5.4.20v24? Ещё хотелось бы узнать, чем отличается таргет 3.5.4.26 от таргетов 3.5.4.20 кроме доп.узлов?
Евгений Кислов
09.10.2020, 13:16
В архиве есть еще такой target: 3.5.4.20v23. Возможно узнать его отличия от 3.5.4.20v24?
В v24 сняли ограничение на размер пользовательского проекта (в v23 было что-то в районе 7 Мб)
Ещё хотелось бы узнать, чем отличается таргет 3.5.4.26 от таргетов 3.5.4.20 кроме доп.узлов?
Кроме узлов - ничем.
Евгений, можно получить комментарий по этой ситуации от специалистов?
Да, это возможно - напишите на support@owen.ru и предоставьте возможность удаленного подключения по TeamViewer.
C target стало всё понятно.
По появлению ошибок связи 163 (The response is not from the expected Slave) при обновлении на target "с доп.узлами", как я понял, Вы объяснения не знаете, поэтому послали на support:). Я больше месяца назад уже обращался туда по другому вопросу, вот до сих пор жду ответа, и номер заявки есть. Была надежда, что хоть Вы прольёте свет. А в TeamViewer вроде и смысла нет, сейчас с ошибками всё гладко (отдельный ФБ их считает, точнее считал).
Евгений, а может повлиять на появление ошибки 163 с новыми target время цикла MainTask в 50ms? Вроде везде в ваших документации и примерах ставится 20ms. Ранее пробовал изменять настройки связи и MainTask увеличивал, результата не было. Сейчас настройки для 6 модулей МУ110-16К: отправляется битовая маска с циклом 0.5 сек., остальные параметры рекомендуемые - время между фреймами 20мс, таймауты везде 1000мс. Общая длина линии связи 90м., терминалы есть, скорость 38400, в самих модулях настройки по умолчанию.
В любом случае, хотелось, чтобы потребитель знал, что при апгрейде ПО, может даунгрейдиться функциональность. Хорошо бы, чтобы такие особенности target были где-то указаны, тогда потребитель не будет терять время на "пляски с бубном" вокруг оборудования.
Евгений Кислов
09.10.2020, 16:30
По появлению ошибок связи 163 (The response is not from the expected Slave) при обновлении на target "с доп.узлами", как я понял, Вы объяснения не знаете, поэтому послали на support.
Безусловно - пока что не знаю. В подобных ситуациях надо разбираться как минимум при удаленном подключении, а это гораздо удобнее делать формализованным способом - через саппорт.
Евгений, а может повлиять на появление ошибки 163 с новыми target время цикла MainTask в 50ms?
Может.
В любом случае, хотелось, чтобы потребитель знал, что при апгрейде ПО, может даунгрейдиться функциональность.
Вы проецируете вашу конкретную ситуацию на все устройства/все проекты и т.д. Это понятно.
Но в данный момент я ни могу это не подтвердить, ни опровергнуть, потому что не видел, как это воспроизводится.
Опять же - в рамках общения с саппортом вы бы могли отправить свой проект, они собрали бы такую же шину у нас и посмотрели, что происходит.
OK, я на следующей неделе добавлю в "пустой проект" с target 3.5.4.26 счетчик ошибок и выложу результаты. Чтобы ни у меня, ни у Вас, ни в последующем у саппорта, не было сомнений, что проект тут ни причём.
Евгений, буду очень признателен, если Вы объясните как время цикла MainTask может повлиять на появление ошибки связи 163 (Ответ не от ожидаемого Slave)? Можно ссылку, где про это можно прочитать?
Евгений Кислов
10.10.2020, 11:11
Владимир, буду очень признателен, если вы опишите конкретную проблему, которую в данный момент пытаетесь решить.
Я прошу прощения, но немного потерял ее из виду после фразы
А в TeamViewer вроде и смысла нет, сейчас с ошибками всё гладко
Экспериментально не обнаружил влияния времени цикла MainTask в 20ms и 50ms на появление ошибок связи 163 с модулями вывода МУ110-16К.
Евгений, у СПК207[М04][М05] есть некоторые проблемы, в том числе которые пытается решить автор этой темы Dmitro: зависания, ошибки связи, непомерно большое время цикла MainTask, ну и retain - это большая проблема СПК207, которая замалчивается. Решить эти проблемы, именно решить, могут только ОВЕН и 3S, а мы, потребители, можем только как-то обходить их.
Про зависания и как их обойти писал Владимир Геннадьевич:
Была аналогичная проблема на объекте: контроллер работал несколько часов или даже сутки, потом происходило зависание панели, не отображались параметры и не работали кнопки. Помогало перезапуск по питанию. При попытки выявить данный дефект выяснилось, что в момент потери связи со слейвами и попытками контроллера программно их перезапустить получалась ситуация что связь терялась сразу со всеми слейвами и контроллер зависал. Методом "научного тыка" выяснили, если в момент зависания выдернуть шлейф из контроллера RS-485 на котором сидят слейвы и обратно вставить, то связь со слейвами восстанавливалась и контроллер начинал опять работать.
В связи с чем в программу добавили еще код перезапуска мастера сети и все стало работать.
В моём случае, зависания прекратились, когда я заменил модуль ввода МВ110-16ДН (был он один на com3) на ПР200 и "уволил" из мастеров СПК207, поставив его в slave. ПР200 оказался на голову выше СПК207 в смысле организации связи по RS-485 (и да, это рекламма ПР200:)). Был такой факт: вначале зависания СПК207 лечились перезагрузкой, а потом опытным путем выяснилось, что если после включения СПК207, его выключить и повторно включить, то в дальнейшем зависаний не возникало.
Ошибки связи, которые возникали из-за обнаруженных ошибок в ПО, как и обещал Александр Приходько, были исключены в прошивке 5.480. Да, я наблюдал, что ошибки 161 (превышен таймаут) магически пропадают при переходе на эту прошивку.
Но у меня, как я ранее писал в этой теме, появилась куча ошибок 163 (Ответ не от ожидаемого Slave). Выяснил экспериментально (прошивка 5.480) следующее: на target 3.5.4.26 эти ошибки у меня появились, так как был установлен приоритет VisuTask = 14, после изменения приоритета VisuTask = 31, ошибки 163 пропали; на target 3.5.4.20v24 ни при приоритете VisuTask = 14, ни при = 31 ошибок 163 не было.
В сообщении #16 Dmitro приводит завышенное время цикла MainTask и будет пытаться "искать задержку" в своём проекте. Очень возможно, что это будет невыполнимая задача, по подобию: "найти чёрную кошку в тёмной комнате особенно если её там нет".
У меня была подобная ситуация: выяснял почему время цикла MainTask было большим, до 100 ms. Причем переносил абсолютно всю логику в отдельную задачу и макс. время выполнения этой задачи было менее 1 ms. Выяснил, что если в проекте имеется иная кроме MainTask задача с приоритетом <= 15 (включая VisuTask), то время её выполнения влияет на время выполнения MainTask с приоритетом = 1. Увидеть это наглядно можно, когда эта иная задача скачкообразно увеличит время своего выполнения. Например, если приоритет VisuTask = 14, и при переходе на условно "тяжёлый" экран макс. время цикла VisuTask скакнёт с 10 ms до 40 ms, то вместе с ним макс. время цикла MainTask тоже скакнет и будет даже больше 40 ms. Тоже самое, например, с отдельной задачей по чтению и обработке большого файла: ставил приоритет до 15 включительно, макс. время цикла было до 80 ms и макс. время цикла MainTask при работе с файлом скакало соответственно до значений более 80 ms. Задачи с приоритетом более 15 не оказывают такого влияния на MainTask.
Такое поведение не могу объяснить в рамках вытесняющей многозадачности для овеновских ПЛК/СПК с CODESYS V3.5.
Получается какое-то зависание MainTask в момент выполнения задач с приоритетом <= 15.
Для наглядности, создал экспериментальный проект с "лёгким" MainTask, второй запускаемой вручную "тяжёлой" задачей HeavyTask, а в визуализации добавил второй "тяжёлый" экран с большой таблицей. Эксперимент проводил так: производил сброс счетчиков цикла всех задач и через 3 минуты делал "грязное дело" - запускал "тяжёлый" функционал.
Сначала приведу Monitor из конфигурации задач, когда все задачи, кроме MainTask, с приоритетом > 15:
MainTask (циклич. 20 ms) - приоритет = 1;
HeavyTask (циклич. 1000 ms) - приоритет = 16;
VISU_TASK (циклич. 200 ms) - приоритет = 31.
Прошло 2 минуты после сброса счетчиков цикла:
(макс. время цикла MainTask = 3.3 ms, HeavyTask = 0.77 ms, VISU_TASK = 11.4 ms)
51644
Непосредственно после перехода на "тяжелый" экран и включения "тяжёлой" HeavyTask:
(Заметного влияния на макс. время цикла MainTask нет.)
51645
Изменил приоритеты:
HeavyTask (циклич. 1000 ms) - приоритет = 9;
VISU_TASK (циклич. 200 ms) - приоритет = 15.
Один раз привожу Monitor из конфигурации задач через 2 минуты после сброса счетчиков цикла:
(макс. время цикла MainTask = 7 ms, HeavyTask = 0.16 ms, VISU_TASK = 3.3 ms)
51646
Перешёл на "тяжёлый" экран:
(макс. время цикла VISU_TASK = 27.7 ms повлияло на макс. время цикла MainTask = 32.3 ms)
51647
Запустил 1 цикл "тяжёлой" HeavyTask:
(макс. время цикла HeavyTask = 140 ms повлияло на макс. время цикла MainTask = 146 ms)
51648
Запустил выполнение "тяжёлой" HeavyTask, скриншот через 3 минуты работы "тяжёлой" HeavyTask:
(макс. время цикла HeavyTask = 138 ms повлияло на макс. время цикла MainTask = 146 ms и видно как сред. время цикла MainTask заметно увеличивается)
51649
Ещё один эксперимент. После сброса счетчиков цикла всех задач через 3 минуты вытащил MMC-карту из СПК207:
(На несколько секунд зависло всё, в том числе связь по RS-485, на подключенном через Ethernet CoDeSys все счетчики цикла замерли, но после зависания скакнуло только макс. время цикла MainTask до 3.2 секунды (были случаи и до 4.6 сек.). При отключении от USB Host такого не наблюдается, в т.ч. пробовал карт-ридер с той же самой MMC-картой).
51650
Теперь ошибки 163: В экспериментальном проекте в MainTask (PLC_PRG) ловлю и считаю ошибки связи с шестью модулями вывода МУ110-16К на COM2. Но после экспериментирования с "тяжёлым" функционалом, 163-х ошибок поймалось мало, за пол часа было всего две. Не имея много времени для эксперимента (делал в пересменок), изменил приоритет VisuTask с 15 на 14 и добавил COM3 со slave, как у меня в рабочем проекте.
Вот, в следующий раз, эксперимент заключался только в ловле ошибок 163:
(Ровно за час поймал 4 ошибки. Частота появления ошибок вроде не изменилась. Но за 5 рабочих дней на моём рабочем проекте было до 50 на одном модуле.)
51651
Выкладываю используемый мною проект при проведении экспериментов (с последней указаной конфигурацией):
Резюмирую написанное в предыдущих 2-х сообщениях:
Сначала поясню, откуда взялась тяга к задачам с приоритетом <= 15. В рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 для Приоритета в Конфигурации указаны рамки (0..15). Сразу замечю, что в англоязычном интерфейсе рамки (0..31). Так вот, исходя из "рекомендаций" системы и выбираются приоритеты вновь созданных задач <= 15, в т.ч. и для VisuTask. Ведь написано же - до 15!
Очень даже предполагаю, что Dmitro тоже задействовал задачи с приоритетом до 15, так как MainTask на 78 ms трудновато замутить.
Dmitro, можно ли озвучить приоритеты задач в Вашем проекте? И проверить, изменится ли ситуация с зависанием, если приоритеты задач (естественно кроме MainTask) поставить > 15?
Прошу уважаемых специалистов ОВЕН разъяснить результаты проведенных мною экспериментов:
1. Почему задачи с приоритетом до 15 так влияют на MainTask, вызывая её зависание?
2. В документе CodesysTaskManagment.pdf (https://ftp.owen.ru/CoDeSys3/98_Books/CodesysTaskManagment.pdf) есть следующие пояснения по приоритету в CODESYS V3.5:
"Для контроллеров с ОС Linux с PREEMPT RT Patch задачи с приоритетом 0…15 выполняются с
классом планирования SHED_FIFO (задачи реального времени), а задачи с приоритетом 16…31 – с
классом планирования SHED_OTHER. Более подробную информацию о классах планирования и
работе планировщика Linux можно найти в сети (например, см. эту статью (https://www.opennet.ru/man.shtml?topic=sched_setscheduler&category=2&russian=0))."
Справедливо ли это для всех овеновских ПЛК/СПК с CODESYS V3.5?
3. Почему в рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 "рекомендации" системы по приоритету (0..15)?
4. Почему извлечение карты из интерфейса SD Card, в отличии от извлечения из интерфейса USB Host, приводит к зависанию СПК207 на несколько секунд?
5. Почему target 3.5.4.26 и приоритет VisuTask так влияют на появление ошибок связи 163?
6. Александр Приходько в теме "Глобальное обновление ПО для всех СПК, программируемых в CODESYS 3.5 SP5 Patch5" писал про ошибки СПК207:
Обновление на порядок уменьшит ошибки, но полностью не избавит. Помимо программных ошибок есть аппаратная. Ее устраним в СПК207[М05] - об этом уже было написано. Сейчас для пользователей с СПК207[М04] могу дать только такие рекомендации:
1. Если хорошо программируете, то делайте обмен через библиотеку Modbus. Особенности ее реализации позволяют ошибки свести к минимуму
2. Если вы будете делать обмен через конфигурацию, то при настройке модулей МХ110 выставляйте параметр RS.DL (задержка ответа по линии RS-485) 30 мс или больше(в конфигураторе МХ110 для ПК). Проблема связана с тем, что СПК не успевает переключаться в режим чтения после отправки. Увеличение периода ответа от самих модулей поможет решить данную проблему. При этом таймаут ожидания ответа должен быть 100-150мс. Данные рекомендации приведены для скорости 115200.
Предполагаю, что наблюдаемые мною ошибки - это описанные тормоза СПК, который не успевает переключаться в режим чтения после отправки. Что же получается, в СПК207[М05] аппаратная проблема так и не была устранена или модификация СПК207[М04] в [М05] так и не произошла?
7. У СПК207[М04][М05] не так много энергонезависимой памяти, всего retain 4kB, но и те могут запросто пропасть. Подобных сообщений на форуме много. У меня уже 2-й вылет retain. Из ремонта (замены микросхемы MRAM) СПК207 не проработал месяца, после очередной заливки проекта retain пропала. 1-й раз вылетела после перехода на новейшую прошивку и, естественно, заливки проекта. И если это физическое "убийство" MRAM, то напрашивается предположение о плохой стабилизации напряжения при процессе программирования микросхем памяти. Может ли ОВЕН набраться смелости, признать проблему и хоть что-то прояснить?
Не хотелось, чтобы описанные выше проблемы СПК207 были списаны по причине снятия его с производства. Указанный СПК был самым отзывчивым (в смысле реакции на нажатия) и быстрым, даже по сравнению с выпускаемым сейчас СПК107[М01]. Хотя, большим недостатком его считаю нестандартное монтажное отверстие, что усложняет его замену.
Опасаюсь также, что проблемы некогда флагмана фирмы ОВЕН, раз они не выявлены, могут проявляться и у новых овеновских ПЛК/СПК с CODESYS V3.5, представляющих определённый интерес. И нет желания опять попасть на зависающие продукты ОВЕНа. Отсюда вопрос уважаемым специалистам ОВЕН и участникам форума: наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?
Евгений Кислов
02.11.2020, 18:09
1. Почему задачи с приоритетом до 15 так влияют на MainTask, вызывая её зависание?
Я бы не стал здесь использовать слово "зависание", но, безусловно, задачи влияют друг на друга.
Добавление "тяжеловесной" задачи с приоритетом реального времени действительно отразится на времени цикла остальных задач.
У вас это вызывает удивление?..
2. Справедливо ли это для всех овеновских ПЛК/СПК с CODESYS V3.5?
Да.
3. Почему в рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 "рекомендации" системы по приоритету (0..15)?
Банальная опечатка, в свежих версиях поправили (теперь там 0..31).
4. Почему извлечение карты из интерфейса SD Card, в отличии от извлечения из интерфейса USB Host, приводит к зависанию СПК207 на несколько секунд?
Вы извлекаете накопитель на горячую, без размонтирования?
5. Почему target 3.5.4.26 и приоритет VisuTask так влияют на появление ошибок связи 163?
На этот вопрос я не готов дать ответ.
У меня встречный вопрос:
"Но за 5 рабочих дней на моём рабочем проекте было до 50 на одном модуле" - получение 10 ответов с кодом ошибки за сутки является серьезной проблемой в рамках вашей системы?
6. Предполагаю, что наблюдаемые мною ошибки - это описанные тормоза СПК, который не успевает переключаться в режим чтения после отправки. Что же получается, в СПК207[М05] аппаратная проблема так и не была устранена или модификация СПК207[М04] в [М05] так и не произошла?
Я не готов ответить, была ли проведена доработка вашего прибора (возможно, вы можете уточнить это у сервисного центра, если доработка проводилась в рамках ремонта), но в СПК207 [М05] не наблюдалось проблем с RS-485, характерных для [М04]. С другой стороны, вы могли столкнуться с другой проблемой, которая проявляется аналогичным образом.
У меня встречный вопрос - вы пробовали проводить ваши эксперименты на "пустом" проекте (только компоненты Modbus и подсчет ошибок), без "тяжеловесных" задач, манипуляций с приоритетами и т.д.?
7. Может ли ОВЕН набраться смелости, признать проблему и хоть что-то прояснить?
Проблемы с RETAIN в СПК207 периодически возникали, но это всегда были единичные случаи, без систематики (непропай т.п.).
К сожалению, прояснить что-то здесь я не могу.
Не хотелось, чтобы описанные выше проблемы СПК207 были списаны по причине снятия его с производства.
К сожалению, у нас нет планов по доработке / исследованиям проблем приборов, снятых с производства.
наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?
Давайте мы предоставим вам СПК107 [М01] на бессрочное (сколько потребуется) тестирование?
И тогда вы сами сможете ответить на этот вопрос. =)
Евгений, спасибо за ответы, но могли бы Вы переадресовать вопросы, на которые не в компетенции ответить, разработчикам ПЛК/СПК с CODESYS V3.5?
1.
Добавление "тяжеловесной" задачи с приоритетом реального времени действительно отразится на времени цикла остальных задач. У вас это вызывает удивление?..
Ещё бОльшее удивление у меня вызывает Ваш ответ. Я нигде не акцентирую, что влияют на MainTask только "тяжелые" задачи. Я писал, что любая задача с приоритетом до 15 влияет на время цикла MainTask, увеличивая его, что в принципе при вытесняющей многозадачности не может быть! Я запускал условно "тяжёлые" задачи по команде, чтобы это влияние было хорошо заметно. Время выполнения задачи HeavyTask в моём проекте для экспериментов можно изменять, попробуйте, и увидите, что с любым временем задача HeavyTask (обязательное условие - приоритет до 15) будет тормозить MainTask.
Посмотрите 1-й и 3-й скриншоты моих экспериментов (https://owen.ru/forum/showthread.php?t=33124&p=342362&viewfull=1#post342362) без выполнения "тяжелого" функционала. Макс. время цикла MainTask = 3.3 ms, если остальные задачи с приоритетом > 15 и макс. время цикла MainTask = 7 ms, если остальные задачи с приоритетом <= 15. И это один и тот же проект! Тут же можно увидеть, что макс. время цикла VISU_TASK = 11.4 ms (приоритеты > 15) и = 3.3 ms (приоритеты <= 15). И эти результаты стабильные. Получается какая-то вытесняющая многозадачность наоборот! Во втором случае (приоритеты <= 15) задача VISU_TASK с меньшим приоритетом вытесняет задачу MainTask с большим приоритетом. Да, для меня это нонсенс! В первом случае (приоритеты > 15) все логично с точки зрения вытесняющей многозадачности.
Кроме того, влияние задач с приоритетами до 15 избирательно, друг на друга они никакого влияния не оказывают (см. 4, 5, и 6 скриншоты (https://owen.ru/forum/showthread.php?t=33124&p=342362&viewfull=1#post342362)). Зависает исключительно MainTask.
Уважаемые специалисты ОВЕН, разъясните, пожалуйста, зависание (увеличение времени цикла, вопреки вытесняющей многозадачности) MainTask (только MainTask!) при наличии иных задач с приоритетом до 15.
4.
Вы извлекаете накопитель на горячую, без размонтирования?
В моём проекте для экспериментов нет функционала с размонтированием. Причём ранее я лично интересовался у Александра Приходько на семинаре о необходимости такого функционала. Он его не рекомендовал, единственное условие для извлечения - отсутствие обращения к накопителю. В представленном проекте для эксперимента отсутствует функционал работы с накопителями вообще. И здесь, в вопросе, я указываю дополнительно на различие извлечения накопителей из интерфейсов SD Card и USB Host. Извлечение накопителя из интерфейса USB Host никакого влияния на работоспособность проекта не вызывает, в отличии от извлечения накопителя из интерфейса SD Card, приводящего к зависанию СПК207 на несколько секунд. Уважаемые специалисты ОВЕН, разъясните ситуацию.
5,6.
С другой стороны, вы могли столкнуться с другой проблемой, которая проявляется аналогичным образом.
Евгений, можно поподробнее, пожалуйста?
Отвечаю сразу на "встречные вопросы". Эксперимент по ловле ошибок связи можно сказать как раз и был на "пустом" проекте - ошибки были пойманы при выключенной задаче HeavyTask и без перехода по экранам. И я не замечал влияния "тяжёлого" функционала на появление ошибок связи, они "живут" своей жизнью. Да, и на полностью "пустом" другом проекте с приоритетом VisuTask = 14 ошибки были, наблюдал красные треугольнички на модулях Modbus. А про манипуляцию с приоритетами я что-то не понял, чтобы поменять приоритет надо вроде обновить проект, что в рамках одного эксперимента невозможно. У меня получилась явная зависимость появления ошибок связи от target и приоритета VisuTask. Причем target 3.5.4.26 и приоритет VisuTask = 14 исключительно любят ошибки связи 163, на приоритете VisuTask = 15 были и ошибки 161. Может статистика не полная, но на рабочем проекте (target 3.5.4.26 и приоритет VisuTask = 14) на протяжении продолжительного времени я наблюдал очень частые исключительно ошибки 163; с приоритетом VisuTask = 31 на target 3.5.4.26 всё изумительно, но не так много времени наблюдал. Вопросы про ошибки связи я поднимаю не потому, что у кого-то есть проблема в рамках системы, а потому, что по заверениям "фирмы" "в СПК207 [М05] не наблюдалось проблем с RS-485, характерных для [М04]". А наш СПК207 отправлялся в сервис как раз для модификации в [М05], и есть бумажка, в которой написано о проделанных соответствующих манипуляциях.
Поэтому вопросы к специалистам ОВЕН остаются: по влиянию target 3.5.4.26 и приоритета VisuTask на появление ошибок связи 163; по исправлению в СПК207[М05] аппаратной проблемы, влияющей на появление ошибок связи, она так и не устранена или модификация СПК207[М04] в [М05] является неполноценной?
7.
Проблемы с RETAIN в СПК207 периодически возникали, но это всегда были единичные случаи, без систематики (непропай т.п.).
Очень странный ответ, словосочетания "периодически возникали" и "единичные случаи" мне кажутся несовместимыми. А случаи, как видно по сообщениям форума, ну не единичны.
И все-таки, могут ли специалисты ОВЕН прояснить ситуацию с вылетом retain у СПК207?
К сожалению, у нас нет планов по доработке / исследованиям проблем приборов, снятых с производства.
Я не прошу у ОВЕН подобных жертв и как раз таким ответом на перечисленные проблемы СПК207 просил "не отфутболивать".
Важно для все ещё пользователей СПК207 разъяснения по приведенным проблемам, чтобы их хотя бы грамотно обходить, а не плясать с бубном вокруг оборудования. А для современных ПЛК/СПК с CODESYS V3.5 хотелась работа над ошибками и исключения, извиняюсь за выражение, "косяков" старых приборов. Если с современными приборами всё хорошо, то я очень рад, но судя по предварительным ответам Евгения, особенно по 1-му вопросу, есть сомнения.
Давайте мы предоставим вам СПК107 [М01] на бессрочное (сколько потребуется) тестирование?
И тогда вы сами сможете ответить на этот вопрос. =)
Евгений, спасибо за предложение. Но я не очень представляю, как я вместо СПК207 воткну СПК107? Монтажные отверстия приборов сильно отличаются. А Вам или другим участникам форума, думаю не сложно будет залить в современные ПЛК/СПК с CODESYS V3.5 представленный мною проект, или поэкспериментировать со своим проектом и произвести описанные мною манипуляции. А вытащить накопитель из интерфейсов SD Card и USB Host можно без изменений проекта, просто подключившись к ПК для мониторинга. Результатом и будет ответ на мой вопрос: наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?
Евгений Кислов
03.11.2020, 19:25
могли бы Вы переадресовать вопросы, на которые не в компетенции ответить, разработчикам ПЛК/СПК с CODESYS V3.5?
Хорошо.
Причём ранее я лично интересовался у Александра Приходько на семинаре о необходимости такого функционала. Он его не рекомендовал, единственное условие для извлечения - отсутствие обращения к накопителю.
Тут мне сложно дать комментарии - возможно, Александр неверно выразил свою мысль, или не понял вопрос, или это было настолько давно, что у него еще не было точной информации об особенностях работы с накопителями. Не думаю, что сейчас он бы дал такой ответ.
Извлечение накопителя из интерфейса USB Host никакого влияния на работоспособность проекта не вызывает, в отличии от извлечения накопителя из интерфейса SD Card, приводящего к зависанию СПК207 на несколько секунд. Уважаемые специалисты ОВЕН, разъясните ситуацию.
USB и SD - это разные устройства, которые обрабатываются разными драйверами, у которых разные приоритеты прерываний.
Поэтому извлечение разных типов накопителей оказывает разный эффект на работу контроллера.
Но я не очень представляю, как я вместо СПК207 воткну СПК107?
Я не предлагал вам использовать его вместо СПК207. Просто имея на руках прибор - вы могли бы довольно быстро получить на некоторые ваши вопросы ответы, в которых вам не пришлось бы сомневаться.
А вытащить накопитель из интерфейсов SD Card и USB Host можно без изменений проекта, просто подключившись к ПК для мониторинга.
В четверг повторю ваш опыт на СПК1хх [М01] и отпишусь по результатам. По изучению влияния цикла задач друг на друга - проверю, когда будет время.
Евгений, можно поподробнее, пожалуйста?
Я не очень понимаю, какие подробности нужны в рамках моего комментария; по-моему, его смысл однозначен.
Мне, например, не очень понятно, как вы почти в соседних предложениях сочетаете фразы "....аппаратной проблемы, влияющей на появление ошибок связи, она так и не устранена или модификация СПК207[М04] в [М05] является неполноценной?" и "с приоритетом VisuTask = 31 на target 3.5.4.26 всё изумительно".
Евгений Кислов
05.11.2020, 09:57
Потестировал ваш проект на СПК1хх [М01].
Приоритеты оставил такие, как в выложенном файле - 9 для HeavyTask и 14 для VisuTask.
У неявно создаваемой в новых таргетах OwenCloudTask приоритет равен 31.
Нагрузочный код "тяжелой" задачи выполнялся циклически ( heavyenable := TRUE; ).
Вот информация мониторинга задач:
51723
Видно, что задачу MainTask никто не вытесняет и что у задач с самыми высокими приоритетами (MainTask, HeavyTask) наименьшее значение джиттера.
Я могу предположить, что в рамках своих тестов вы наблюдаете баги планировщика задач старой версии системы исполнения, которые к настоящему моменту уже исправлены.
Стоит отметить интересный момент - при наличии ошибок по таймуту периодически будут "выбросы" в значениях времени цикла MainTask, потому что в данном проекте (и, в принципе, в большинстве проектов) обмен выполняется в контекте MainTask (которая по умолчанию является задачей цикла шина для Modbus-компонентов). Мы отразим это в документации при ее обновлении.
По поводу извлечения USB- и SD-накопителей - вывел на график время цикла MainTask в микросекундах.
Красная черта - момент, когда я извлек накопитель (на горячую).
Как можно заметить - время цикла MainTask не дрогнуло.
51724 51725
Но опять же - и версия ОС, и версия рантайма со времен СПК207 сильно поменялись.
В них устранено множество недочетов старых версий.
Я не очень понимаю, какие подробности нужны в рамках моего комментария; по-моему, его смысл однозначен.
Евгений, в Вашем сообщении была фраза: "С другой стороны, вы могли столкнуться с другой проблемой, которая проявляется аналогичным образом." Вот я и решил, что Вы знаете эту "другую проблему", из-за которой появляются ошибки связи, и попросил раскрыть её. Но судя по Вашему ответу, "другая проблема" Вам не известна, а смысл Вашей фразы - "Всё может быть".
Мне, например, не очень понятно, как вы почти в соседних предложениях сочетаете фразы "....аппаратной проблемы, влияющей на появление ошибок связи, она так и не устранена или модификация СПК207[М04] в [М05] является неполноценной?" и "с приоритетом VisuTask = 31 на target 3.5.4.26 всё изумительно".
Поясняю, хотя должно быть и так всё понятно. Фирма рапортует, что аппаратная проблема, влияющая на появление ошибок связи, устранена, а до этого исправлялось ПО тоже с этой-же целью. В заявлениях нет уточнений, что ошибки устранены только для определённой конфигурации, например для приоритета VisuTask = 31. То есть, для любой конфигурации ситуация с ошибками должна быть одинаковой - их не должно быть. Я же наблюдаю зависимость интенсивности ошибок связи и их типа от приоритета VisuTask на target 3.5.4.26. А ещё я писал, что для приоритета VisuTask = 31 на target 3.5.4.26 я ситуацию мониторил не так много времени.
Потестировал ваш проект на СПК1хх [М01].
Я могу предположить, что в рамках своих тестов вы наблюдаете баги планировщика задач старой версии системы исполнения, которые к настоящему моменту уже исправлены.
Евгений, огромное спасибо За Ваш эксперимент. Я рад за новые СПК.
В документе (https://ftp.owen.ru/CoDeSys3/98_Books/CodesysTaskManagment.pdf) написано: "На большинстве контроллеров с ОС Linux (с PREEMPT RT Patch) используется вариант активации 3.3 (планированием задач CODESYS занимается планировщик ОС) и внутреннее квантование. Это справедливо и для контроллеров ОВЕН (ПЛК2хх, СПК1хх)."
Поэтому я не совсем понимаю Ваше предположение. Ведь система исполнения для СПК207 - это CodeSys V3.5 SP5 P5, а планировщик задач в этом случае - это Linux. Ведь приведенная мною цитата справедлива и для ОВЕН СПК207?
В любом случае, возникает вопрос, а может ли измениться ситуация с СПК207 при переходе например на SP14 с соответствующим профилем? А SP5 тогда убрать с сайта как "вредную"? Евгений, можно, пожалуйста, рекомендации по этому поводу?
Евгений Кислов
05.11.2020, 16:22
Ведь система исполнения для СПК207 - это CodeSys V3.5 SP5 P5, а планировщик задач в этом случае - это Linux. Ведь приведенная мною цитата справедлива и для ОВЕН СПК207?
Тем не менее, в рантайме все равно есть прослойка, которая связывает задачи CODESYS с планировщиком ОС (CmpSchedule, SysTask и т.д.).
В ней тоже могли быть ошибки. Ну и строго говоря - в планировщике ОС тоже они могли быть.
В любом случае, возникает вопрос, а может ли измениться ситуация с СПК207 при переходе например на SP14 с соответствующим профилем?
Я думаю - ситуация не изменится.
Добрый день
Опять обращаюсь со старой проблемой, которую долгие годы не могу решить.
Периодически зависает СПК207.
Подключение по SSH остается работать (через него делаю ssh busybox reboot для возобновления работы СПК).
Хранятся ли возникающие сбои в каком-то файле в памяти контроллера (чтобы скачать их по scp)?
Вот что я нашел в файловой системе СПК
53071
Заранее спасибо
Евгений Кислов
19.01.2021, 17:12
Добрый день
Опять обращаюсь со старой проблемой, которую долгие годы не могу решить.
Периодически зависает СПК207.
Подключение по SSH остается работать (через него делаю ssh busybox reboot для возобновления работы СПК).
Хранятся ли возникающие сбои в каком-то файле в памяти контроллера (чтобы скачать их по scp)?
Вот что я нашел в файловой системе СПК
53071
Заранее спасибо
Добрый день.
Если меня не подводит память, то в СПК207 логи CODESYS лежат в /var/log
Добрый день.
Если меня не подводит память, то в СПК207 логи CODESYS лежат в /var/log
Евгений, память превосходная! Спасибо!!
Вот лог. По-прежнему не понятно почему висим...
[ 0.000000] Linux version 3.2.0-rt10 (oleg@Oleg-buildpc) (gcc version 4.3.2 (GCC) ) #1 PREEMPT RT Tue Sep 5 17:41:20 MSK 2017
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: owen_am335x
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 32768
[ 0.000000] free_area_init_node: node 0, pgdat c06e2fb8, node_mem_map c0711000
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32512 pages, LIFO batch:7
[ 0.000000] really allocated: s=4096, a=c0812000
[ 0.000000] Retain memory: size=4096, address=0x80812000
[ 0.000000] AM335X ES2.1 (sgx neon )
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: mtdparts=omap2-nand.0:0x80000(SPL),0x1a0000(u-boot),0x40000(logo),0x20000(u-boot-env),0x500000(kernel),0x5880000(rootfs),0x2000000( userfs) console=ttyS0,115200n8 root=ubi0:rfs rootfstype=ubifs ro ubi.mtd=5 ubi.mtd=6 consoleblank=0 eth=6A:77:00:82:1F:1D display=AT070TN83 hw_ver=0 logo.owen=Owen
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 128MB = 128MB total
[ 0.000000] Memory: 122664k/122664k available, 8408k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc053c000 (5328 kB)
[ 0.000000] .init : 0xc053c000 - 0xc0690000 (1360 kB)
[ 0.000000] .data : 0xc0690000 - 0xc06ec7c8 ( 370 kB)
[ 0.000000] .bss : 0xc06ec7ec - 0xc07101a4 ( 143 kB)
[ 0.000000] NR_IRQS:444
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER2 at 25000000 Hz
[ 0.000000] omap_dm_timer_switch_src: Switching to HW default clocksource(sys_clkin_ck) for timer1, this may impact timekeeping in low power state
[ 0.000000] OMAP clocksource: GPTIMER1 at 25000000 Hz
[ 0.000000] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798ms
[ 0.000000] Console: colour dummy device 80x30
[ 0.000379] Calibrating delay loop... 548.86 BogoMIPS (lpj=2744320)
[ 0.046614] pid_max: default: 32768 minimum: 301
[ 0.046818] Security Framework initialized
[ 0.046955] Mount-cache hash table entries: 512
[ 0.047540] CPU: Testing write buffer coherency: ok
[ 0.048903] devtmpfs: initialized
[ 0.070905] omap_hwmod: pruss: failed to hardreset
[ 0.072605] print_constraints: dummy:
[ 0.073192] NET: Registered protocol family 16
[ 0.076986] OMAP GPIO hardware version 0.1
[ 0.081709] omap_mux_init: Add partition: #1: core, flags: 0
[ 0.083064] Detect AT070TN83 display
[ 0.083314] omap_hsmmc.0: alias fck already exists
[ 0.086237] omap_i2c.1: alias fck already exists
[ 0.087136] davinci-mcasp.0: alias fck already exists
[ 0.089471] _regulator_get: l3_main.0 supply vdd_core not found, using dummy regulator
[ 0.089600] am335x_opp_update: physical regulator not present for core(-22)
[ 0.090030] registered am33xx_sr device
[ 0.090556] d_can.0: alias fck already exists
[ 0.090938] _omap_mux_init_gpio: Could not set gpio48
[ 0.090957] _omap_mux_init_gpio: Could not set gpio49
[ 0.090972] _omap_mux_init_gpio: Could not set gpio50
[ 0.090987] _omap_mux_init_gpio: Could not set gpio51
[ 0.091003] _omap_mux_init_gpio: Could not set gpio52
[ 0.091017] _omap_mux_init_gpio: Could not set gpio53
[ 0.091032] _omap_mux_init_gpio: Could not set gpio54
[ 0.091047] _omap_mux_init_gpio: Could not set gpio55
[ 0.091062] _omap_mux_init_gpio: Could not set gpio56
[ 0.091077] _omap_mux_init_gpio: Could not set gpio57
[ 0.091442] _omap_mux_init_gpio: Could not set gpio19
[ 0.091460] _omap_mux_init_gpio: Could not set gpio65
[ 0.091779] Hw_ver=0
[ 0.092146] da8xx_lcdc.0: alias fck already exists
[ 0.093059] omap2_mcspi.1: alias fck already exists
[ 0.093462] omap2_mcspi.2: alias fck already exists
[ 0.093928] edma.0: alias fck already exists
[ 0.093957] edma.0: alias fck already exists
[ 0.093983] edma.0: alias fck already exists
[ 0.129069] bio: create slab <bio-0> at 0
[ 0.133486] SCSI subsystem initialized
[ 0.142665] usbcore: registered new interface driver usbfs
[ 0.143181] usbcore: registered new interface driver hub
[ 0.143522] usbcore: registered new device driver usb
[ 0.144053] registerd cppi-dma Intr @ IRQ 17
[ 0.144071] Cppi41 Init Done Qmgr-base(c887a000) dma-base(c8878000)
[ 0.144085] Cppi41 Init Done
[ 0.144120] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13, plat_mode=0x3
[ 0.144571] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13, plat_mode=0x1
[ 0.147372] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[ 0.149786] tps65910 1-002d: JTAGREVNUM 0x1
[ 0.152545] print_constraints: VRTC:
[ 0.154231] print_constraints: VIO: at 1800 mV
[ 0.157176] print_constraints: VDD1: 950 <--> 1300 mV at 1100 mV normal
[ 0.159876] print_constraints: VDD2: 950 <--> 1300 mV at 1100 mV normal
[ 0.161091] print_constraints: VDD3: 5000 mV
[ 0.162734] print_constraints: VDIG1: at 1800 mV
[ 0.164372] print_constraints: VDIG2: at 1800 mV
[ 0.166047] print_constraints: VPLL: at 1800 mV
[ 0.167799] print_constraints: VDAC: at 1800 mV
[ 0.169496] print_constraints: VAUX1: at 1800 mV
[ 0.171172] print_constraints: VAUX2: at 3300 mV
[ 0.172841] print_constraints: VAUX33: at 3300 mV
[ 0.174479] print_constraints: VMMC: at 3300 mV
[ 0.175050]
[ 0.175056]
------Read default DCDCCtrl=38-(ofset=3e)--------
[ 0.175068]
------Setting VDD1=1.1v-----------
[ 0.175841]
------Setting VDD2=1.1v------------
[ 0.177041]
------Setting VDD1=1.1v-----------
[ 0.178575]
------Setting VDD2=1.1v------------
[ 0.179664]
------Setting VDD1=1.1v-----------
[ 0.181194]
------Setting VDD2=1.1v------------
[ 0.182284]
[ 0.183495]
------Writed new value of DCDCCtrl=38-(ofset=3e)--------
[ 0.183508]
[ 0.184300] tps65910 1-002d: No interrupt support, no core IRQ
[ 0.186362] Advanced Linux Sound Architecture Driver Version 1.0.24.
[ 0.187811] Switching to clocksource gp timer
[ 0.221989] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[ 0.222190] musb-hdrc musb-hdrc.0: dma type: dma-cppi41
[ 0.222663] MUSB0 controller's USBSS revision = 4ea20800
[ 0.222693] TxFifo Empty intr disabled
[ 0.222707] musb0: Enabled SW babble control
[ 0.223074] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.223102] musb-hdrc: MHDRC RTL version 2.0
[ 0.223116] musb-hdrc: setup fifo_mode 4
[ 0.223154] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 0.223175] musb-hdrc.0: bulk split disabled
[ 0.223187] musb-hdrc.0: bulk combine disabled
[ 0.224159] musb-hdrc musb-hdrc.0: USB OTG mode controller at c883c000 using DMA, IRQ 18
[ 0.224430] musb-hdrc musb-hdrc.1: dma type: dma-cppi41
[ 0.224874] MUSB1 controller's USBSS revision = 4ea20800
[ 0.224903] TxFifo Empty intr disabled
[ 0.224915] musb1: Enabled SW babble control
[ 0.225269] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.225295] musb-hdrc: MHDRC RTL version 2.0
[ 0.225309] musb-hdrc: setup fifo_mode 4
[ 0.225346] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 0.225364] musb-hdrc.1: bulk split disabled
[ 0.225376] musb-hdrc.1: bulk combine disabled
[ 0.225622] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
[ 0.225672] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
[ 0.225867] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.225889] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.225908] usb usb1: Product: MUSB HDRC host driver
[ 0.225924] usb usb1: Manufacturer: Linux 3.2.0-rt10 musb-hcd
[ 0.225939] usb usb1: SerialNumber: musb-hdrc.1
[ 0.227373] hub 1-0:1.0: USB hub found
[ 0.227418] hub 1-0:1.0: 1 port detected
[ 0.228931] musb-hdrc musb-hdrc.1: USB Host mode controller at c883e800 using DMA, IRQ 19
[ 0.229604] NET: Registered protocol family 2
[ 0.229904] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.230372] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.230523] TCP bind hash table entries: 4096 (order: 4, 98304 bytes)
[ 0.230785] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.230804] TCP reno registered
[ 0.230821] UDP hash table entries: 64 (order: 0, 4096 bytes)
[ 0.230884] UDP-Lite hash table entries: 64 (order: 0, 4096 bytes)
[ 0.231264] NET: Registered protocol family 1
[ 0.231651] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.231936] omap-gpmc omap-gpmc: GPMC revision 6.0
[ 0.231962] Registering NAND on CS0
[ 0.242149] VFS: Disk quotas dquot_6.5.2
[ 0.242221] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.242947] NTFS driver 2.1.30 [Flags: R/W].
[ 0.243329] aufs 3.2-20130923
[ 0.243365] msgmni has been set to 239
[ 0.244707] io scheduler noop registered
[ 0.244723] io scheduler deadline registered
[ 0.244818] io scheduler cfq registered (default)
[ 0.246738] da8xx_lcdc da8xx_lcdc.0: GLCD: Found AT070TN83 panel
[ 0.261806] Console: switching to colour frame buffer device 100x30
[ 0.273215] omap_uart.0: ttyS0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[ 1.121725] console [ttyS0] enabled
[ 1.123756] omap_uart.2: ttyS2 at MMIO 0x48022000 (irq = 73) is a OMAP UART2
[ 1.125547] omap_uart.3: ttyS3 at MMIO 0x48024000 (irq = 74) is a OMAP UART3
[ 1.128789] omap_uart.1: ttyS1 at MMIO 0x481a6000 (irq = 44) is a OMAP UART1
[ 1.129681] omap_uart.4: ttyS4 at MMIO 0x481a8000 (irq = 45) is a OMAP UART4
[ 1.130541] omap_uart.5: ttyS5 at MMIO 0x481aa000 (irq = 46) is a OMAP UART5
[ 1.149361] brd: module loaded
[ 1.158781] loop: module loaded
[ 1.162581] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.163308] omap2-nand driver initializing
[ 1.163775] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
[ 1.163853] 7 cmdlinepart partitions found on MTD device omap2-nand.0
[ 1.163871] Creating 7 MTD partitions on "omap2-nand.0":
[ 1.163897] 0x000000000000-0x000000080000 : "SPL"
[ 1.166654] 0x000000080000-0x000000220000 : "u-boot"
[ 1.170208] 0x000000220000-0x000000260000 : "logo"
[ 1.172620] 0x000000260000-0x000000280000 : "u-boot-env"
[ 1.174916] 0x000000280000-0x000000780000 : "kernel"
[ 1.179776] 0x000000780000-0x000006000000 : "rootfs"
[ 1.220069] 0x000006000000-0x000008000000 : "userfs"
[ 1.236344] OneNAND driver initializing
[ 1.237555] UBI: attaching mtd5 to ubi0
[ 1.237577] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 1.237593] UBI: logical eraseblock size: 126976 bytes
[ 1.237606] UBI: smallest flash I/O unit: 2048
[ 1.237621] UBI: VID header offset: 2048 (aligned 2048)
[ 1.237635] UBI: data offset: 4096
[ 2.152817] UBI: max. sequence number: 538
[ 2.168337] UBI: attached mtd5 to ubi0
[ 2.168354] UBI: MTD device name: "rootfs"
[ 2.168368] UBI: MTD device size: 88 MiB
[ 2.168380] UBI: number of good PEBs: 708
[ 2.168392] UBI: number of bad PEBs: 0
[ 2.168404] UBI: number of corrupted PEBs: 0
[ 2.168415] UBI: max. allowed volumes: 128
[ 2.168427] UBI: wear-leveling threshold: 4096
[ 2.168439] UBI: number of internal volumes: 1
[ 2.168451] UBI: number of user volumes: 1
[ 2.168462] UBI: available PEBs: 0
[ 2.168474] UBI: total number of reserved PEBs: 708
[ 2.168486] UBI: number of PEBs reserved for bad PEB handling: 7
[ 2.168502] UBI: max/mean erase counter: 4/1
[ 2.168514] UBI: image sequence number: 0
[ 2.168558] UBI: attaching mtd6 to ubi1
[ 2.168577] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 2.168592] UBI: logical eraseblock size: 126976 bytes
[ 2.168605] UBI: smallest flash I/O unit: 2048
[ 2.168619] UBI: VID header offset: 2048 (aligned 2048)
[ 2.168633] UBI: data offset: 4096
[ 2.177923] UBI: background thread "ubi_bgt0d" started, PID 510
[ 2.560398] UBI: max. sequence number: 3556
[ 2.574896] UBI: attached mtd6 to ubi1
[ 2.574911] UBI: MTD device name: "userfs"
[ 2.574924] UBI: MTD device size: 32 MiB
[ 2.574937] UBI: number of good PEBs: 256
[ 2.574948] UBI: number of bad PEBs: 0
[ 2.574960] UBI: number of corrupted PEBs: 0
[ 2.574971] UBI: max. allowed volumes: 128
[ 2.574983] UBI: wear-leveling threshold: 4096
[ 2.574995] UBI: number of internal volumes: 1
[ 2.575006] UBI: number of user volumes: 1
[ 2.575017] UBI: available PEBs: 0
[ 2.575029] UBI: total number of reserved PEBs: 256
[ 2.575041] UBI: number of PEBs reserved for bad PEB handling: 2
[ 2.575057] UBI: max/mean erase counter: 26/14
[ 2.575068] UBI: image sequence number: 0
[ 2.575248] UBI: background thread "ubi_bgt1d" started, PID 513
[ 2.576674] CAN device driver interface
[ 2.576690] CAN bus driver for Bosch D_CAN controller 1.0
[ 2.578081] d_can d_can.0: device registered (irq=52, irq_obj=53)
[ 2.627880] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[ 2.627902] davinci_mdio davinci_mdio.0: detected phy mask ffff7fff
[ 2.628806] davinci_mdio.0: probed
[ 2.628827] davinci_mdio davinci_mdio.0: phy[15]: device 0:0f, driver NS DP83848C 10/100 Mbps PHY
[ 2.629442] usbcore: registered new interface driver cdc_ether
[ 2.629716] usbcore: registered new interface driver cdc_eem
[ 2.629992] usbcore: registered new interface driver dm9601
[ 2.630069] cdc_ncm: 04-Aug-2011
[ 2.630350] usbcore: registered new interface driver cdc_ncm
[ 2.630370] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.630692] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.631315] usbcore: registered new interface driver cdc_acm
[ 2.631331] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 2.631349] Initializing USB Mass Storage driver...
[ 2.631719] usbcore: registered new interface driver usb-storage
[ 2.631737] USB Mass Storage support registered.
[ 2.632764] mousedev: PS/2 mouse device common for all mice
[ 2.633088] stepconfigx =80432
[ 2.633103] stepconfigy =312
[ 2.633114] charge =88120
[ 2.633123] steps =1fff
[ 2.633752] input: ti-tsc as /devices/platform/omap/ti_tscadc/tsc/input/input0
[ 2.638099] rtc-ds1307 1-006f: rtc core: registered mcp7941x as rtc0
[ 2.658010] tps65910-rtc tps65910-rtc: rtc core: registered tps65910-rtc as rtc1
[ 2.658310] i2c /dev entries driver
[ 2.678020] lm75 1-0048: hwmon0: sensor 'tmp75'
[ 2.687966] OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 2.707975] cpuidle: using governor ladder
[ 2.708830] cpuidle: using governor menu
[ 2.720308] Registered led device: buzzer
[ 2.720655] Registered led device: ready
[ 2.726218] Registered led device: sv1
[ 2.726787] Registered led device: sv2
[ 2.727339] Registered led device: sv3
[ 2.738008] Registered led device: sv4
[ 2.738613] Registered led device: sv5
[ 2.739180] Registered led device: sv6
[ 2.739742] Registered led device: sv7
[ 2.740297] Registered led device: sv8
[ 2.740896] Registered led device: mstr485_1
[ 2.748038] Registered led device: mstr485_2
[ 2.778042] usbcore: registered new interface driver usbhid
[ 2.778059] usbhid: USB HID core driver
[ 2.779219] tiadc tiadc: attached adc driver
[ 2.784705] usbcore: registered new interface driver snd-usb-audio
[ 2.799498] _regulator_get: 1-0018 supply IOVDD not found, using dummy regulator
[ 2.799595] _regulator_get: 1-0018 supply DVDD not found, using dummy regulator
[ 2.799687] _regulator_get: 1-0018 supply AVDD not found, using dummy regulator
[ 2.799767] _regulator_get: 1-0018 supply DRVDD not found, using dummy regulator
[ 2.803778] asoc: tlv320aic3x-hifi <-> davinci-mcasp.0 mapping ok
[ 2.814110] ALSA device list:
[ 2.814127] #0: AM335X SOM02
[ 2.814219] TCP cubic registered
[ 2.814236] NET: Registered protocol family 17
[ 2.814287] can: controller area network core (rev 20090105 abi 8)
[ 2.814502] NET: Registered protocol family 29
[ 2.814548] can: raw protocol (rev 20090105)
[ 2.814565] can: broadcast manager protocol (rev 20090105 t)
[ 2.814588] Registering the dns_resolver key type
[ 2.814692] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 2.814725] ThumbEE CPU extension supported.
[ 2.814805] mux: Failed to setup hwmod io irq -22
[ 2.816225] Power Management for AM33XX family
[ 2.816736] Trying to load am335x-pm-firmware.bin (60 secs timeout)
[ 2.816878] Copied the M3 firmware to UMEM
[ 2.817233] DIEID: 1402d00e 014fc111 00000000 1daa0002
[ 2.817247] EFUSE SMA register val = 00013e2f
[ 2.817277] Compensating OPP0: Orig nvalue:0x99c7b9 New nvalue:0x99c7b9
[ 2.817297] Compensating OPP1: Orig nvalue:0x999084 New nvalue:0x999084
[ 2.817462] Cortex M3 Firmware Version = 0x18
[ 2.819159] Compensating OPP0: Orig nvalue:0x99bdb1 New nvalue:0x99bdb1
[ 2.819181] Compensating OPP1: Orig nvalue:0x999083 New nvalue:0x999083
[ 2.819201] Compensating OPP2: Orig nvalue:0xaae8d4 New nvalue:0xaae8d4
[ 2.819219] Compensating OPP3: Orig nvalue:0xaac8b7 New nvalue:0xaac8b7
[ 2.819239] Compensating OPP4: Orig nvalue:0xaac8b7 New nvalue:0xaa998e
[ 2.827991] create_regulator: VDD1: Failed to create debugfs directory
[ 2.829852] smartreflex smartreflex: am33xx_sr_probe: Driver initialized
[ 2.851849] clock: disabling unused clocks to save power
[ 2.869045] Detected MACID=6a:77:0:82:1f:1d
[ 2.870907] cpsw: Detected MACID = d0:5f:b8:f9:2b:70
[ 2.898758] input: gpio-keys as /devices/platform/gpio-keys/input/input1
[ 2.900773] rtc-ds1307 1-006f: setting system clock to 2021-01-16 21:43:53 UTC (1610833433)
[ 3.249823] UBIFS: mounted UBI device 0, volume 0, name "rfs"
[ 3.249841] UBIFS: mounted read-only
[ 3.249856] UBIFS: file system size: 83042304 bytes (81096 KiB, 79 MiB, 654 LEBs)
[ 3.249876] UBIFS: journal size: 9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
[ 3.249893] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 3.249906] UBIFS: default compressor: lzo
[ 3.249918] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 3.253258] VFS: Mounted root (ubifs filesystem) readonly on device 0:13.
[ 3.255993] devtmpfs: mounted
[ 3.258864] Freeing init memory: 1360K
[ 4.377920] UBIFS: recovery needed
[ 4.536775] UBIFS: recovery completed
[ 4.536805] UBIFS: mounted UBI device 1, volume 0, name "ufs"
[ 4.536824] UBIFS: file system size: 30347264 bytes (29636 KiB, 28 MiB, 239 LEBs)
[ 4.536843] UBIFS: journal size: 9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
[ 4.536860] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 4.536873] UBIFS: default compressor: lzo
[ 4.536885] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 4.584638] aufs test_add:294:mount[663]: uid/gid/perm /mnt/etcro 0/0/0775, 0/0/01777
[ 4.748587] PPP generic driver version 2.4.2
[ 4.798562] PPP Deflate Compression module registered
[ 5.055187] net eth0: CPSW phy found : id is : 0x20005c90
[ 5.056426] Set coalesce to 1120 usecs.
[ 5.398444] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 5.588395] nf_conntrack version 0.5.0 (1937 buckets, 7748 max)
[ 6.622676] eepro step 3
[ 6.957628] step (MODE485=1) _1 nPin = 117 lvl=1
[ 6.963930] step (MODE485=1) _1 nPin = 62 lvl=1
[ 7.048754] PHY: 0:0f - Link is Up - 100/Full
[ 17.149631] am33xx_sr_cpufreq_transition: prechange
[ 17.149797] am33xx_sr_cpufreq_transition: postchange
[ 17.149813] am33xx_sr_cpufreq_transition: postchange, new opp=2
[ 22.266162] am33xx_sr_cpufreq_transition: prechange
[ 22.273884] am33xx_sr_cpufreq_transition: postchange
[ 22.273901] am33xx_sr_cpufreq_transition: postchange, new opp=3
Евгений Кислов
19.01.2021, 18:54
Это лог ОС, где-то рядом должен быть лог CODESYS (PlcLog.csv).
Если его там нет - то надо проверить рабочую директорию (/mnt/ufs/root/codesys_wrk)
Это лог ОС, где-то рядом должен быть лог CODESYS (PlcLog.csv).
Если его там нет - то надо проверить рабочую директорию (/mnt/ufs/root/codesys_wrk)
53079
Файлы, где чтото может быть...
3s.dat = 0 байт
alarmstorage - имеет размер, но открытие браузером базы данных показывает что там таблицы пустые.
Значит, не хранит он логов...?
Евгений Кислов
19.01.2021, 20:02
Логи хранятся в оперативной памяти - то есть после перезагрузки начинают записываться заново.
Что значит "периодически" зависает? О каком периоде речь?
Есть возможность попробовать повторить это с пустым проектом (условно - одна кнопка и лампа на экране) без какого-либо кода?
Логи хранятся в оперативной памяти - то есть после перезагрузки начинают записываться заново.
Что значит "периодически" зависает? О каком периоде речь?
Есть возможность попробовать повторить это с пустым проектом (условно - одна кнопка и лампа на экране) без какого-либо кода?
В первом сообщении темы писал:
СПК207, залита крайняя прошивка.
Проблема - постоянно (от раза в неделю до раза в сутки) зависает визуализация.
При этом продолжает работать встроенный Linux и СПК207 можно перегрузить по SSH.
Визуализация не отвечает, Веб-визуализация не отвечает.
Помогает только ssh busybox reboot.
Вы говорили подключаться к нему по порту 1217 (программирования) - надеятся что коннект произойдет и Кодесис покажет в журнале какие-то сбои.
этого не делал (надо приезжать на обьект, это сложно).
Евгений Кислов
19.01.2021, 20:48
Я не вижу способов разобраться в ситуации без возможности проведения ПНР.
А для современных ПЛК/СПК с CODESYS V3.5 хотелась работа над ошибками и исключения, извиняюсь за выражение, "косяков" старых приборов.
Vniko, большое спасибо за подробные исследования. Копаться глубоко для меня нет необходимости, тем более контроллер уже "древний". Попробую ставить приоритеты >15 на две вспомогательные задачи, если зависания исчезнут - очень хорошо, с меня 100 гр и пирожок)
Поменял приоритет визуализации с 10 на 25, зависания прекратились.
p.s. приконнектиться к зависшему СПК207 чтоб посмотреть причину зависания в журнале - невозможно.
Виснет, но теперь уже Codesys :)
Для наглядности, создал экспериментальный проект с "лёгким" MainTask, второй запускаемой вручную "тяжёлой" задачей HeavyTask, а в визуализации добавил второй "тяжёлый" экран с большой таблицей. Эксперимент проводил так: производил сброс счетчиков цикла всех задач и через 3 минуты делал "грязное дело" - запускал "тяжёлый" функционал.
Сначала приведу Monitor из конфигурации задач, когда все задачи, кроме MainTask, с приоритетом > 15:
MainTask (циклич. 20 ms) - приоритет = 1;
HeavyTask (циклич. 1000 ms) - приоритет = 16;
VISU_TASK (циклич. 200 ms) - приоритет = 31.
Прошло 2 минуты после сброса счетчиков цикла:
(макс. время цикла MainTask = 3.3 ms, HeavyTask = 0.77 ms, VISU_TASK = 11.4 ms)
51644
Непосредственно после перехода на "тяжелый" экран и включения "тяжёлой" HeavyTask:
(Заметного влияния на макс. время цикла MainTask нет.)
51645
Изменил приоритеты:
HeavyTask (циклич. 1000 ms) - приоритет = 9;
VISU_TASK (циклич. 200 ms) - приоритет = 15.
Один раз привожу Monitor из конфигурации задач через 2 минуты после сброса счетчиков цикла:
(макс. время цикла MainTask = 7 ms, HeavyTask = 0.16 ms, VISU_TASK = 3.3 ms)
51646
Перешёл на "тяжёлый" экран:
(макс. время цикла VISU_TASK = 27.7 ms повлияло на макс. время цикла MainTask = 32.3 ms)
51647
Запустил 1 цикл "тяжёлой" HeavyTask:
(макс. время цикла HeavyTask = 140 ms повлияло на макс. время цикла MainTask = 146 ms)
51648
Запустил выполнение "тяжёлой" HeavyTask, скриншот через 3 минуты работы "тяжёлой" HeavyTask:
(макс. время цикла HeavyTask = 138 ms повлияло на макс. время цикла MainTask = 146 ms и видно как сред. время цикла MainTask заметно увеличивается)
51649
Ещё один эксперимент. После сброса счетчиков цикла всех задач через 3 минуты вытащил MMC-карту из СПК207:
(На несколько секунд зависло всё, в том числе связь по RS-485, на подключенном через Ethernet CoDeSys все счетчики цикла замерли, но после зависания скакнуло только макс. время цикла MainTask до 3.2 секунды (были случаи и до 4.6 сек.). При отключении от USB Host такого не наблюдается, в т.ч. пробовал карт-ридер с той же самой MMC-картой).
51650
Теперь ошибки 163: В экспериментальном проекте в MainTask (PLC_PRG) ловлю и считаю ошибки связи с шестью модулями вывода МУ110-16К на COM2. Но после экспериментирования с "тяжёлым" функционалом, 163-х ошибок поймалось мало, за пол часа было всего две. Не имея много времени для эксперимента (делал в пересменок), изменил приоритет VisuTask с 15 на 14 и добавил COM3 со slave, как у меня в рабочем проекте.
Вот, в следующий раз, эксперимент заключался только в ловле ошибок 163:
(Ровно за час поймал 4 ошибки. Частота появления ошибок вроде не изменилась. Но за 5 рабочих дней на моём рабочем проекте было до 50 на одном модуле.)
51651
Выкладываю используемый мною проект при проведении экспериментов (с последней указаной конфигурацией):
С приоритетом 25 вместо 10 зависает реже, но зависает.
Может имеет смысл птавить freewheeling ? Других вариантов не просматривается. Визуализация тяжелая...
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot