| Автор |
Повідомлення |
|
Повідомлення створено: 03. 07. 2012 [13:54]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Спасибо за пояснение, Роман!
Интересный синтаксис: "{ArhMod}.{Arh}" - конкретный архиватор модуля
При указании конкретного архиватора фигурные скобки указывать обязательно?
Допустим имеем архиватор с идентификатором msg_actions_archiver в архиваторе на основе БД.
Тогда параметр arch примет вид:
{BDArch}.{msg_actions_archiver}
или требуется предварять префиксом "mess_":
{mod_BDArch}.{mess_msg_actions_archiver} ?
|
|
Повідомлення створено: 03. 07. 2012 [14:56]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"DJ-AMIGO" wrote:
Интересный синтаксис: "{ArhMod}.{Arh}" - конкретный архиватор модуля
При указании конкретного архиватора фигурные скобки указывать обязательно?
Стандартный синтаксис.
Смотрим здесь http://wiki.oscada.org/Doc/OpisanieProgrammy/part4/files?get=subsys_arch_mess.png , в поле "Архиватор"!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 31. 07. 2012 [16:44]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Добрый день, Роман!
Напомню, что я сконфигурировал OpenSCADA на контроллере LinPAC ICP DAS LP-5441 (развернул готовую сборку OpenSCADA для данного контроллера с сайта проекта).
Использую пакет в основном для трех основных функций:
1. Опрос по протоколу DCON модулей дискретного ввода (УСО ICP DAS I-7041).
2. Опрос атрибутов параметра daq-контролера DCON реализован в daq-контроллере LogicLev.
Суть заложенного алгоритма заключается в отслеживании состояния каждого из атрибутов параметра daq-контроллера DCON и при изменении уровня с "0" в "1" в увеличении значения соответствующего счетчика в логическом контроллере. При каждом возникновении такого события генерируется системное сообщение специальной категории, которое помещается в буфер сообщений open scada.
3. На третьем этапе обработки действует еще один daq-контроллер LogicLev, в котором реализован алгоритм сканирования буфера сообщений openscada.
Все отлавливаемые новые сообщения, при условии наличия соединения с центральным сервером OpenSCADA, отправляются посредством SelfSystem транспортного протокола на центральную Scada-станцию используя SSL-транспорт.
Естественно для хранения системных данных используется взаимодействие со служебной базой данных (хранение времени последней удачной отправки сообщений на центральную станцию).
Управление SSL-соединениями для организации сеансов связи с центральной Scada-станцией.
Архивирование и хранение в архиве сообщений, попадающих в очередь за определенный промежуток времени (я использовал 2 недели).
В принципе это описание достаточно полно характеризует структуру проекта.
При условии наличия Интернет-соединения все включается и транспортировка адекватных данных происходит без проблем.
Но стоит отключить сетевой кабель, включить контроллер, то обнаруживается проблема с SSL-соединением.
Если теперь подключить сетевой кабель и попробовать инициировать передачу данных, то как бы я не пытался SSL-коннект отказывается устанавливаться (при этом совершенно точно известно, что центральный сервер доступен для обращения по сети).
Но самое интересное происходит, когда я перезапускаю daq-контроллер LogicLev (см. 3 этап), отвечающий за передачу данных на центральный сервер. После его рестарта соединение устанавливается без проблем!
Таким образом, вывод напрашивается сам собой, как контроллер логического уровня может влиять на подсистему транспортов? Почему после рестарта LogicLev-контроллера установление SSL-соединений снова оказывается возможным?
Также хотелось бы отметить, что подсистема архивов сообщений работает как-то медленно, а при запросах величиной больше 10000 сек. и вовсе подвисает на приличное время.
Также есть у OpenSCADA такое поведение: после очередной перезагрузки (например в результате пропадания напряжения питания), все daq-контроллеры модуля "сбор данных" оказываются незапущенными, хотя галочка запускать при старте все еще стоит. Здесь я хотел бы акцентировать важность проблемы, так как это очень неприятное поведение влияет на надежность решения. В один прекрасный день система попросту перестанет работать, потому что daq-контроллеры не запустились... с чем это может быть связано не подскажите?
|
|
Повідомлення створено: 31. 07. 2012 [17:22]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"DJ-AMIGO" wrote:
Напомню, что я сконфигурировал OpenSCADA на контроллере LinPAC ICP DAS LP-5441 (развернул готовую сборку OpenSCADA для данного контроллера с сайта проекта).
Какую именно?
"DJ-AMIGO" wrote:
3. На третьем этапе обработки действует еще один daq-контроллер LogicLev, в котором реализован алгоритм сканирования буфера сообщений openscada.
Все отлавливаемые новые сообщения, при условии наличия соединения с центральным сервером OpenSCADA, отправляются посредством SelfSystem транспортного протокола на центральную Scada-станцию используя SSL-транспорт.
Это лучше было сделать в контроллере JavaLikeCalc, поскольку процедура реально одна.
"DJ-AMIGO" wrote:
Естественно для хранения системных данных используется взаимодействие со служебной базой данных (хранение времени последней удачной отправки сообщений на центральную станцию).
Это лишнее, достаточно хранить во внутреннем атрибуте.
"DJ-AMIGO" wrote:
Но стоит отключить сетевой кабель, включить контроллер, то обнаруживается проблема с SSL-соединением.
Если теперь подключить сетевой кабель и попробовать инициировать передачу данных, то как бы я не пытался SSL-коннект отказывается устанавливаться (при этом совершенно точно известно, что центральный сервер доступен для обращения по сети).
Но самое интересное происходит, когда я перезапускаю daq-контроллер LogicLev (см. 3 этап), отвечающий за передачу данных на центральный сервер. После его рестарта соединение устанавливается без проблем!
Значит при той ошибке не происходит остановка транспорта, которая происходит при перезапуске. В любом случае у меня таких проблем нет. Разбирайтесь!
А вообще SSL на сборке для этого контроллера я сильно не тестировал да и вспоминая его общую проблемность не удивлюсь если это бока из SSL лезут.
"DJ-AMIGO" wrote:
Также хотелось бы отметить, что подсистема архивов сообщений работает как-то медленно, а при запросах величиной больше 10000 сек. и вовсе подвисает на приличное время.
Шутите! На этом девайсе и это высокая производительность.
Но если оно Вам конечно нужно, то займитесь и оптимизируйте!
"DJ-AMIGO" wrote:
Также есть у OpenSCADA такое поведение: после очередной перезагрузки (например в результате пропадания напряжения питания), все daq-контроллеры модуля "сбор данных" оказываются незапущенными, хотя галочка запускать при старте все еще стоит.
У меня такого нигде нет. Смотрите в архив системных сообщений на предмет причины незапуска.
"DJ-AMIGO" wrote:
Здесь я хотел бы акцентировать важность проблемы, так как это очень неприятное поведение влияет на надежность решения. В один прекрасный день система попросту перестанет работать, потому что daq-контроллеры не запустились... с чем это может быть связано не подскажите?
Я понимаю, только важность проблемы напрямую соотносится с тем у кого она есть. У меня этой проблемы нет и нигде не воспроизводится.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 01. 08. 2012 [16:15]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Роман, Вы все правильно говорите!
но тем не менее раздел, в котором я поставил эти вопросы, как раз посвящен вопросам внедрения OpenSCADA и я намерен решать возникшие трудности.
Над оптимизацией алгоритма опроса я уже подумал, и получается, что можно преодолеть это ограничение производительности уменьшив временной интервал поиска для сервисной функции get подсистемы архивов, но с другой стороны увеличить частоту вызова этой функции.
Естественно это можно делать не бесконечно, т.к. есть и нижний предел, когда накладные затраты на вызов сервисной функции "get" превышают выигрыш от прироста производительности за счет увеличения частоты опроса буфера сообщений.
С проблемой незапуска daq-контроллеров все еще не разобрался, такое ощущение, будто остановка происходит из-за нехватки ресурсов. Прокомментируйте, пожалуйста, данную догадку.
|
|
Повідомлення створено: 01. 08. 2012 [17:25]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"DJ-AMIGO" wrote:
Над оптимизацией алгоритма опроса я уже подумал, и получается, что можно преодолеть это ограничение производительности уменьшив временной интервал поиска для сервисной функции get подсистемы архивов, но с другой стороны увеличить частоту вызова этой функции.
Естественно это можно делать не бесконечно, т.к. есть и нижний предел, когда накладные затраты на вызов сервисной функции "get" превышают выигрыш от прироста производительности за счет увеличения частоты опроса буфера сообщений.
Если не создавалось архиваторов сообщений то оптимизировать буфер там уже наверное некуда.
"DJ-AMIGO" wrote:
С проблемой незапуска daq-контроллеров все еще не разобрался, такое ощущение, будто остановка происходит из-за нехватки ресурсов. Прокомментируйте, пожалуйста, данную догадку.
Не может. Там 128/64Мб чего за глаза достаточно. Скорее запуск висит на таймауте транспорта SSL. Ещё раз говорю, в архив системных сообщений смотрите!
Хотя если учесть, что Вы работаете с XMLNode, то возможно его утечка, исправлена недавно: http://oscada.org/websvn/listing.php?repname=OpenSCADA&rev=1882&peg=1883
"roman" wrote:
"DJ-AMIGO" wrote:
Напомню, что я сконфигурировал OpenSCADA на контроллере LinPAC ICP DAS LP-5441 (развернул готовую сборку OpenSCADA для данного контроллера с сайта проекта).
Какую именно?
На этот вопрос ответьте!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 01. 08. 2012 [19:13]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
"roman" wrote:
"DJ-AMIGO" wrote:
Напомню, что я сконфигурировал OpenSCADA на контроллере LinPAC ICP DAS LP-5441 (развернул готовую сборку OpenSCADA для данного контроллера с сайта проекта).
Какую именно?
Роман, я использовал готовый архив сборки OpenSCADA приведенный в конце статьи "Сборка OpenSCADA и прошивки для ARM-контроллеров фирмы ICP DAS (LP-5141)".
Ссылка на архив сборки: ftp://ftp.oscada.org/OpenSCADA/PLC/LP5xx1/root_oscada.tgz
Адрес статьи: http://oscada.org/ru/glavnaja/reshenija/odinochnaja-stranica/article/building-openscada-and-firmware-for-arm-controllers-of-icp-das-company-lp-5141/
|
|
Повідомлення створено: 01. 08. 2012 [19:17]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
"DJ-AMIGO" wrote:
С проблемой незапуска daq-контроллеров все еще не разобрался, такое ощущение, будто остановка происходит из-за нехватки ресурсов. Прокомментируйте, пожалуйста, данную догадку.
Не может. Там 128/64Мб чего за глаза достаточно. Скорее запуск висит на таймауте транспорта SSL. Ещё раз говорю, в архив системных сообщений смотрите!
Хотя если учесть, что Вы работаете с XMLNode, то возможно его утечка, исправлена недавно: http://oscada.org/websvn/listing.php?repname=OpenSCADA&rev=1882&peg=1883
Роман, а имеется ли возможность обработать ситуацию с длительным тайм-аутом SSL-транспорта в пользовательском скрипте?
|
|
Повідомлення створено: 01. 08. 2012 [19:43]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Последнее здесь: ftp://ftp.oscada.org/OpenSCADA/PLC/LP_ARM/
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 01. 08. 2012 [19:44]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"DJ-AMIGO" wrote:
Роман, а имеется ли возможность обработать ситуацию с длительным тайм-аутом SSL-транспорта в пользовательском скрипте?
Нет таких механизмов в libSSL.
Learn, learn and learn better than work, work and work.
|
