Данный CODESYS форум содержит архивную копию русской ветви только для чтения. Для создания сообщений пожалуйста используйте актуальную международную платформу CODESYS Forum. Close

Для начинающих. Почему SFC именно такой?

2011-06-07
2012-07-08
1 2 > >> (Page 1 of 2)
  • Igor Petrov

    Igor Petrov - 2011-06-07

    SFC штука сильная и красивая. Правильную SFC программу легко читать, легко менять, легко обучить сопровождению заказчика. Он позволяет программисту проводить выходные и даже вечера далеко от работы. Такова цель.

    Проблема с SFC в том, что он резко не похож на все остальные МЭК языки. Его нужно понять и почувствовать. Получается всегда, но требует времени на размышления совсем свежей головой. К сожалению, она обычно забита кучей более срочных дел

    Начинающие не понимают SFC, а опытные авторы документации не понимают, что тут вообще можно не понимать?

    Предлагаю помочь начинающим силами самих начинающих. Начну плавно поэтапно, а вы подключайтесь с вопросами. Вмешательство имеющих опыт, крайне приветствуется.

    Возьмем очень простую общепонятную задачу. Начнем издалека и постепенно придем в SFC. Этот пример был рассмотрен на конференции 2011. Постараемся пока не отвлекаться на приемы отладки, моделирования и др. и пр. Потом, если будет интерес.

    Итак, снова наш старый светофор. В них еще была фаза красно-желтого перед зеленым. В виде картинки это выражается так:

    По оси X время в секундах. Общий цикл 40 секунд. Все фазы по 10 сек.

    Возьмем любознательного школьника Вову, владеющего азами информатики, но не проходившего ПЛК. Попросим его записать этот алгоритм словами. Получится нечто типа:

    ВКЛ xGreen
    ЖДАТЬ 10
    ВЫКЛ xGreen
    ВКЛ xYellow
    ЖДАТЬ 10
    ВЫКЛ xYellow
    ВКЛ xRed
    ЖДАТЬ 10
    ВКЛ xYellow 
    ЖДАТЬ 10
    ВЫКЛ xYellow
    ВЫКЛ xRed
    ПЕРЕХОД на начало
    

    Все очень просто и интуитивно понятно. К этой программе мы еще вернемся. Придумаем ей имя. Пусть будет ‘Интуитивный Алгоритм’, сокращенно метод ‘Иа’.

    Вова легко сможет реализовать метод ИА на языке Бейсик или Си с использованием функции задержки sleep. Даем ему мануал на ПЛК. Он шустро начинает искать функцию задержки выполнения. Ее нет принципиально! Очевидное предложение: 1) никчемный девайс об стену, 2) мануал в топку.

    Но, Вова парень наш. Сдаваться он не обучен. В его голове засел вопрос : ‘Почему в ПЛК нет команды приостановки программы?’

    IMG: Изображение

    IMG: Изображение

     
  • Igor Petrov

    Igor Petrov - 2011-06-08

    Отступление: о таймерах принципах ПЛК

    Смотрим на алгоритм Иа. Он прекрасен для одного светофора. А если добавить второй с циклом вдвое больше? Ну, тогда вставим еще несколько команд ЖДАТЬ и включений. А если таких светофоров сто или тысяча и с разными временами. Проблема, однако. Правильный ПЛК должен быть устроен так, чтобы ее не возникало.

    Он работает как автомат. Программа получает значения всех входов, вырабатывает решение и выдает его на выход. Классический цикл ПЛК.

    В идеале, допустимое число разных вычислений (обслуживаний разных светофоров и пр.), в одной программе, которые делаются одновременно, должно стремиться к бесконечности. Соответственно время цикла должно стремиться к нулю. Тогда программировать будет очень легко. Отсюда следует мысль: затормаживать выполнение программы ПЛК нельзя. Оно должно быть максимально коротким.
    Задача ПЛК реагировать на выходы в реальном времени. Застрять в программе и делать там нечто громадное и долгое, типа сортировки массива методом пузырька, нельзя. Программа должна коротко поработать, отдать управление на выходы, еще немного посчитать, опять отдать на выходы и так далее. (Это упрощенно, для начинающих, прошу не пинать). Она должна выполняться не монолитным блоком, а небольшими шажками. Не стоит все вычисления повторять постоянно. Делаем только то, что нужно сейчас.

    Отсюда растет проблема А – декомпозиции программы, ее разбиения на компактные кусочки. Это вызывает затруднения у начинающих и часто обсуждается (например, сегодня). Из этих же рассуждений следует проблема Б – цикл должен быть коротким. Именно он определяет время реакции на внешние события! Это важно для ПЛК. Неважно сколько умножений или делений способен сделать процессор в секунду. ПЛК должен строчить как швейная машинка – частыми короткими стежками. Не нужно пытаться пришить весь рукав одним движением.

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

    Ну и как же быть с таймерами, если тормозить работу нельзя?

    Да точно так, как это делаем мы сами! Заводим таймер (будильник) или кучу таймеров и занимаемся другими делами, пока не будет пора. Таймер для ПЛК это практически внешний прибор с выходом готовности.

    Возьмем таймер TON. Он может иметь много независимых экземпляров. Каждый работает сам по себе.

    Утомил теориями? Переходим к практике. Для разминки, создаем пустой проект и делаем в нем 1 таймер так, чтобы он отсчитывал 4 секунды, сбрасывался в 0 и так крутился бесконечно. На любом языке, SFC пока не трогаем.

     
  • Igor Petrov

    Igor Petrov - 2011-06-14

    Для ускорения отладки светофора поделим времена на 10. Т.е. будем переключаться раз в секунду. Общее время таймера 4 секунды.

    Создадим пустой проект. Вариантов программирования таймера много. Я объявил в разделе объявлений переменную для времени процесса и экземпляр таймера :

    tProcessTime : TIME;
    mTimer : TON := (PT:= T#60s);
    

    Здесь сразу ему на вход задается заведомо большое время. Мы будем сбрасывать его раньше.
    На ST:

    tmTimer(IN := tProcessTime < T#4s, ET => tProcessTime);
    

    Если время процесса меньше 4 секунды, то на входе таймера логическая единица. Иначе, ноль, формирующий рестарт.

    На FBD :

    Собственно все. Подключаемся к эмулятору или ПЛК и проверяем работу циклического таймера.

    IMG: Изображение

     
  • Anonymous - 2011-06-17

    Originally created by: Дмитрий К

    Спасибо!)

    Цитата:
    Начинающие не понимают SFC, а опытные авторы документации не понимают, что тут вообще можно не понимать?
    -именно так!
    Цитата:
    Утомил теориями?
    -ничуть нет. Как раз, очень доступное объяснение «философии» SFC.
    После предыдущих Ваших подсказок я постепенно сам к этому пришел. И данная статья – дополнительное подтверждение для меня того, что я начинаю правильно понимать концепцию работы SFC.
    Пример со светофором, ранее, оказался мне, признаюсь, «не по зубам». Я добросовестно пытался его осилить. Но, вот беда: по отдельности, по блокам - что, как и для чего работает – конечно же, понятно. Однако, каким образом эти отдельные компоненты взаимодействуют между собой, образуя целостную программу – «схватить» умом, такому новичку, как я, увы, оказалось не под силу. Тем более, что, написана программа не на 2-х, а сразу на 3-х языках. Не хватило, наверное, детального и последовательного «разжевывания» цепочки происходящих событий. Причем, не только «со стороны» (красный, синий, зеленый), а именно в программе (…присваиваем переменной X1 значение «TRUE». Так как X1 находится на входе таймера Т1, таймер начинает считать… маркер пошел дальше… классификатор S оставляет действие «в работе» пока его не прервет классификатор R в шаге Step11 … - и так далее). Я утрирую.
    Даже, может быть, сначала, лучше взять пример совсем простой. Из 3-х блоков, например. И показать, как они ведут себя в том или ином случае. Чтобы человек понял «природу» SFC. Пусть это удлинит самый начальный этап знакомства с продуктом, зато, обучающийся поймет основной принцип его работы (а не «свернет шею» и не пойдет искать чего-нибудь попроще). А дальше ему сразу становится значительно легче и усваивается все быстрее. Как только принцип действия ясен, остальное – уже накопление информации и опыта. Какие есть команды, блоки и переменные – лезь в библиотеку и находи! Даже то, как управляется действие – безусловно, важная информация – но, она нужна уже после того, как человек понял главный смысл работы программы.
    Извините за общую длину высказывания, но, может быть, это поможет Вам в работе с такими, как я)).
    Пример «кашеварки», кстати, уже гораздо доступнее для понимания. Однако, все-таки, даже в нем, мне кажется, можно было акцентировать внимание именно на принципе работы SFC. Ведь пример как раз для «чайников», которые не знают о программе «ну, совсем ничего…». Внимание читающего последовательность и смысл шагов «ловит», а принцип работы – упускает. Т.е., здесь нужно «носом ткнуть».
    Просто потому, что не способен ребенок сразу и ноги переставлять, и равновесие держать.

    И, если можно, вопрос. Искал и в книжке и в статьях, не попалось мне.
    Если я ставлю в действие счет (Х1:=Х1+1;), то, за каждый цикл у меня прибавляется не 1, как мне хочется, а 2 (по причине, о которой я уже прочитал; действие такого рода выполняется дважды: при активации и при отключении его). Как сделать, чтобы считало по одному?

     
  • Igor Petrov

    Igor Petrov - 2011-06-17

    Спасибо за отклик. Я уж думал не актуальная тема. Буду продолжать, пока цейтнот

    Дмитрий К писал(а):
    Если я ставлю в действие счет (Х1:=Х1+1;), то, за каждый цикл у меня прибавляется не 1, как мне хочется, а 2

    Видимо имеется в виду МЭК действие с классификатором P? Тут есть предложение, обсужденное и принятое в работу в ‘кулуарах конференции’. Отложим ближе к концу темы.

    X+1 нужно написать во входное или выходное действие. Получим число проходов

     
  • Igor Petrov

    Igor Petrov - 2011-06-24

    Итак, имеем циклический таймер. Остается по нему включать выходы в определенных комбинациях. Тут большого ума не нужно. Элементарные логические операции. На ST:

    xGreen :=  tProcessTime < T#1S;
    xRed :=  tProcessTime > T#2S;
    xYellow  :=  (tProcessTime > T#1S [b]AND[/b] tProcessTime < T#2S) [b]OR[/b] tProcessTime > T#3S;
    

    Это классическая программа для ПЛК. Обычно оформляется функциональным блоком (ФБ). В сравнении с программой Иа тут есть большой прогресс – нет никакой сложности сделать сотню экземпляров ФБ и асинхронно управлять кучей светофоров. Программа стала масштабируемой! Однако, что-то мне в ней не нравится.

    Попробуем на FBD:

    На LD:

    Очень даже неплохо. В режиме Онлайн видно как ‘складываются’ ветви, в каком порядке и почему. В Оффлайне не так все очевидно.

    Логический подход хорош для огромного числа случаев. Как видите, применим он и для последовательностных задач. Однако, невооруженным глазом быстро ухватить последовательность работы тут не просто. Может ли загореться желтый и красный одновременно? А зеленый и желтый? Мгновенно и не ответишь, нужно сложить цепочки в голове. Проблема В: последовательность действий должна быть выражена наглядно.

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

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

    IMG: Изображение

    IMG: Изображение

     
  • Igor Petrov

    Igor Petrov - 2011-07-01

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

    Тут все понятно. Состояния можем пронумеровать. Пусть одна переменная определяет состояние. Крутимся в каждом состоянии, держим выходы, контролируем условия перехода в другое состояние. Напрашивается сделать это на ST с оператором CASE.
    Да, про таймер забыли. Это еще один автомат с одним состоянием:

    Его обслуживаем отдельно. Получается вот такая программа:

    tmTimer(IN := tProcessTime < T#4S, ET => tProcessTime);
    CASE iState OF
     1:  
       xGreen := TRUE;   
        xRed := xYellow := FALSE;
       
       IF tProcessTime > T#1S THEN iState := 2; END_IF
    2:   xYellow := TRUE;
       xRed := xGreen := FALSE;
       
       IF tProcessTime > T#2S THEN iState := 3; END_IF
    3:   xRed := TRUE;
       xYellow := xGreen := FALSE;
       
       IF tProcessTime > T#3S THEN iState := 4; END_IF
       
    4:    xRed := xYellow := TRUE;
       xGreen := FALSE;
       
       IF tProcessTime > T#4S THEN iState := 1; END_IF
          
    END_CASE 
    

    Что сказать про эту программу?
    Четко выраженные состояния
    Строгая регулярная структура
    Простота кодирования
    Простота сопровождения
    Очевидное быстродействие
    Красота, лепота

    Надеюсь с автоматным подходом примерно понятно. Это хороший и полезный подход. Очень рекомендую новичкам попрактиковаться в нем. Например, реализовать ее в FBD или LD. Можно даже развить тему и применить мой любимый табличный метод программирования. Делаем массив выходов, массив состояний и по индексу (состоянию) присваиваем все переменные. Автомат реализуется в 1 строчку кода, а вся логика работы кодируется исключительно в таблице. (Такая программа наверняка есть в тетрадке Михаила Швецова ‘101 способ программирования светофора’).

    Сильная штука автомат, однако..

    IMG: Изображение

    IMG: Изображение

     
  • Anonymous - 2011-07-03

    Originally created by: Дмитрий К

    Здорово!
    Очень полезный материал. Спасибо!

     
  • Igor Petrov

    Igor Petrov - 2011-07-04

    Мы подобрались к самому ключевому моменту. Программы на всех языках МЭК (SFC пока не трогаем) в каждом рабочем цикле выполняются сверху до низу! Что мы сделали в автоматной программе? Мы искусственно сделали так, что в одном цикле вызова выполнятся только нужный маленький кусок кода!!! Конкретно при iState = 2 будет работать только кусок:

    CASE iState OF
    ...
    2:   xYellow := TRUE;
       xRed := xGreen := FALSE;
       
       IF tProcessTime > T#2S THEN iState := 3; END_IF[/color]
    ...
    ...
    END_CASE
    

    Мы не скачем по вс6ему кейсу, а совершенно осмысленно умышленно крутим одно состояние – делаем нужную работу и контролируем условия ухода. Действуем как в известном анекдоте про молодого и старого быков – ‘никаких быстренько сбегаем, мы закончим начатую трапезу, спокойно спустимся и ..’
    Чтобы перепрыгнуть дальше, на следующий шаг, нужно увеличить iState и отдать управление системе. Она приведет в порядок в/в и сразу же вызовет наш POU, но активным будет уже другое состояние. Мы умышленно крутимся в одном состоянии, пока оно активно, игнорируя код всех других состояний. Каждое состояние – это как отдельный маленький ПЛК. Поработал один, выключился, отдал эстафету другому.
    Дмитрий, что Вы думаете насчет в одной из следующих работ применить автоматный подход? Я не намекаю на SFC, до него еще далеко. Иногда автомат предпочтительнее. Пока вопрос только по нему. Насколько автоматный подход понятен? Что смущает?

     
  • Anonymous - 2011-07-04

    Originally created by: Дмитрий К

    Игорь, принцип понятен!
    Правда, процесс усвоения у меня в голове происходит как-то постепенно. Понять – это ведь одно. А понять так, чтобы эффективно использовать – это другое. Однако, все, что узнаю, пытаюсь, для начала, применить к одной своей полутренировочной программе, которая должна запускать бензогенератор (пропадание основной сети – зажигание – старт – неудачная попытка – еще раз старт - … - подключение нагрузки – или, авария – переключение на сеть - предусмотреть экономичный режим и всякие защиты – ну и еще мелочи и т.д.). Некоторое время назад я сделал такую программу на FBD для SIEMENS LOGO. Она получилась сложной, запутанной и не идеальной. И я решил взяться за более интересные варианты программирования и контроллеры.
    Данный автоматный подход с таким кодированием таймера, конечно же, оказался мне очень интересен, и я попытался «сделать» таким образом участок программы «старт – стоп» с передышками и с отключением действия в случаях: появление сети; перебор по счетчику неудачных запусков…. Наверное, поспешил. Пока не понял. Нужно еще посидеть, повозиться – тогда отрапортую!). Вообще, я сразу начал делать эту программу в SFC, т.к., почему-то, изначально мне показалось, что SFC для такого рода задач должен быть просто идеален. Нагляден, все по ветвям, из разных участков можно включать и выключать одни и те же действия и т.д. И принцип автомата – конечно, нужно бы мне еще «разглядеть» получше)

     
  • Igor Petrov

    Igor Petrov - 2011-07-05

    Дмитрий К писал(а):
    Правда, процесс усвоения у меня в голове происходит как-то постепенно. Понять – это ведь одно. А понять так, чтобы эффективно использовать – это другое.

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

    'http://ru.wikipedia.org/wiki/Автоматное_программирование'

    В пятницу я писал программу ведения архива в файл на диске в формате Excel .csv. Это шкаф термопрогона радиооборудования. Контроллер формирует суточные циклы разогрева и охлаждения. Полное испытание 20 дней. Данные пишутся раз в 10 минут. Строка записи сложная. Она форматируется и собирается поэтапно, короткими кусочками в фоновой задаче. По кнопке СТОП сразу пишу в iState номер состояния ‘Закрыть файл’, вообще не думая в каком состоянии сейчас живет программа. С автоматом на ST получилось красиво. Отлаживать вообще ничего не пришлось.

    В конечном автомате на CASE состояние кодируется одной переменной. Это большой плюс, он же основной минус. Хорошо когда активным может быть только одно состояние и возможны дальние переходы. Один поток выполнения = один автомат

    Однако, как быть когда процесс распараллеливается? Т.е. надо чтобы активными могли быть несколько состояний одновременно? Требуется распараллелить работы. Конечно, можно сделать композицию автоматов, но это уже не так красиво и не интуитивно. Для этого есть другой математический аппарат.

     
  • Igor Petrov

    Igor Petrov - 2011-07-11

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

    Попробуем отобразить процесс так, как он развивается. Рисуем кружками состояния, по порядку (пусть будет сверху вниз), последовательно соединяем и на линиях переходов записываем условия перехода. Принцип передачи эстафетной палочки – маркера. Четко понятно кто и за кем бежит. Принял эстафету – беги, отдал – отдыхай. Можно бежать и группой, взяв по фрагменту эстафетной палочки. Но тут понятно, что финиш делает последний. Маркер (эстафетная палочка) должна собраться целиком.

    Для нашего светофора это нарисуется в таком виде:

    Голубые кружки – это 2 маркера. Сейчас активен таймер и зеленый шаг одновременно.

    Мы нарисовали сеть Петри. Она прекрасно отображает последовательностные процессы. Распараллеливание не представляет проблемы. Ветвления по условиям тоже. Все интуитивно понятно, но погуглить на досуге материалы по сетям Петри полезно. Их применение значительно шире нашей темы. Ниже мы обобщим правила SFC. Но лучше бы их не запоминать, а понять самостоятельно. Все их корни растут из сетей Петри.

    В старые времена мечтать о графическом дисплее для ПЛК было бы глупой фантастикой. В лучшем случае, текстовый дисплей. ’Рисовать’ можно было только символами псевдографики. Ну, ничего страшного если вместо окружностей будут прямоугольники. Попробуем перерисовать нашу светофорную сеть в стиле кубизма.

    IMG: Изображение

     
  • Igor Petrov

    Igor Petrov - 2011-07-12

    Получается вот так:

    Уф. Наконец-то нарисовался SFC

    Верхний шаг называется Init. Он выделен двойной рамкой. Это начальный шаг (Начало). При желании его можно переименовать. (В CoDeSys V3 любой шаг можно сделать начальным).

    За ним в условии перехода стоит TRUE. Это нормально и является типовым приемом. Переход безусловно разрешен. Будут выполнены действия шага и маркер отдан дальше. Кроме таких ‘пустых’ переходов могут быть и пустые шаги. Это тоже нормально. Шаг может просто ждать, без активной работы. Например, попадаем в аварийное состояние и висим там пока оператор не разрешит продолжить работу.

    В других переходах условия записаны рядом. В нашем случае переходы идут по времени таймера. Для более сложных условий можно дать переходу имя и описать его в отдельном окошке. Тут может быть что угодно, главное чтобы на выходе был логический результат. На схеме будет видно только имя условия.
    В наших шагах есть закрашенные уголки. Это говорит о том, что внутри шага запрятан код действия. Он может быть написан на любом языке. Я использовал ST. Для таймера код знакомый:

    tmTimer(IN := tProcessTime < T#4S, ET => tProcessTime);
    

    Для светофорных шагов он сводится к управлению выходами. Например, для зеленого:

    xGreen := TRUE;   
    xRed := xYellow := FALSE;
    

    В этой SFC программе все интуитивно понятно, если есть понимание того о чем мы уже говорили выше: программа вызывается извне циклически; в каждом цикле вызова работают только те шаги, которые имеют маркеры. Программа сама разбивается на короткие кусочки. Цикл будет маленьким, реакция на выходах контроллера быстрой. Это базовые принципы. Они позволяют избежать проблем А и Б.

    Все, кто первый раз пишут SFC программу, недовольны последним фактом. Они пытаются сделать цикл FOR из нескольких шагов и удивляются, почему же он не прокручивается при каждом вызове POU? Некоторые даже пишут ругательные письма в техподдержку о якобы обнаруженных страшных ошибках. Понять базовые принципы не так просто, как кажется. Если они воспринимаются как логичные и правильные, то программирование на SFC не представит сложности.

    Если вы только осваиваете SFC, то тут нужно притормозить. Сделайте этот пример самостоятельно с нуля. Проект намеренно не прикладываю. Запустите его в эмуляторе в онлайн. В V3 самостоятельно изучите тему Макросов. Попробуйте левую ветку с шагами светофора разместить в макрос. Должна получиться диаграмма с Инит и двумя параллельными шагами: макросом и таймером.

    IMG: Изображение

     
  • Igor Petrov

    Igor Petrov - 2011-07-12

    Наш студент Вова изучил теорию и выполнил пример. Его выводы всегда логичны:
    1) Неужели в языке, заточенном на последовательностные алгоритмы, нельзя было встроить нормальные задержки? Почему я обязан извращаться с таймерами?
    2) SFC вообще языком назвать нельзя. Это пустышка. Весь код пишется на других языках. На чистом SFC ничего запрограммировать нельзя принципиально.

    Минуту терпения. Счастье близко.

    В каждом шаге SFC есть неявная переменная t, которая показывает время активности шага. Пишем через точку: имя_шага.t. Стоит попробовать. Таймер в топку:

    Вот же она нормальная задержка! Оказывается, есть она в ПЛК.

    Но, обратите внимание, что ПЛК не висит тупо в задержке, он работает – крутит действие шага. Параллельно могут работать другие шаги и другие программы.

    IMG: Изображение

     
  • Igor Petrov

    Igor Petrov - 2011-07-12

    Действия в SFC не обязательно прятать внутрь шага. Существуют ‘МЭК-действия’. Они приклеиваются к шагам справа. В них присутствует индекс-классификатор, уточняющий способ приклеивания. Например, N говорит о том, что действие активно пока активен шаг. Действием может быть подпрограмма или просто логическая переменная. Таким способом мы можем приклеить выходы непосредственно к шагам. Весь ST код в топку. Только чистый SFC:

    Ничего не напоминает?
    Это же метод ‘Иа’! Самое интуитивное, что только может быть.
    Мы начали с элементарной программы. Потом пустились в сложности и.. Круг замкнулся

    Нет ничего проще и понятнее SFC.

    IMG: Изображение

    IMG: Изображение

     
  • Anonymous - 2011-07-13

    Originally created by: Дмитрий К

    Игорь, 100% понятно!! Очень здорово Вы расписали. Большое спасибо! Многое я уже именно так себе и представлял, однако, очень полезно было пройтись столь последовательно и в различных вариантах кодирования одного и того же процесса. Сразу все еще более прояснилось.
    Программу «светофор» проштудировал в 2-х вариантах: один - как Ваш последний; второй – МЭК– вариант с параллельной ветвью и МЭК действием на ST. Все работает. Хотя, с таймером, закодированным <tmtimer(in t#4s,="" :="tProcessTime" <="" et=""> tProcessTime);> немного провозился, т.к., в режиме эмуляции он вяз в последнем шаге. В конце концов, методом «тыка» добавил знак «=» после знака «<» и – ура!! - все поехало!!))). Хотя, не знаю, действительно ли правильно поступил, т.к., не очень понимаю, почему таймер в данном случае работает именно так. Ведь, в описании к CoDeSys такого способа кодирования TON, вроде бы, не дается. Впрямую, по крайней мере. Или я чего-то не углядел… </tmtimer(in>

    Цитата:
    В V3 самостоятельно изучите тему Макросов. Попробуйте левую ветку с шагами светофора разместить в макрос.

    Пока, к сожалению, не добрался ни до V3, ни до макросов. Поскольку начал я с V2, то думал, что, для начала, быстрее будет разобраться в уже знакомом продукте. Хочется ведь скорее «в бой», применить, хоть что-нибудь, «на деле» . А времени на совершенствования, увы, жизнь оставляет совсем чуть-чуть)).

     
  • Anonymous - 2011-07-13

    Originally created by: Дмитрий К

    это, на всякий случай, что у меня получилось

    опять светофор 1, SFC.pro [18.7 КБ]

     
  • Anonymous - 2011-07-14

    Originally created by: Дмитрий К

    Но:

    Цитата:
    А если таких светофоров сто или тысяча и с разными временами.

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

    Т.е., в нашем случае, если я правильно понял, можно запрограммировать в параллельных ветвях несколько светофоров, работа которых укладывается в цикл одного таймера.
    Однако, как быть в SFC, если одновременно должны работать несколько светофоров в разных, по времени, циклах?? Ведь условие перехода для параллельных ветвей – одно. Они получаются замкнутыми друг на друга, по времени?

     
  • Igor Petrov

    Igor Petrov - 2011-07-14

    Дмитрий К писал(а):
    это, на всякий случай, что у меня получилось

    Хорошо получилось.

    Все верно. Далее в переходах используем внутренне время активности шага. Например: Red.t > T#1s. Таймер и его ветку выбрасываем совсем. Получается простейший вариант.

    В V2.3 полноценный SFC. В V3 добавлены возможности изменять начальный шаг, макросы, редактор более ‘умный’. В V2.3 он просто не позволяет изменить схему так, чтобы ее структура стала неправильной. Это иногда удивляет. Пытаешься что-то сделать, а оно не делается. V3 делает и автоматически корректирует.

    В начале я обещал рассказать, что мы обсуждали на конференции в этом году про SFC. По первой редакции стандарта МЭК, действие P вызывается дважды подряд. Если с P связана логическая переменная, то она сначала взводится, потом сбрасывается. Получается 1 импульс. Это хорошо. Но, двойной вызов это не всегда то, что хотелось бы. Кроме того, было бы удобнее использовать МЭК действия везде, в том числе для входного и выходного. Отсюда растет идея ввести дополнительно классификаторы P0 и P1 аналогичные входному и выходному. Вторая редакция стандарта МЭК их предусматривает.

     
  • Igor Petrov

    Igor Petrov - 2011-07-14

    Дмитрий К писал(а):
    Однако, как быть в SFC, если одновременно должны работать несколько светофоров в разных, по времени, циклах??

    Делаем светофор функциональным блоком (ФБ). Времена циклов делаем входными переменными. В программе объявляем много экземпляров ФБ. Можно даже массив.

    Отдельная тема – обработка ошибок и принудительное изменение поведения SFC POU. Можем позднее рассмотреть. Ничего хитрого. См. ‘Флаги SFC’. Рулить ими нужно из вызывающей программы. Отсюда растет правило: Не пишите PLC_PRG на SFC. Делайте отдельный ФБ или программу.

     
  • Anonymous - 2011-07-28

    Originally created by: Дмитрий К

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

    ST, светофоры.pro [23.89 КБ]

     
  • Anonymous - 2011-07-28

    Originally created by: Дмитрий К

    Уже понял, что поспешил).
    У меня из основной программы можно изменять времена циклов, но, нельзя изменять длительности каждого из цветов.

     
  • Anonymous - 2011-07-29

    Originally created by: Дмитрий К

    Вот, переделал)
    Правда, возникает вопрос. Когда только включаю эмулятор, визуально, все 3 светофора начинают работать синхронно (в одном зеленый горит 1с, в другом -2с и т.д.), переключаясь одновременно, с разницей в секунды. Затем, эта синхронность нарушается. И, соответственно, это означает, что и время, по секундам, выдерживается лишь приблизительно.

    ST, светофоры.pro [23.88 КБ]

     
  • Yougi

    Yougi - 2011-07-31

    Цитата:
    Далее в переходах используем внутренне время активности шага. Например: Red.t > T#1s.

    А в стрюкциях ( User Manual) написано

    Цитата:
    Для МЭК шагов определена переменная <stepname>.t (<stepname>.t служит для внутренних целей).</stepname></stepname>

    Или "для внутренних целей" означает, что в неё писать нельзя?

     
  • codemo

    codemo - 2011-08-07

    Спасибо за доходчивое объяснение.

    Только SFC на этой диаграмме не рабочий:
    l viewtopic.php?p=2362#p2362 l
    т.к. условие перехода в самом низу (tProcessTime > T#4s) никогда не выполнится, т.к. MyTime зацикливает tProcessTime по модулю 4s.

    Есть вопрос по отображению работы SFC на реальный PLC.
    Опишите циклы PLC для этого примера светофора. Какие шаги исполняются на каждом цикле PLC. Я предполагаю так:
    (1 цикл) выполняется Init, выполняется условие перехода после Init, выполняется Green, условие перехода после Green не выполняется, поэтому помечаем шаг Green и выходим из цикла.
    (2 цикл) начинаем выполнение с помеченного шага Green, выполняем его, условие перехода не выполняется, поэтому помечаем шаг Green и выходим из цикла.
    (допустим 100 цикл) начинаем выполнение с помеченного шага Green, выполняем его, условие перехода выполняется (прошло больше 1 сек), выполняем блок Yellow, условие перехода после Yellow не выполняется, поэтому помечаем шаг Yellow и выходим из цикла.

    т.е. насколько я понимаю, выполнение на каждом цикле начинается с последнего помеченного цилка, и продолжается до упора в false-переход, при этом активный шаг помечаем (с него начинаем выполнение со следующего цикла).

    а что происходит при распараллеливании (ветвь)?

     
1 2 > >> (Page 1 of 2)