kkormsvr

Модуль управления процессом многокомпонентного дозирования. Предназначен для замены старого приложения kkormrcpsvr2.exe. Данный модуль требует включения в задачу.

promauto.gelios.dozkkmc

• Опрос дозаторов и управление процессом дозирования выполняют независимые друг от друга модули. Добавление нового типа дозатора в peripherial не требует изменения программного кода модуля kkormsvr.
• Возможность работать как на сервере (старый вариант), так и в составе ПЛК с использованием сервера в качестве удаленного СУБД. Работа на одной аппаратной платформе с ПЛК позволяет отказаться от дискретных сигналов управления дозаторами без ущерба общей скорости дозирования.
• Хранение оперативных данных в базе данных, т.е. там же где и хранятся все остальные данные. Старый вариант использовал для сохранения оперативных данных обычные файлы, что в случае сбоя может привести к рассинхронизации. Другой минус старого варианта при использовании на борту ПЛК - это частые операции записи в файл, что также является потенциально опасным.
• Работа одной транзакцией на цикл, что гарантирует целостность данных и положительно влияет на производительность приложения.
• Возможность отключения, включения и перезагрузки kkormsvr без прерывания выполнения задачи дозирования.
• При потери связи с удаленным СУБД восстановление происходит автоматически без прерывания выполнения задачи дозирования.
• Состав и именование тегов полностью обновлено. Новые теги кроме текущего состояния процесса также позволяют видеть названия рецептов и продуктов, выполнять сброс и приостановку работы линий.

Например, в jrobo 1 работает roboplant логика и выполняется опрос всех устройств ввода/вывода (peripherial), в т.ч. и многокомпонентных дозаторов, а также работает модуль jrbustcp в режиме server. В jrobo 2 работает модуль kkormsvr, взаимодействуя с локальной, либо удаленной базой данных, а теги по дозаторам поставляются при помощи модуля jrbustcp в режиме client. Использовать связку rpsvrtcp и rpclient недопустимо, т.к. данный протокол не поддерживает передачу тегов типа LONG.

Структура базы данных осталась прежней Модель базы данных. При миграции старой системы на kkormsvr НЕЛЬЗЯ работать непосредственно со старой базой как есть, а необходимо создать новую и сделать импорт.

plugin.kkormsvr:

  module.kksvr:
    database: db

    lines:
      - linenum:  1
        name:     "Линия 1"

        dosers:
          - name:       "d1"
            bind:       "D001"
            grouplevel:  0

            storages:
              1: 101, Бункер 101
              2: 102, Бункер 102
              3: 103, Бункер 103

          - name:       "d2"
            storages:
              1: 201
              2: 202
              3: 203

Теги старой версии (kkormrcpsvr2)

Во время выполнения задачи каждое изменение значения суммарного счетчика дозатора (другими словами - отвес) фиксируется в базе данных в соответствующих таблицах с ссылкой на задачу и рецепт, по которому работает задача. Если же счетчики меняют значение, когда линия остановлена и выполняемых задач нет, то в этой ситуации создается задача с пустым рецептом, и уже к ней привязывается отвес. Пустой рецепт создается автоматически с названием «ДОЗИРОВАНИЕ ВНЕ ЗАДАЧИ (РУЧНОЕ)» и kk_receipt.id равным 0.

Также при фиксировании отвеса вне задачи указывается продукт, который в данный момент назначен соответствующему бункеру. Если продукт не указан, создается «НЕИЗВЕСТНЫЙ ПРОДУКТ» c kk_product.id равным 0.

Для перехода со старого архиватора wessvr.exe на новый требуется перенести данные из старой базы данных в новую, создаваемою автоматически модулем wessvr. Описание действий по шагам:

• создать два модуля database для подключения к новой (не существующей) и старой (существующей) базам данных.

  plugin.database:
    module.db:
      type:        firebird
      dbname:      /database/kkorm_fb30.fdb
  
    module.dbold:
      type:        firebird
      dbname:      /database/old_kkorm_fb30.fdb
  
  plugin.kkormsvr:
    module.kksvr:
      database:  db
      
  plugin.task:
    module.taskmain:
      modules:
        - db
        - kksvr

• запустить систему и выполнить команды:

  kksvr:import dbold
  reload kksvr

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

В таблицах KK_TASK, KK_TASKCONTENT, KK_EXECUTE, KK_OUTPUT и KK_RASHOD данные сохраняются без циклической перезаписи, и таким образом постоянно накапливаются. Для удаления ненужных данных используется команда w:sweep <year>. Пример использования:

kksvr:sweep 2016

Данная команда, посылаемая модулю с именем kksvr, удаляет все записи старше 2016 года включительно.