Для выполнения последовательных команд в Trace Mode 6 можно было выполнить через шаблон программы, например, на ST. Десяток IF_THEN_ELSE с двумя десятками GOTO. И это если последовательность прямая и явная (1-2-3-4...), а если есть условия при которых шаг выполняется или требуется переход с пропуском других шагов, то код разрастается дополнительными ветвями кода, в который можно запутаться через 5 минут...
В Trace Mode 7 есть Call.AsyncCollection. С одноименным каналом из 6-ой версии общее только название.
Скажем прямо, канал значительно сложнее каналов MOVE, SQL и даже PROGRAM. Но если разобраться, то огромный пласт задач будет решаться без программирования.
Основная задача - последовательная (и не очень) отработка рецептов. Но мы разберем на примере запуска печей.
Первым делом, что бы создать Call.AsyncCollection, необходимо создать Источник - Алгоритм - Управление - AsyncCollection. Теперь переносим источник в узел и получаем канал Call, настроенный на работу.
Подробное описание аргументов есть во встроенной Справочной Системе. Коротко:
Аргументы канала:
arg0, step_name – название шага;
arg1, step_tmout – таймаут в мс на исполнение шага; задается, если необходимо контролировать время на выполнение команды. Эту настройку рассмотрим на примере ниже;
arg2, send_waitread –
- если аргументы типа IN, то это УСЛОВИЕ выполнения данного шага;
- если аргумент типа OUT, то это КОМАНДА данного шага.
Каждый шаг имеет 3 таких аргумента (arg2, arg3 и arg4)., в любой конфигурации (условий от 0 до 2 и команд от 1 до 3). Естественно, условие (аргументы in) должны быть до команды (аргумента out).
arg5, send_value – тип данного аргумента может быть любой (IN или OUT), аргумент может иметь привязку. Аргумент задает значение, которое используется при обработке аргумента destination;
arg6, destination – по умолчанию тип данных аргументов send_value и destination – REAL, но разработчик может задать любой тип данных (кроме STRING).
- Если тип данного аргумента – OUT, в него записывается значение аргумента send_value и выполняется переход.
- Если тип – IN, никаких действий нет, а для перехода должно выполняться условие (зависит от типа данных аргументов и (44) Модификатора).
Теперь разберем пример.
Допустим, есть три печки, которые необходимо запускать последовательно. Можно сделать три кнопки, которые Оператор будет нажимать последовательно (100 раз сделает правильно, а на сто первый...). Можно написать программу с шагами последовательного запуска печей. А можно...
Три канала Discrete_Печь* - PDA канал, для управления печами. О dpa- каналах отдельно или в Справке и поставляемом demo-примере.
Привязка 99, mCMD - атрибут для отправки команды (2 - включить печь)
Привязка 84, aSTS - атрибут состояния устройства, в данном случае используется как условие перехода к следующему шагу (если печь включилась)
Для наглядности, в примерах вместо aSTS использовалась привязка в атрибуту 100, b_0_1 (значение 0 и 1 битов).
Очевидно, что первый шаг начинается просто по команде по кнопке. Но второй и последующие должны начинаться ЕСЛИ предыдущая печь включилась.
А если необходимо первый запустить один, а после запустить два остальных одновременно? Первое изменение - всего два шага ( и на втором подается две команды в свои mCMD)
Но если одно из устройств НЕ отработает команду? Для начала вопрос - как узнать, что устройство не отработало команду? Самое простое решение заключается в контроле времени на выполнение команды. Если известно, что печь запускается за 1 секунду (значение условное, для наглядного пример), но за это время устройство не сообщило о запуске, то у нас проблемка...
В AsyncCollection можно задать время step_tmout. В рамках примера у моделей печи задано время 5 секунд, зададим в канале Asynccollection 1 секунду для второй печи последовательного запуска.
Тогда получим вот. Для удобства на экран выведено значение атрибута Аппаратное значение канала AsyncCollection, что бы видеть на каком аргументе сейчас отработка (и на каком аргументе остановится работа)
Печь не успела включиться за заданную 1 секунду и процесс встал на 14-ом аргументе, т.е на равенстве состояния и заданного значения.
Так же можно в настройках самого AsyncCollection выставить настройку контроля достоверности привязанных каналов. В случае недостоверности, весь алгоритм будет заблокирован до запуска.
Теперь Вы можете управлять устройствами поочередно или групповым образом. И контролировать проблемы.
Успехов в освоении Программы и применении полученного опыта! 👽
Список авторских статей о Trace Mode 7
