Как Вы, возможно, знаете PLCOpen разработали документ Creating PLCopen Compliant Libraries, в котором описаны стандартные интерфейсы и поведения функциональных блоков разработанных на языках стандарта МЭК-61131 (всем нам знакомые FBD, CFC, ST и т.д.).
Не так давно этот документ был переведен на русский язык (доступен по ссылке).
В стандарте приведены примеры для всех "моделей поведения", но их использование в проекте затруднено т.к. все примеры приведены в виде картинок и текст придется перенабирать вручную.
В этой теме я буду постепенно выкладывать исходный код ФБ (на языке ST) тех моделей поведения, которые использовал в работе.
Так Вы сможете просто
скопировать перечисление, содержащее состояния ФБ в Ваш проект;
скопировать "скелет" ФБ;
доработать "скелет" ФБ в соответствии с Вашей задачей (места, которые необходимо доработать под задачу выделил комментариями (* TODO: *)).
без необходимости перевводить код ФБ вручную.
Если Вы использовали модель поведения, которой еще нет в теме - присылайте исходный код, я добавлю его в тему.
Итак:
перечисление, содержащее все состояния ФБ:
Префикс BM - сокращение от Behavior model (модель поведения)
Код:
(*
Перечисление, содержащее все состояния ФБ
*)
TYPE BM_STATES :
(
BM_DORMANT := 0, (* Ожидание запуска *)
BM_EXECUTING := 1, (* Выполнение операции *)
BM_DONE := 2, (* Завершение операции *)
BM_ERROR := 3, (* Ошибка *)
BM_RESETTING := 4, (* Переинициализация *)
BM_ABORTING := 5, (* Прерывание работы ФБ *)
BM_ABORTED := 6 (* Работа ФБ прервана *)
);
END_TYPE
ETrig
Старт по переднему фронту;
Нет возможности прерывания до окончания работы блока;
m_xNeedToChangeState := TRUE;
WHILE m_xNeedToChangeState DO
m_xNeedToChangeState := FALSE;
CASE m_eState OF
BM_DORMANT:
IF xExecute THEN
xBusy := TRUE;
m_eState := BM_EXECUTING;
m_xNeedToChangeState := TRUE;
(* TODO: запомнить состояние остальных входов *)
END_IF
BM_EXECUTING:
(* TODO: m_xIsExecutionDone должно стать TRUE, когда выполнение операции завершено успешно *)
m_xIsExecutionDone := TRUE;
(* TODO: m_xIsExecutionFail должно стать TRUE, когда возникла ошибка выполнения операции *)
m_xIsExecutionFail := FALSE;
IF m_xIsExecutionFail THEN
m_eState := BM_ERROR;
m_xNeedToChangeState := TRUE;
ELSIF m_xIsExecutionDone THEN
m_eState := BM_DONE;
m_xNeedToChangeState := TRUE;
END_IF
BM_DONE:
IF xDone AND (m_xResetRequest OR NOT xExecute) THEN
m_eState := BM_RESETTING;
m_xNeedToChangeState:= TRUE;
ELSE
xBusy := FALSE;
xDone := TRUE;
m_xResetRequest := NOT xExecute;
m_xNeedToChangeState:= FALSE;
END_IF
BM_ERROR:
IF xError AND (m_xResetRequest OR NOT xExecute) THEN
m_eState := BM_RESETTING;
m_xNeedToChangeState:= TRUE;
ELSE
xBusy := FALSE;
xError := TRUE;
m_xResetRequest := NOT xExecute;
m_xNeedToChangeState:= FALSE;
END_IF
BM_RESETTING:
(* TODO: освобождение ресурсов здесь *)
xBusy := FALSE;
xDone := FALSE;
xError := FALSE;
m_eState := BM_DORMANT;
m_xNeedToChangeState := m_xResetRequest;
m_xResetRequest := FALSE;
m_xIsExecutionDone := FALSE;
m_xIsExecutionFail := FALSE;
END_CASE
END_WHILE
ETrigA
Старт по переднему фронту;
Есть возможность прерывания до окончания работы блока;
m_xNeedToChangeState := TRUE;
WHILE m_xNeedToChangeState DO
m_xNeedToChangeState := FALSE;
CASE m_eState OF
BM_DORMANT:
IF xExecute THEN
xBusy := TRUE;
m_eState := BM_EXECUTING;
m_xNeedToChangeState := TRUE;
(* TODO: запомнить состояние остальных входов *)
END_IF
BM_EXECUTING:
(* TODO: m_xIsExecutionDone должно стать TRUE, когда выполнение операции завершено успешно *)
m_xIsExecutionDone := TRUE;
(* TODO: m_xIsExecutionFail должно стать TRUE, когда возникла ошибка выполнения операции *)
m_xIsExecutionFail := FALSE;
IF m_xIsExecutionFail THEN
m_eState := BM_ERROR;
m_xNeedToChangeState := TRUE;
ELSIF m_xIsExecutionDone THEN
m_eState := BM_DONE;
m_xNeedToChangeState := TRUE;
END_IF
IF xAbort THEN
m_xNeedToChangeState := TRUE;
m_eState := BM_ABORTING;
END_IF
BM_DONE:
IF xDone AND (m_xResetRequest OR NOT xExecute) THEN
m_eState := BM_RESETTING;
m_xNeedToChangeState:= TRUE;
ELSE
xBusy := FALSE;
xDone := TRUE;
m_xResetRequest := NOT xExecute;
m_xNeedToChangeState:= FALSE;
END_IF
BM_ERROR:
IF xError AND (m_xResetRequest OR NOT xExecute) THEN
m_eState := BM_RESETTING;
m_xNeedToChangeState:= TRUE;
ELSE
xBusy := FALSE;
xError := TRUE;
m_xResetRequest := NOT xExecute;
m_xNeedToChangeState:= FALSE;
END_IF
BM_RESETTING:
(* TODO: освобождение ресурсов здесь *)
xBusy := FALSE;
xDone := FALSE;
xError := FALSE;
m_eState := BM_DORMANT;
m_xNeedToChangeState := m_xResetRequest;
m_xResetRequest := FALSE;
m_xIsExecutionDone := FALSE;
m_xIsExecutionFail := FALSE;
m_xIsAbortingDone := FALSE;
m_xIsAbortingFail := FALSE;
BM_ABORTING:
(* TODO: m_xIsAbortingDone должно стать TRUE, когда прерывание операции выполнено *)
m_xIsAbortingDone := TRUE;
(* TODO: m_xIsAbortingFail должно стать TRUE, когда возникла ошибка прерывания операции *)
m_xIsAbortingFail := FALSE;
IF m_xIsAbortingFail THEN
m_eState := BM_ERROR;
m_xNeedToChangeState := TRUE;
ELSIF m_xIsAbortingDone THEN
m_eState := BM_ABORTED;
m_xNeedToChangeState:= TRUE;
END_IF
BM_ABORTED:
IF xAborted AND (m_xResetRequest OR (NOT xExecute)) THEN
m_eState := BM_RESETTING;
m_xNeedToChangeState:= TRUE;
ELSE
xBusy := FALSE;
xAborted := TRUE;
m_xResetRequest := NOT xExecute;
m_xNeedToChangeState:= FALSE;
END_IF
END_CASE
END_WHILE
P.S. Не смотря на то, что в теме указано "Модели поведения в CODESYS 2.3". Этот же исходный код будет работать и в CODESYS 3.5.
Заготовка оформления:
Название модели поведения
Краткое описание блока
Исходный код:
Интерфейс ФБ
Код:
Тело ФБ
Код:
Последний раз редактировалось Евгений Кислов; 13.03.2019 в 19:44.
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС
не опасно ли всё через while делать и отдавать на использование неподготовленному пользователю
Так реализовано в стандарте.
Можно реализовать без WHILE, но, в таком случае, выполнение работы ФБ займет как минимум 3 цикла ПЛК (DORMANT -> EXECUTING -> DONE).
Реализация внутри WHILE позволяет (если задача выполнена уже сейчас) сразу по переднему фронту xExecute перейти на DONE.
Я выделил места, в которые нужно внести изменения.
Если неподготовленный пользователь решит менять условия перехода на следующий шаг, а точнее, значение переменной m_xNeedToChangeState, то да, это может привести к "зависанию".
Но здесь даны ссылки на стандарты не зря. Пользователь, изучивший стандарты, уже не будет неподготовленным. Ведь так?
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС
я имел ввиду что неподготовленный пользователь считает документацию для дураков, т.ч. ни кто не будет читать стандарты а захочет сразу применять выложенный код. Я кстати пока не читал документацию, но хотел бы предложить переделать всё это в функцию, а все локальные переменные оформить в UDT структуру и подавать на вход функции через указатель, как мне кажется функция охладит пыл создавать достаточно сложный код
ЗЫ прочитал, в доках используется REPEAT почему используете WHILE
Последний раз редактировалось capzap; 08.07.2018 в 18:39.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
я имел ввиду что неподготовленный пользователь считает документацию для дураков, т.ч. ни кто не будет читать стандарты а захочет сразу применять выложенный код. Я кстати пока не читал документацию, но хотел бы предложить переделать всё это в функцию, а все локальные переменные оформить в UDT структуру и подавать на вход функции через указатель, как мне кажется функция охладит пыл создавать достаточно сложный код
Я не думаю, что неподготовленный пользователь полезет менять то, в чем не понимает.
Для неподготовленных - четко указано, где и что писать.
Подготовленные пользователи, наоборот, могут оптимизировать этот "скелет" так, чтобы он более четко соответствовал решаемой задаче.
В "модели поведения" основная идея в том, что по интерфейсу ФБ можно быстро понять как этот ФБ работает:
работа по уровню, или по переднему фронту;
есть ли возможность прервать работу блока;
есть ли возможность ограничить время цикла блока;
есть ли возможность задать таймаут работы блока;
А решаемую при помощи этого ФБ задачу программист реализует сам, накладывая решение на "скелет".
Обратите внимание на п.3 списка выше.
Есть модель поведения, которая позволяет ограничить время, которое ФБ потратит в 1 цикле ПЛК, после чего отложит выполнение на следующий цикл ПЛК (это модели поведения с буквами TL в названии (например, ETrigTl)).
Т.е. если есть предпосылки для того, что работа ФБ будет сильно увеличивать время цикла ПЛК, нужно будет просто использовать соответствующую модель поведения, и сама модель позаботиться о том, чтобы отложить выполнение при достижении ограничения.
Пользователю лишь останется написать код так, чтобы при следующем вызове выполнение продолжилось с того же места, на котором было прервано в предыдущем цикле.
Я постараюсь выделить время и подготовить пару примеров "из жизни" для того, чтобы ближе познакомить новичков с моделями поведения и их использованием в проектах.
Сообщение от capzap
все локальные переменные оформить в UDT структуру
В данном случае не вижу преимуществ в передаче структуры в функцию и ФБ.
Заменив переменные ФБ на структуру мы обяжем пользователя работать со структурой в его программе (мониторить xDone, xBusy, изменять xExecute), что на CFC совсем не очевидно.
По итогу результат будет тем же, но
Сообщение от capzap
подавать на вход функции через указатель
новичков это отпугнет.
Последний раз редактировалось Осинский Алексей; 08.07.2018 в 18:57.
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС
В "модели поведения" основная идея в том, что по интерфейсу ФБ можно быстро понять как этот ФБ работает:
работа по уровню, или по переднему фронту;
есть ли возможность прервать работу блока;
есть ли возможность ограничить время цикла блока;
есть ли возможность задать таймаут работы блока;
А можно небольшое объяснение?
По пунктам 2,3,4 какое то понимание есть, а вот по 1 пункту... Понятно как это работает, непонятно как применить. В каких случаях следует использовать логику по уровню, а в каких по фронту?
А можно небольшое объяснение?
По пунктам 2,3,4 какое то понимание есть, а вот по 1 пункту... Понятно как это работает, непонятно как применить. В каких случаях следует использовать логику по уровню, а в каких по фронту?
Спасибо.
Сообщение от Осинский Алексей
Не так давно этот документ был переведен на русский язык (доступен по ссылке).
Не смотрели документ по ссылке выше?
Если вкратце, то
ФБ с работой "по уровню" выполняет некую задачу до тех пор, пока на входе xEnable присутствует высокий уровень сигнала (например, утюг, поддерживает температуру до тех пор, пока включен в розетку);
ФБ с работой "по фронту" начинает выполнение некой задачи по переднему фронту сигнала xExecute и до тех пор, пока задача не будет выполнена (например, стиральная машина: программу выбрали, кнопку нажали, закончит стирку - пропищит).
Какая модель Вам поможет для решения конкретной задачи - предстоит определить Вам.
Не смотря на написанное в списке выше я могу себе представить как
нагреватель, работающий по фронту (например, плавный набор температуры и выдержка в течение некоторого времени)
так и
стиральную машину, работающую по уровню (нажали кнопку - стирает, нажали еще раз - прекратила стирать).
Последний раз редактировалось Осинский Алексей; 09.07.2018 в 09:17.
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС
ЗЫ прочитал, в доках используется REPEAT почему используете WHILE
Мы не используем цикл REPEAT т.к. его использование ухудшает читабельность программы:
чтобы понять до каких пор будет выполняться цикл нужно пролистать до конца цикла и только потом станет понятно условие выхода.
Цикл WHILE лишен этого недостатка: условие выхода становится понятным уже на 1й строке.
Последний раз редактировалось Осинский Алексей; 08.07.2018 в 18:55.
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС
Мы не используем цикл REPEAT т.к. его использование ухудшает читабельность программы:
чтобы понять до каких пор будет выполняться цикл нужно пролистать до конца цикла и только потом станет понятно условие выхода.
Цикл WHILE лишен этого недостатка: условие выхода становится понятным уже на 1й строке.
не совсем так, переменную мы найдем в while в начале блока, а в repeat в конце блока, а условие выхода нужно искать в теле обоих циклов и чтоб быть уверенным что оно несколько раз не изменяется, в каждом случае надо пролистывать от начала и до конца блока, между ними лишь одна разница repeat один раз но выполниться
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
не совсем так, переменную мы найдем в while в начале блока, а в repeat в конце блока, а условие выхода нужно искать в теле обоих циклов и чтоб быть уверенным что оно несколько раз не изменяется, в каждом случае надо пролистывать от начала и до конца блока, между ними лишь одна разница repeat один раз но выполниться
Мы не используем (за исключением редких случаев) прерывание цикла при помощи CONTINUE и EXIT т.к. это ухудшает читабельность кода (п. 6.5.2 PLCopen Coding Guidelines):
пробежавшись глазами по телу цикла легко пропустить такой оператор, и сидеть, недоумевая, над программой, в попытках понять, почему этот конкретный участок кода не выполняется.
А спустя какое-то время увидеть, что перед ним стоял оператор EXIT.
В большинстве случаев, тело цикла можно переписать так, чтобы обойтись без этих операторов.
UPD: Из тех же соображений избегаем использования RETURN.
Последний раз редактировалось Осинский Алексей; 08.07.2018 в 19:40.
OSCAT.ru читать стандарты и статьи по автоматизации на русском без регистрации и СМС