From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Documents/How to and the translation is 100% complete.

Other languages:
English • ‎российский
Constr.png Common revision and translation

Автор: Роман Савоченко

Данный документ предназначен для предоставления описания рецептов (Как сделать) решения часто встречающихся проблем и задач пользователя. Рецепты решения задач и проблем для помещения в этот документ могут предлагаться пользователями.

1 Перенос конфигураций OpenSCADA из одного проекта в другой

Часто востребованной бывает задача переноса конфигурации из одного проекта OpenSCADA в другой. Причём, чаще всего нужно осуществить частичный перенос, например, перенос отдельных наработок, которые могут пригодиться в новом проекте.

Вообще, нужно отметить, что любые наработки с малейшим намёком и перспективой вторичного использования нужно стараться унифицировать и сохранять в отдельные, собственные, библиотеки и БД. Крайне не рекомендуется непосредственно менять стандартные конфигурации и элементы стандартных библиотек, а также сохранять собственные, новые, библиотеки и элементы в базах данных стандартных библиотек. Это позволит Вам впоследствии безболезненно обновлять стандартные библиотеки, а также просто использовать наработки ваших предыдущих проектов.

1.1 Простой перенос БД с библиотеками и конфигурацией

Если Вы учли вышеуказанные рекомендации и все Ваши унифицированные наработки содержаться в отдельной БД, то весь процесс переноса будет заключаться в копировании БД и подключении её в новом проекте.

Процедура копирование БД отличается для различных типов БД и с ней нужно будет ознакомиться из документации к БД. Для сопутствующего распространения с дистрибутивами OpenSCADA обычно используется БД SQLite, в виде отдельных файлов *.db. Копирование БД SQLite соответственно заключается в простом копировании нужного файла БД из директории баз данных старого проекта в директорию баз данных нового.

Подключение осуществляется путём создания нового объекта БД в модуле нужного типа БД подсистемы БД и последующей его конфигурации (детальнее). После создания, конфигурации и включения БД можно сразу загрузить конфигурацию из неё, нажав кнопку "Загрузить систему из этой БД" на форме объекта БД.

1.2 Выделение нужной конфигурации

В случае, если нужная конфигурация содержится в общей БД или БД стандартных библиотек, то предварительно нужно осуществить выделение её в отдельную БД. Выделить конфигурацию можно или в отдельную БД с Вашими библиотеками или в экспортную БД. Экспортная БД, в отличие от библиотечной, служит только для переноса конфигурации и будет впоследствии удалена. В любом случае нужно создать новую БД для нужного типа БД, подобно процедуре подключения выше. Для переноса нужно использовать тип БД, который планируется использовать в новом проекте. Обычно для переноса лучше использовать тип БД SQLite, ввиду простой процедуры копирования. Однако, если использовать сетевую СУБД эта процедура может превратиться в простое подключение библиотечной или экспортной БД в новом проекте.

Далее необходимо выделить конфигурацию в унифицирующие или экспортные библиотеки, если она не может быть прямо сохранена в БД. Например, отдельные шаблоны параметров или параметры контроллеров сбора данных, визуальные элементы библиотек виджетов и т.д. выделить можно путём создания библиотеки экспорта или унификации соответствующего элемента, например, библиотека шаблонов или контроллер параметров сбора данных, библиотека виджетов и т.д. Для вновь созданной библиотеки в качестве БД нужно указать ранее созданную унифицирующую или экспортную БД. Далее осуществляется копирование нужных элементов из исходной библиотеки в унифицирующую/экспортную посредством стандартной функции копирования. После копирования унифицирующую/экспортную библиотеку нужно сохранить.

В случае необходимости переноса объекта с отдельным свойством БД, или целых библиотек, операцию создания промежуточной библиотеки и последующего копирования можно опустить. Достаточно в поле БД указать ранее созданную унифицирующую или экспортную БД и сохранить элемент.

Дальнейшие действия, а именно простой перенос БД, осуществляются в соответствии с предыдущим разделом.

При переносе конфигурации путём экспортирования необходимо осуществить обратный процесс копирования из экспортных библиотек в локальные библиотеки нового проекта и удаление экспортной БД.

1.3 Низкоуровневое копирование содержимого БД

Для переноса можно осуществить избирательное копирование таблиц БД с конфигурацией путём выбора объектов таблиц в объекте БД; команды копирования, выбора объекта новой БД и команды вставки (детальнее). Однако, для этого нужно знать структуру БД, про которую изложено по этой ссылке.

2 Особенности циклического программирования в OpenSCADA

У начинающих пользователей часто возникает вопрос обеспечения выдержки временных интервалов при программировании вычислительных процедур в окружении OpenSCADA. Этот вопрос обычно связан с наличием предыдущего опыта программирования линейных вычислений и отсутствием опыта программирования циклических систем реального времени.

В системах реального времени используется так называемый такт или цикл периодических вычислений, т.е. ритм жизни. В каждом такте выполняется некоторая процедура, которая не должна занимать времени больше такта. Как следствие, если процедура такта останавливается в ожидании, то останавливается и жизнь системы реального времени. Следовательно, использование в этих процедурах традиционных функций усыпления задачи недопустимо!

Решение задачи выдержки нужного интервала времени в системах реального времени, в рамках ритма жизни, осуществляется в два способа. Первый способ заключается в декременте счётчика, установленного в значение временного интервала, в каждом цикле на значение периодичности такта до значения <=0, например, в OpenSCADA это реализуется таким образом:

if((tm_cnt-=1/f_frq) <= 0)  //Декремент
{
    tm_cnt = 10; //Установка счётчика в значение 10 секунд
    //Выполнение других действий с периодичностью 10 секунд
}

Второй способ основан на астрономическом времени, т.е. в цикле осуществляется сравнение с текущим временем, например, в OpenSCADA это реализуется таким образом:

if(SYS.time() > tm_to)
{
    tm_to = SYS.time()+10; //Установка порога ожидания на 10 секунд более текущего времени
    //Выполнение других действий с периодичностью 10 секунд
}

Второй способ является более надёжным поскольку в нём исключается проблема запаздывания срабатывания по причине возможного выполнения процедуры цикла более времени такта. Хотя в правильно настроенных системах и задачах данный эффект не должен иметь место.

3 Живой диск (Live CD/USB)

Для максимального упрощения развёртывания OpenSCADA можно использовать живые сборки загрузочных дисков CD и USB. Живой диск предусматривает возможность загрузки прямо с него и быстрого получения желаемого рабочего окружения. При загрузке и работе живой диск не использует штатных носителей, а значит Вы можете не беспокоиться за их целостность и сохранность данных на них. В целом живой диск является удобным средством с широким набором нужных программных инструментов под рукой и независимым от стационарного программного окружения, способным осуществить диагностику программного и аппаратного окружения, а также их восстановление, в некоторых случаях.

Живой диск представляет собой упакованный образ операционной системы и прикладных программ размером около 700МБ, записанный на CD/DVD диск или USB-Flash носитель. При своей работе операционная система "на лету" распаковывает нужные файлы для запуска программ и открытия документов, а значит не использует оперативной памяти больше, чем при её обычной установке.

Живые диски с OpenSCADA собираются в нескольких вариантах на основе дистрибутивов ОС Linux Debian и ALTLinux (старые версии) и доступны для загрузки к соответствующей версии OpenSCADA здесь: http://oscada.org/ru/glavnaja/zagruzit. Текущие живые сборки с OpenSCADA обладают значительно большими функциями чем предусматривалось изначально:

  • Возможность прозрачного сохранения рабочих изменений в случае записи на USB-Flash. Функция обеспечивается созданием раздела диска, с возможностью записи, на свободном месте USB-Flash. Этот раздел отражается на корень файловой системы, или её часть, и все изменения записываются на него. Кроме сохранения рабочих данных в этот раздел можно доустанавливать недостающие пакеты программ из репозитория пакетов Debian, OpenSCADA или ALTLinux.
  • Возможность совмещения обычного Flash-диска данных с живым Flash-диском. Предусматривает запись данных живого диска прямо на файловую систему USB-Flash — FAT16 или FAT32, что сохраняет функции обычного носителя данных и добавляет функцию живого диска.
  • Возможность установки окружения живого диска на стационарный носитель. Позволяет не заниматься глубоким изучением и погружением в операционную систему Linux при её установке, настройке, а также развёртывания OpenSCADA. Достаточно загрузиться с живого диска, убедиться, что основное оборудование определилось нормально и нужные программы работают, а затем, посредством простой процедуры с иконки на рабочем столе, или отдельного меню загрузки, установить на стационарный носитель. Полученная установка будет точно повторять окружение живого диска.

3.1 Комбинированный-гибридный ISO-образ живого диска

На данный момент в основном осуществляются сборки гибридных ISO образов "живых дисков" (*LiveCD_USB.iso), которые можно записать прямо на CD/DVD, USB-Flash, а также извлечь содержимое для записи на USB-Flash с файловыми системами FAT или EXT.

Основным вариантом формирования "живого диска" является запись на CD/DVD, для чего можно использовать стандартный инструментарий исходной операционной системы. Однако всё более распространённым становится запись на USB-Flash, которая может быть осуществлена из окружения ОС Linux, например, из окружения этого же "живого диска", записанного и загруженного ранее с CD/DVD диска; или же из ОС MS Windows посредством "Win32DiskImager".

At.png Запись образа "живого диска" на USB-Flash уничтожит все данные и сделает его непригодным для использования в качестве носителя данных, если не учитывать возможность записи на раздел сохранения изменений окружения ОС живого диска, который будет создан при первой загрузке с живого диска, в случае ALTLinux, или пользователем, в случае "Debian".

Адрес диска для записи ISO-образа имеет вид "/dev/sd{x}", а узнать его можно вызовом консольной команды "$ dmesg" сразу после подключения целевого диска USB-Flash. Из окружения Linux ISO-образ можно записать таким образом:

# Запись файла ISO-образа на USB-Flash:
$ dd if=Debian_8-OpenSCADA_0.9+r2294-TDE_R14-amd64-LiveCD_USB.iso of=/dev/sd{x} bs=4096
# Запись ISO-образа прямо с загруженного CD/DVD живого диска
$ dd if=/dev/sr0 of=/dev/sd{x} bs=4096

3.2 Живой USB-Flash диск с файловой системой FAT или EXT

Ранее осуществлялись специальные сборки образов для записи их на файловую систему FAT. На данный момент специально такие образы собираются только для "прошивок" (FirmWare) ряда ПЛК (*flash.tar). Однако для создания живых USB-Flash дисков общего назначения можно использовать гибридный ISO-образ, о котором описано в разделе выше.

Преимуществом "живого диска" на USB-Flash, как ранее упоминалось, является совмещение функции USB-Flash диска как носителя данных и как живого диска. Кроме того, таким образом можно создавать компактные, надёжные и функциональные решения встраиваемых систем с OpenSCADA, взяв "живой диск" за основу, например: программируемые логические контроллеры (ПЛК), панельные контроллеры (с сенсорным дисплеем), а также просто SCADA-серверы и SCADA-станции оператора "быстрого приготовления"; путём записи живого диска на стационарный носитель (HDD, SSD или Flash). Надёжность данного решения определяется размещением основного ПО в немодифицируемом упакованном файле, а рабочих данных на журналируемой файловой системе.

Запись данных "живого диска" на файловую систему можно осуществить из любой ОС (для FAT), но установить загрузчик только в ОС Linux, для чего можно воспользоваться "живым" CD/DVD диском из прошлого раздела.

Процедура создания живого диска следующая для данных гибридного ISO-диска (Debian и ALTLinux):

  • Для простоты операцию извлечения и копирования данных ISO выполняем в двух-панельном файловом менеджере mc. Чтобы mc смог прочитать ISO образ необходимо установить утилиту isoinfo, обычно находится в пакете "genisoimage".
  • Берём исходный файл ISO-образа, открываем его в mc и копируем из него на целевую FAT или EXT файловую систему:
    • Debian: директории "isolinux" и "live"; директорию "isolinux" переименовываем в "syslinux", на целевой файловой системе.
    • ALTLinux: директорию "syslinux" и файл "live".
  • Переименовываем файл "syslinux/isolinux.cfg" на "syslinux/syslinux.cfg", для FAT, или "syslinux/extlinux.cfg", для EXT.
  • ALTLinux: Добавляем в аргумент "append", секции "label live" файла "syslinux/syslinux.cfg", подстроку "automatic=method:disk,label:MY_LAB" или "automatic=method:disk,uuid:MY-UUID", где MY_LAB и MY-UUID можно узнать, для раздела "живого диска", с помощью команды $ blkid.
  • ALTLinux: Заменяем файл "syslinux/gfxboot.c32" аналогичным файлом из текущей системы (обычно находится в директории "/usr/lib/syslinux/").
  • Устанавливаем загрузчик из командной строки, всё от суперпользователя: $ su -
    • Отключаем диск: $ umount /dev/sd{x}1
    • Инициируем MBR диска в корректное значение: $ ms-sys -s /dev/sd{x}
    • Инициируем загрузчик: $ syslinux /dev/sd{x}1

Для образа "живого диска" на FAT (ALTLinux), всё от суперпользователя: $ su -

  • Подключаем целевой диск и определяем его адрес: $ dmesg
  • Монтируем: $ mkdir /mnt/tmp; mount /dev/sd{x}1 /mnt/tmp
  • Распаковываем содержимое архива прошивки на смонтированный диск: $ cd /mnt/tmp; tar xvf /var/tmp/LP8x81-ALTLinux6-OpenSCADA_0.9+r2302-i586-plc-rt1-up.flash.tar
  • Определяем UUID для файловой системы целевого диска: $ blkid | grep /dev/sd{x}1
  • Модифицируем файл "/mnt/tmp/syslinux/syslinux.cfg" в конце строки "append initrd=alt0/full.cz live ... disk,uuid:4EB3-0478", где указываем ранее полученный UUID.
  • Добавляем или модифицируем файл "/mnt/tmp/syslinux/lang" на предмет указания локали-языка интерфейса по умолчанию, для Русского языка нужно указать "ru_RU", иначе будет Английский.
  • Отключаем диск: $ umount /dev/sd{x}1
  • Инициируем MBR диска в корректное значение: $ ms-sys -s /dev/sd{x}
  • Инициируем загрузчик: $ syslinux /dev/sd{x}1

At.png Данный способ развёртывания живого диска требует знаний ОС Linux и интерфейса командной строки (консоли), а также основ разбиения дисковых носителей поскольку, при некорректном начальном разбиении носителя, загрузка может не пройти.

3.3 Сохранение рабочих данных живого диска на разделе USB-Flash

Живой диск, как ранее указывалось, допускает полноценную работу с возможностью сохранения рабочих данных, а также обновления ПО (за исключением системного ПО и ядра ОС Linux). Обычно данная возможность имеет смысл только для USB, HDD, SSD носителей.

В случае дистрибутивов Debian, отдельный раздел для хранения рабочих данных, с меткой "persistence", нужно всегда создавать специально, а также в файле "persistence.conf" на нём указывать файловую систему, или её часть, для отражения на запись (например, "/home"). Для отражения всей корневой файловой системы в файле нужно записать "/ union". В качестве файловой системы этого раздела лучше использовать "EXT3". Для создания раздела Вы можете использовать программу менеджера разделов, например "gparted".

В случае дистрибутива ALTLinux (6), и прямой записи гибридного ISO-образа, такой раздел будет создан при первом запуске. При формировании "живого диска" на FAT и EXT необходимо создать отдельный раздел с меткой "alt-live-storage" и файловой системой "EXT3", что можно сделать в программе менеджера разделов, например "gparted".

3.4 Загрузка

Для загрузки с полученного "живого диска" нужно перегрузить компьютер и нажать клавишу входа в меню загрузки BIOS, в самом начале загрузки, до загрузчика стационарной ОС, и выбрать там наш носитель (рис.3.1). На разных компьютерах клавиша входа в меню загрузки может отличаться и быть одной из "F8", "F9", "F10", "F11" или "F12".

Рис. 3.1. Вариант меню выбора устройства загрузки в BIOS.

После выбора устройства должно появиться меню загрузки живого диска (рис.3.2), где предварительно важно выбрать вариант загрузки с указанным языком, для Debian, или Ваш язык, по клавише F2 для ALTLinux.

Рис. 3.2. Меню выбора языка живого диска Debian, ALTLinux.

В результате загрузки живого диска Вы получите рабочий стол TDE (рис.3.3).

Рис. 3.3. Рабочий стол живого диска.

4 Общие положения концепции работы с нарушениями, сигнализацией и уведомлениями

Нарушения и работа с ними в OpenSCADA реализуется двояко, что связано со структурой OpenSCADA, способами её использования, а также самой природой нарушений.

Первой стороной нарушений, с которыми OpenSCADA работает изначально и которая наиболее востребована, является уведомление различными способами. Поскольку уведомление это часть интерфейса визуализации то и реализованы они в движке визуализации UI.VCAEngine и визуализаторах UI.Vision, UI.WebVision. На данный момент подсистема уведомлений нарушений в OpenSCADA реализует функции:

  • Уведомление:
    • Светом — мигание объекта, группы сигнализации, общего статуса цветом нарушения.
    • Звуком — проигрывание звукового файла или синтез речи из текста, связанного с нарушением;
    • Гудком — выдача непрерывного сигнала на системный "бузер", независимо от нарушения.
  • Квитирование уведомления о нарушении:
    • Полностью — по нажатию на цветной мигающий кружок статуса нарушений (событие "ws_alarmLev"), снизу справа:
    • По способу уведомления — отдельно световую (событие "ws_alarmLight"), звуковую (событие "ws_alarmLight") и гудок (событие "ws_alarmAlarm"), по нажатию кнопки с соответствующим изображением, снизу справа или под кнопками видов отображения;
    • По объекту нарушения — к образу визуального представления может добавляться команда квитации уведомления непосредственно по нём;
    • Поочерёдно, c выслушиванием — характерно для уведомлений звуком, поскольку каждый объект нарушения может предоставлять своё звуковое уведомление или синтез речи.

При реализации уведомлений в среде визуализации нет установленного правила получения и формирования признака нарушения, поскольку в разных ситуациях нет однозначности. На данный момент на стороне типизированных шаблонов источника данных практикуется способ формирования атрибута ошибки "err" с кодами и текстом нарушения, а их обработка и формирование уведомления осуществляется в визуальном образе объекта данных. Иногда же обработка границ уставок осуществляется прямо в визуальном образе объекта данных.

Впоследствии возникла необходимость протоколирования, а также учёт актуальных на текущий момент нарушений. Если для протоколирования достаточно формирования системных сообщений с оговоренной категорией и форматом сообщения, то для контроля за текущими нарушениями необходим некий буфер. Впоследствии такой буфер был добавлен в виде надстройки над подсистемой сообщений, а адресация к нему осуществляется инверсией уровня сообщения. Так запись сообщения с уровнем "-2" и категорией "TEST" поместит сообщение в буфер нарушений и продублирует его в архиве сообщений, с уровнем "2". При запросе сообщений с отрицательным уровнем сообщения будут браться из буфера нарушений. Удаление/снятие нарушения осуществляется записью сообщения с той же категорией "TEST" и неотрицательным уровнем.

Такая концепция учёта активных нарушений позволяет использовать стандартные механизмы работы с сообщениями для учёта нарушений:

  • Регистрация нарушения: SYS.message("alCategory", -3, "Параметр: нарушение");
  • Снятие нарушения: SYS.message("alCategory", 1, "Параметр: норма");
  • Формирование списка активных нарушений: посредством примитива "Протокол" или "Документ", с отрицательным уровнем, для всех "-1".

Регистрацию сообщений лучше всего осуществлять на стороне типизированных шаблонов источника данных посредством специальной функции SYS.DAQ["Modul"]["Controller"].alarmSet(string mess, int lev = -5, string prm = ""), которая унифицирует категорию. Для вызова этой функции из контекста шаблона нужно добавить IO "this" типа "Объект", после чего установка нарушения будет иметь вид this.cntr().alarmSet("Параметр: нарушение", -5, "prm");. Указанная функция сейчас используется во многих модулях источников данных для учёта глобальных нарушений объектов контроллеров. Функция формирует нарушение с категорией: al{ModId}:{CntrId}[.{PrmId}], где:

  • ModId — идентификатор модуля;
  • CntrId — идентификатор контроллера;
  • PrmId — идентификатор параметра, из аргумента prm.

At.png В целом нужно отметить, что уведомления и регистрация нарушений это разные механизмы, которые могут использоваться по отдельности — для простых проектов, или вместе — для больших комплексных проектов.

5 Сохранение/Восстановление модифицированных данных в источнике/обёртке логического уровня

Иногда может понадобиться сохранить и затем восстановить, в основном при перезапуске, некоторые модифицированные данные вроде счётчиков пробега оборудования. В целом обработку такого рода источников данных и оборудования нужно осуществлять в логическом уровне подсистемы "Сбор данных". Такую задачу Вы можете реализовать многими путями, предусматривающими сохранение данных и последующее их восстановление на некотором хранилище, однако наиболее известные способы это:

  • Периодическое сохранение контекста параметров шаблона с помощью запроса пользовательского API OpenSCADA через cntrReq():
SYS.cntrReq(SYS.XMLNode("save").setAttr("path",this.nodePath()+"/%2fobj"));
  • Если атрибут шаблона со счётчиком архивируется тогда Вы можете получить последнее значение из этого архива при старте параметра, например, так:
if(f_start)    prevArchRestore = false;
if(!prevArchRestore && (archEnd=this.cntr.arch().end("FSArch.1s"))) {
    SYS.messInfo("testArch", "val="+this.cntr.arch().getVal(archEnd)+"; "
                            "val1="+this.cntr.arch().getVal(archEnd,false,"FSArch.1s")+"; "
                            "val2="+this.cntr.get(archEnd/1000000,archEnd%1000000));
    cntr = this.cntr.arch().getVal(archEnd);
    prevArchRestore = true;
}
  • Создание специальной таблицы БД и запись/чтение этих данных прямо в эту таблицу посредством SQL-запросов через SQLReq().

6 Отладка

Если Вы строго следуете основной инструкции то Вы не встретите здесь никаких проблем, однако если Вы делаете что-то своё тогда Вам может быть нужна некоторая отладка. OpenSCADA предоставляет широкие возможности отладки и обнаружения проблем программирования в общем пользовательском пространстве OpenSCADA и проблем самой OpenSCADA и её частей.

Основные подходы пользовательской отладки, доступные для LTS и Рабочей версии, предусматривают:

  • Создание внешних атрибутов для обзора за промежуточными значениями и наблюдения за текущим контекстом исполнения.
  • Создание отладочных сообщений, также для обзора за промежуточными значениями и наблюдения за последовательностью исполнения.

Присутствующие механизмы отладки расширены в Рабочей версии на предмет:

  • Пользовательского контроля за отладкой посредством категории отладочного сообщения, для частей OpenSCADA и сообщений пространства пользователя.
  • Специфическая отладка и окружение диагностики некоторых частей OpenSCADA, таких как: источники данных (объекты контроллеров) и интерфейсы СВУ (проекты СВУ).

6.1 Отладка текущего контекста исполнения

Данный метод отладки предусматривает наблюдение за контекстом исполнения по значениям переменных, включая добавление промежуточных значений для детализации.

Текущий контекст исполнения процедур Сбора Данных Вы можете наблюдать на соответствующей странице объекта исполняющегося контекста вроде: вкладка "Атрибуты" Логического уровня параметров (Рис. 6.1), вкладка "Вычисления" вычислителя основанного на Java (Рис. 6.2) и подобное. Для добавления некоторых промежуточных значений Вы можете временно добавить (или установить в атрибут только для чтения) и подключить некоторые атрибуты к шаблону или добавить и привязать некоторые ВВ к функции.

Рис. 6.1. Вкладка "Атрибуты" параметра Логического уровня.
Рис. 6.2. Вкладка "Вычисление" вычислителя основанного на Java.

Текущий контекст исполнения СВУ процедур (процедуры виджетов) Вы можете наблюдать на вкладке "Атрибуты" соответствующей страницы или виджета сеанса выполняемого проекта (Рис. 6.3). Для добавления некоторых промежуточных значений Вы можете временно добавить и подключить некоторые атрибуты к виджету/странице.

Рис. 6.3. Вкладка "Атрибуты" страницы или виджета сеанса выполняемого проекта.

6.2 Отладка последовательности исполнения

Данный метод отладки предусматривает размещение и/или включение отладочных сообщений и последующее наблюдение за ними в общем интерфейсе архивации и наблюдения сообщений (Рис. 6.4) или в соответствующем интерфейсе части OpenSCADA:

  • Вкладка "Диагностика" объекта контроллера источника данных (Рис. 6.5).
  • Вкладка "Диагностика" объекта проекта СВУ в конфигураторе (Рис. 6.6) или свойствах проекта режима разработки UI.Vision (Рис. 6.7).
Рис. 6.4. Общий интерфейс архивации и наблюдения сообщений.
Рис. 6.5. Вкладка "Диагностика" объекта контроллера источника данных.
Рис. 6.6. Вкладка "Диагностика" объекта проекта СВУ в конфигураторе.
Рис. 6.7. Вкладка "Диагностика" свойств проекта режима разработки UI.Vision.

Для добавления сообщений уровня отладки, или других уровней, к своей процедуре Вы можете использовать следующие функции:

  • Общее: SYS.message(), SYS.mess{Debug,Info,Note,Warning,Err,Crit,Alert,Emerg}() — Для формирования общих сообщений с произвольной категорией, которые в основном доступны для наблюдения из общего интерфейса архивации и наблюдения сообщений (Рис. 6.4).
  • Общее: SYS.*.messSys() — Для формирования системных сообщений с путём узла в качестве категории и с читабельным путём перед сообщением. Сообщения будут доступны для наблюдения в соответствующем интерфейсе диагностики части OpenSCADA (Рис. 6.5, 6.6, 6.7).
  • СВУ: this.mess{Debug,Info,Note,Warning,Err,Crit,Alert,Emerg}() — Для формирования системных сообщений с категорией, как путь виджета. Сообщения будут доступны для наблюдения из интерфейса диагностики СВУ (Рис. 6.6, 6.7).

At.png Отладочные сообщения (суффикс "Debug" или уровень 0), на Рабочей версии, будут доступны для наблюдения только после включения отладки, установки поля "Наименьший уровень" в "Отладка (0)" (Рис. 6.8), и выбора категории сообщений (Рис. 6.9), для деталей читайте тут! Однако включение и выключение отладочных сообщений позволяет вставлять отладочные сообщения в процедуры на постоянной основе в соответствии с расположением, в категории. Все остальные, неотладочные, сообщения будут отображаться всегда, для уровней выше или равным указанным глобально (Рис. 6.8).

Fig. 6.8. Установка поля "Наименьший уровень" в "Отладка (0)".
Fig. 6.9. Выбор отладочных сообщений для отладки.

At.png Внутренние или системные части объекта контроллера источника данных включаются для диагностики установкой свойства "Уровень" в "Отладка (0)" на собственном интерфейсе диагностики" (Fig. 6.5), независимо.