"Хороший тон" (ST) или как правильно структурировать проект

Вид для печати

Показывать 40 сообщений этой темы на одной странице

05.03.2015, 19:45
Smith2007

Вложений: 1

"Хороший тон" (ST) или как правильно структурировать проект

В 13 году начал изучение Codesys (по видеолекциям Кирила). Спустя пару недель написал первую программу, которая уже управляла реальным объектом (меняла режимы работы котлов).
С той поры проект обрастал новыми POU, функциями, переменными, модулями ввода-вывода и т.д.
Глядя сейчас на свое творение, меня начинают терзать мысли "а не переписать ли все с нуля, используя накопленный опыт?"

Хотел спросить у уважаемых форумчан, как правильно структурировать проект? Что будет считаться "хорошим тоном" и какие модули выводить в отдельные программы.
05.03.2015, 21:27
Yegor

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

На скриншоте вижу кучу программ. Такой подход мне кажется проблемным — слишком много отправных точек для отслеживания логики (даже если все они вызываются из PLC_PRG, например). Однозначно плохо, если эти программы увязаны между собой через собственные или глобальные переменные. Progressive disclosure на нуле.

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

Самостоятельные ФБ, чистые автоматы, инкапсуляция состояний/поведений и сосредоточенный ввод-вывод — ключи к победе, как по мне, кароч.

В совсем мелких установках (или в средних со множеством однотипных узлов) — тупо максимум логических выражений и минимум ветвлений. От структуризации кода и абстрагирования всего и вся в таких проектах толку мало, зато монтажники рады, когда косяк железной или программной коммутации быстро обнаруживается.
05.03.2015, 22:56
Валенок

Цитата:

Сообщение от Smith2007

как правильно структурировать проект?

Вопрос из серии - как правильно готовить еду.
06.03.2015, 02:17
amn

Цитата:

Вопрос из серии - как правильно готовить еду.

Точно подметили :) Хорошая тема. Рецепты от профессионалов: кто как готовит проекты. Такой информации мало, не то что про еду.

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

Цитата:

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

Егор, а как Вы организуете ввод/вывод, отдельный блок делаете и уже с него на входы функциональным блокам или как-то иначе?
06.03.2015, 05:11
Smith2007

Все pou явызываю по таймеру. Начал беспокоить pou отвечающий за работу с модемом. Иной раз я вижу что мне на тел от пм01 приходит искаженные слова. Может один, а может и три символа искажены.
Кроме того есть сетевые переменные в слейвах, которые в том числе используются как глобальные.
В одном из присланных мне проектов я видел отдельный pou обеспечивающий считывание данных со входов и отдельных для записи выходов.

Для некоторых покажется странной данная тема, но мне не приходилось раньше создавать программы и уж тем более для ПЛК.
06.03.2015, 08:59
Yegor

Цитата:

Егор, а как Вы организуете ввод/вывод, отдельный блок делаете и уже с него на входы функциональным блокам или как-то иначе?

В зависимости от всякой промежуточной фигни (вроде LIN_TRAFO, необходимого для вывода на аналоговые выходы того же ПЛК160) либо в действие основной программы, либо в отдельную программу (приходится).
06.03.2015, 10:13
Smith2007

Если есть несколько программ, которые вызываются по таймеру, какое количество будет предельным?
06.03.2015, 11:25
Yegor

Такое, при котором время срабатывания таймера начнёт коррелировать с количеством вызываемых им программ.
06.03.2015, 16:46
amn

Спасибо, Егор, еще насчет аварий хотел поинтересоваться, как Вы их обрабатываете? Я разбиваю проект на несколько самостоятельных ФБ и аварии у меня разбросаны по всему проекту. То есть в каждом ФБ приходится учитывать все аварийные ситуации. Как-то думал сделать аварии отдельно, но проще мне это не показалось.
06.03.2015, 18:43
Smith2007

Цитата:

Сообщение от amn

Спасибо, Егор, еще насчет аварий хотел поинтересоваться, как Вы их обрабатываете? Я разбиваю проект на несколько самостоятельных ФБ и аварии у меня разбросаны по всему проекту. То есть в каждом ФБ приходится учитывать все аварийные ситуации. Как-то думал сделать аварии отдельно, но проще мне это не показалось.

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

Каждая программа при обнаружении выхода параметра за пределы нормы - выставляет флаг соответствующего события.
Отдельная программа (запускается так же по таймеру) при каждом входе проверяет одну строку глобального массива событий. Если флаг взведен - генерирует различные сигналы (в том числе устанавливает требование отправки СМС)

Код:

TYPE Alarm : STRUCT Alert: BOOL; Level: BYTE; mode: INT; t_idle: TIME; Msg: STRING[255] :=''; Count: INT; fTON: TON; END_STRUCT END_TYPE

Код:

VAR_GLOBAL Control : ARRAY[1..11] OF Alarm := (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#24h, Count :=0 ), (* 01 *) (Alert := FALSE, Level := 16#00, mode :=0, t_idle := T#10m, Count :=0 ), (* 02 *) (Alert := FALSE, Level := 16#00, mode :=0, t_idle := T#10m, Count :=0 ), (* 03 *) (Alert := FALSE, Level := 16#00, mode :=0, t_idle := T#10m, Count :=0 ), (* 04 *) (Alert := FALSE, Level := 16#00, mode :=0, t_idle := T#20m, Count :=0 ), (* 05 *) (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#10m, Count :=0 ), (* 06 *) (Alert := FALSE, Level := 16#00, mode :=0, t_idle := T#10m, Count :=0 ), (* 07 *) (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#10m, Count :=0 ), (* 08 *) (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#30m, Count :=0 ), (* 09 *) (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#30m, Count :=0 ), (* 10 *) (Alert := FALSE, Level := 16#01, mode :=0, t_idle := T#3m, Count :=0 ); (* 11 *)

__________________________________________________ _________________________________

Не так давно, на одном из форумов меня натолкнули на мысль, что набор "уставок" (заданных параметров) можно хранить в отдельном массиве. Например: Ночной режим, Дневной режим, Режим ограниченной охраны, Режим полной охраны и пр. И по команде грузить тот или иной набор уставок. При этом еще можно сделать возможность сохранять произвольное количество наборов по запросу пользователя.
В системах "Умный дом" это называется "снимок".

Показывать 40 сообщений этой темы на одной странице