[BugWrong]
Ошибка остановки контроллера модуля JavaLikeCalc при завершении приложения OpenScada
Автор |
Сообщение |
Сообщение создано: 22. 02. 2012 [15:16]
|
Dioma
Vadim Lenda
Создатель темы
Зарегистрирован(а) с: 20.02.2012
Сообщения: 3
|
Описание ошибки:
В дереве рабочей станции были созданы - исходящий транспорт, пользовательский протокол, контроллер модуля JavaLikeCalc и его 16 параметров, а также архиватор 100ms. Через исходящий транспорт контроллер запрашивает данные у внешнего модуля по протоколу TCP.
Теперь, при завершении приложения OpenScada контроллер не может остановиться, продолжая делать запросы и выполнять свой скрипт, что вызывает, судя по всему, некорректное завершение программы с возвращаемым значением 139.
Выкладываю лог командной строки при завершении проложения:
1|/WorkStation/ | Stop!
1|/WorkStation/sub_UI/mod_VCAEngine/ | Stop module.
1|/WorkStation/sub_Archive/ | Stop subsystem.
1|/WorkStation/sub_Archive.mod_DBArch.val_100ms: stop | Wait event...
1|/WorkStation/sub_DAQ/mod_JavaLikeCalc/cntr_da1/ | Stop controller!
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
5|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Timeouted !!!
4|/WorkStation/ | Task 'sub_DAQ.mod_JavaLikeCalc.cntr_da1' is not stopped!
4|/WorkStation/sub_DAQ/ | Stop controller 'JavaLikeCalc.da1' error.
1|/WorkStation/sub_DAQ/mod_LogicLev/cntr_post_processing/ | Stop controller!
1|/WorkStation/sub_DAQ/mod_JavaLikeCalc/cntr_da1/ | Stop controller!
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
5|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Timeouted !!!
4|/WorkStation/ | Task 'sub_DAQ.mod_JavaLikeCalc.cntr_da1' is not stopped!
4|/WorkStation/sub_DAQ/ | Disable controller 'JavaLikeCalc.da1' error.
1|/WorkStation/sub_DAQ/mod_LogicLev/cntr_post_processing/ | Disable controller!
1|/WorkStation/sub_DAQ/mod_JavaLikeCalc/cntr_da1/ | Stop controller!
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
1|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Wait event...
5|/WorkStation/sub_DAQ.mod_JavaLikeCalc.cntr_da1: stop | Timeouted !!!
4|/WorkStation/ | Task 'sub_DAQ.mod_JavaLikeCalc.cntr_da1' is not stopped!
4|/WorkStation/sub_DAQ/ | Stop module 'JavaLikeCalc' error.
1|/WorkStation/sub_Transport/ | Stop subsystem.
4|/WorkStation/sub_DAQ/mod_JavaLikeCalc/lib_easyCAN/fnc_fnc_data_req/ | Timeouted function calculation
1|/WorkStation/sub_DAQ/ | Disconnect module 'DAQGate'!
1|/WorkStation/sub_Special/ | Disconnect module 'FLibSYS'!
4|/WorkStation/sub_Special/mod_FLibSYS/fnc_strDec4Bin/ | Blocking node error. Inform developers please!
4|/WorkStation/sub_Special/mod_FLibSYS/fnc_strEnc2Bin/ | Blocking node error. Inform developers please!
1|/WorkStation/sub_BD/ | Disconnect module 'MySQL'!
1|/WorkStation/sub_UI/ | Disconnect module 'WebUser'!
1|/WorkStation/sub_Special/ | Disconnect module 'FLibMath'!
1|/WorkStation/sub_UI/ | Disconnect module 'WebVision'!
1|/WorkStation/sub_BD/ | Disconnect module 'PostgreSQL'!
1|/WorkStation/sub_BD/ | Disconnect module 'SQLite'!
1|/WorkStation/sub_Archive/ | Disconnect module 'FSArch'!
1|/WorkStation/sub_Transport/ | Disconnect module 'Sockets'!
1|/WorkStation/sub_Archive/ | Disconnect module 'DBArch'!
1|/WorkStation/sub_UI/ | Disconnect module 'QTStarter'!
1|/WorkStation/sub_Transport/ | Disconnect module 'SSL'!
1|/WorkStation/sub_BD/ | Disconnect module 'FireBird'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'DCON'!
1|/WorkStation/sub_Protocol/ | Disconnect module 'SelfSystem'!
1|/WorkStation/sub_UI/ | Disconnect module 'WebCfg'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'Siemens'!
1|/WorkStation/sub_Protocol/ | Disconnect module 'UserProtocol'!
1|/WorkStation/sub_UI/ | Disconnect module 'Vision'!
1|/WorkStation/sub_UI/ | Disconnect module 'QTCfg'!
1|/WorkStation/sub_Protocol/ | Disconnect module 'HTTP'!
1|/WorkStation/sub_Protocol/ | Disconnect module 'OPC_UA'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'OPC_UA'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'SNMP'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'LogicLev'!
1|/WorkStation/sub_BD/ | Disconnect module 'DBF'!
1|/WorkStation/sub_DAQ/ | Disconnect module 'JavaLikeCalc'!
1|/WorkStation/sub_DAQ/mod_JavaLikeCalc/cntr_da1/ | Stop controller!
1|/WorkStation/sub_DAQ/mod_JavaLikeCalc/cntr_da1/ | Disable controller!
Program result: 139
root@ced-N128:~#
|
Сообщение создано: 22. 02. 2012 [15:40]
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"Dioma" wrote:
В дереве рабочей станции были созданы - исходящий транспорт, пользовательский протокол, контроллер модуля JavaLikeCalc и его 16 параметров, а также архиватор 100ms. Через исходящий транспорт контроллер запрашивает данные у внешнего модуля по протоколу TCP.
Сделал похожее, кроме пользовательского протокола, место которого в этой конфигурации не понятно.
"Dioma" wrote:
Теперь, при завершении приложения OpenScada контроллер не может остановиться, продолжая делать запросы и выполнять свой скрипт, что вызывает, судя по всему, некорректное завершение программы с возвращаемым значением
Что делает Ваш скрипт я не знаю у меня нет никаких проблем.
Разбирайтесь со своей специфической конфигурацией!
P.S. Версия OpenSCADA вообще какая?
Learn, learn and learn better than work, work and work.
|
Сообщение создано: 22. 02. 2012 [22:49]
|
Dioma
Vadim Lenda
Создатель темы
Зарегистрирован(а) с: 20.02.2012
Сообщения: 3
|
"roman" wrote:
P.S. Версия OpenSCADA вообще какая?
OpenScada 0.7.2. Установленная из .deb пакета. Устанавливалась на Ubuntu 11.10.
Такая проблема возникает именно тогда, когда транспорт установил соединение и идет постоянный обмен данными. Если НЕ останавливая контроллер попытаться завершить приложение, то оно постоянно некорректно завершается (139), елси же перед завершением вручную остановить контроллер, то завершение проходит нормально.
Созданный пользовательский протокол является небольшой надстройкой над TCP, которая разбирает значения параметров, пришедших в одном пакете.
Также столкнулся с проблемой быстродействия системы OpenScada на машине Intel Atom 1.6GHz, 1 Gb RAM. Был запущен проект опроса внешнего модуля (TCP) с частотой 100мс, 16 параметров контроллера, архивирование в базу данных. Визуализация: мнемосхема, графики и два документа (архивный и динамический). Все составляеющие проекта (библиотеки виджетов, функций и настройки рабочей станции и проекта) были разнесены по разным базам данных (SQLite). Могло ли это повлиять на быстродействие? Лучше хранить все составляющие проекта в одной базе данных?
Повлияет ли на быстродействие системы отключение неиспользующихся модулей рабочей станции?
Заранее благодарен.
[Сообщение редактировалось 1 раз(а), в последний раз 22.02.2012 в 22:51.]
|
Сообщение создано: 22. 02. 2012 [23:44]
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"Dioma" wrote:
OpenScada 0.7.2. Установленная из .deb пакета. Устанавливалась на Ubuntu 11.10.
Ставьте из SVN-репозитория рабочую версию. 0.7.2 не LTS и решать проблемы в ней (если она там вообще есть) без приобретения пакета техподдержки я не буду.
Кстати запустил через пользовательский протокол — нет никаких проблем у меня!
"Dioma" wrote:
Также столкнулся с проблемой быстродействия системы OpenScada на машине Intel Atom 1.6GHz, 1 Gb RAM. Был запущен проект опроса внешнего модуля (TCP) с частотой 100мс, 16 параметров контроллера, архивирование в базу данных.
И в чём конкретно заключается проблема быстродействия?
Если в архивировании так это не проблема производительности OpenSCADA, а проблема производительности БД. БД в принципе не предназначена для выполнения архивирования столь частых данных. Для этого оптимизирован файловый архиватор!
Так у меня архивирование на SQLite с периодичностью 100 мс составляет около 0.18 секунд на сигнал, итого 3 секунды на 16 сигналов. На Intel Atom это будет около 6 секунд, на жёсткий диск. Если это флешь то будет ещё больше, т.е. около 15% нагрузки процессора.
"Dioma" wrote:
Визуализация: мнемосхема, графики и два документа (архивный и динамический). Все составляеющие проекта (библиотеки виджетов, функций и настройки рабочей станции и проекта) были разнесены по разным базам данных (SQLite).
Архивы должны быть в отдельной БД иначе это будет ещё медленнее за счёт бросков транзакций.
"Dioma" wrote:
Могло ли это повлиять на быстродействие? Лучше хранить все составляющие проекта в одной базе данных?
Повлияет ли на быстродействие системы отключение неиспользующихся модулей рабочей станции?
Может Вы скажет всё-же быстродействие чего? Вообще заходим в менеджер задач (http://wiki.oscada.org/Doc/OpisanieProgrammy/part4/files?get=sys_tasks.png) и изучаем какие конкретно задачи особенно ресурсоёмки и говорим предметно, а так-же оптимизируем их выполнение.
Learn, learn and learn better than work, work and work.
|
Сообщение создано: 24. 02. 2012 [21:37]
|
Dioma
Vadim Lenda
Создатель темы
Зарегистрирован(а) с: 20.02.2012
Сообщения: 3
|
Проблема быстродействия заключается именно в подтягивании данных из баз при первом вызове страницы графиков запущенного проекта или при формировании динамического документа. Видимо, Атому тяжело.
Теперь опробую архивирование на файловую систему по Вашей рекомендации, спасибо.
По поводу проблемы с остановкой контроллера: было выяснено, что либо кто-то не позволяет транспорту разорвать соединение, либо каким-то образом возникает ситуация, когда транспорт уже разорвал соединение, а пользовательский протокол об этом еще не узнал.
Т.е. после команды завершения работы приложения путем выведения дебаг-сообщений опознали, что система ждет како-го события после вызова функции транспорта: resp = tr.messIO(request); в выходной части пользовательского протокола.
Эта проблема, конечно, не влияет на быстродействие или на другие показатели системы, поэтому является некритичной.
|
Сообщение создано: 24. 02. 2012 [23:17]
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"Dioma" wrote:
Проблема быстродействия заключается именно в подтягивании данных из баз при первом вызове страницы графиков запущенного проекта или при формировании динамического документа. Видимо, Атому тяжело.
Ну это естественно, даже для секундных архивов с БД это не быстро. Есть один способ, своего рода кеширование, это создание пары менее частых архиваторов (1с, 1мин, 1час) и архивировать параллельно на них. Таким образом сигнал будет представлен несколькими архивами разного качества. При отображении их график умеет оптимально запрашивать с того архиватора качества которого достаточно для указанного размера окна. Например, если размер окна будет 1час, то запрашиваться будут данные из архиватора с периодичностью 1 сек, что в 10 раз быстрее чем брать прямо из 100мс архиватора, для отображения такого размера окна.
"Dioma" wrote:
Т.е. после команды завершения работы приложения путем выведения дебаг-сообщений опознали, что система ждет како-го события после вызова функции транспорта: resp = tr.messIO(request); в выходной части пользовательского протокола.
Таймаута может ждать, если очень большие.
Рабочую версию из SVN собирали?
Learn, learn and learn better than work, work and work.
|
|
|