Это всё азы, когда начинал, тоже писал b=true, потом подсказали и стал писать просто b или NOT b.Сообщение от EVGEN_
IF это проверка на истинность, он и проверяет, что b=true, (если NOT b проверка, что b=false) поэтому писать b=true это излишне и писать меньше.
IF можно использовать где угодно, в CASE и вне его.
А вот таймеры надо вызывать только вне IF, а в нём только присваивать входы или время.
Последний раз редактировалось kondor3000; 04.03.2024 в 20:01.
Только на ST не делал - только в связке SFC+ST.
При помощи SFC разделял задачу на процессы:
- инициализация переменных при включении питания
- обработка аналоговых входов (масштабирование, сглаживание)
- работа с панелью оператора (формирование команд, смена режимов, формирование слов состояний для визуализации и прочее)
- валидация параметров, введённых с панели или другого источника
- обработка кнопок и переключателей на щите (формирование команд, смена режимов)
- последовательность пуска управляемого агрегата (барабанный командоаппарат на ST при помощи CASE)
- регуляторы
- сигнализация (включение постоянного, прерывистого звукового сигнала, отключение звуковой сигнализации)
- защита - проверка выхода параметров процесса за допустимые диапазоны в зависимости от текущего состояния управляемого агрегата - формируются сигналы вхождения в предупредительный диапазон, выхода за допустимый и начало отсчёта задержки, завершение отсчёта задержки и аварийного останова агрегата
Сейчас бы ещё учитывал совет о именованных константах для номеров состояний агрегата. А тогда просто нумеровал их с шагом 10, чтобы можно было вставить шаги без изменения нумерации.
Рабочие программы привести не могу, а тестовый пример работы с файлами в ПЛК110[М2] запросто.
Программа в ПЛК содержит переменные, вводимые с панели оператора и буфер обмена с файлами, содержащий все эти переменные.
По команде "записать в файл", переменные копируются в буфер и содержимое буфера сохраняется в файле.
По команде "прочитать из файла", содержимое файла копируются в буфер, но переменные остаются неизменными.
По команде "установить в буфере настройки по умолчанию", в буфер записываются значения "по умолчанию", но переменные остаются неизменными.
По команде "скопировать настройки из промежуточного буфера", содержимое буфера копируется в переменные.
Таким образом, появляется возможность ознакомления с сохранёнными ранее настройками и сравнения их с актуальными.
Добавлю, что к такой структуре программ в CoDeSys пришёл самостоятельно, до этого работал в другой среде разработки и программа была на LD без возможности структурирования единой "простынёй" в ~500-1000 строк.
Сейчас перешёл на другую работу, и для программирования в CODESYS 3.5 во всех наших уроках рекомендуется другой подход к структуре программы - создаются задачи и они вызываются не из основной программы, а каждая отдельно с заданным интервалом через штатный планировщик.
Не могу сказать, какой подход лучше - не встречал анализа.
Последний раз редактировалось FPavel; 03.03.2024 в 21:00.
Вот ещё пример программы SFC+ST+FBD
Задача была - автоматизация работы бака-накопителя ГВС. Автоматическое или ручное управление одним насосом и несколькими задвижками, поддержание уровня в баке при помощи поплавкового датчика уровня с 4 дискретными сигналами.
Была экономия на физических кнопках (а значит и модулях ввода), поэтому с панели оператора были "кнопки" пуск/стоп процесса, сброс и проверка сигнализации, ручные и автоматические режимы насоса и задвижек.
Но структура программы осталась по моему выдуманному принципу
Сначала хотел при включении питания всё закрывать и выключать, но потом отказался от этой идеи, поэтому стадия Init пустая.
А зачем вам здесь SFC вообще?
Можно было накатать всё в одну простыню ST и всё, или сделать несколько программ (сколько там квадратиков, не считал) и запихать их в одну задачу на выполнение.
На форуме нет примеров структурированных программ, все - на едином листе. Спросить совета было не у кого. А самообразование приводит к причудливым решениям )
Исходя из предыдущего опыта не желал получать "простыню", а средствами CoDeSys (SFC) можно было упорядочить код, упростить навигацию по нему.
Работу с периодическими задачами сразу не освоил, а потом за 10 лет было всего четыре проекта в CoDeSys, которые нужно делать срочно - тут не до изысканий новых подходов, когда предыдущая структура устраивает.
По правде, за всё время у меня не возникало желания менять структуру, которую придумал с самого первого проекта. Не видел недостатков, одни достоинства в простой навигации (в дереве объектов подпрограммы, в SFC процессы), в возможности выбирать язык для каждой задачи, простая реализация инициализации при включении питания.
К слову, в OwenLogic уже несколько раз менял стиль и пока не могу определиться "со своим".
Ну, будет время, посмотрите при использование задач и отдельных программ - это более гибкое решение
Спасибо за программы! Я топлю за ST, так как иногда приходится по мелочи залазить в программы контроллеров на работе и к примеру, что-нибудь откалибровать. Так вот, в какую установку не залезем, везде вся программа написана именно на ST. Будь то, контроллер SIEMENS или Allen Bradley.
Сейчас, после обучения работе в CDS 3.5, хоть понимаю о чём речь. При возможности попробую.
На днях закончил свою первую программу на языке ST в среде Codesys v2.3. Не стал я использовать в программе другие языки, так как хотел изначально, чтобы она у меня была полностью только на ST. Как использовать в моей программе всего 2-3 таймера, я не разобрался, но в итоге мне так получилось нагляднее и проще. Хотелось бы еще поделить на отдельные блоки для лучшего понимания и читабельности программы. Комментарии опустил, в принципе как я обзывал переменные возвращаясь к программе спустя даже неделю, мне не много времени уходило, чтобы вспомнить и разобраться, что и куда.
Еще по поводу ST услышал авторитетное мнение, что он по сути не такой уж и перспективный. Как бы раньше программы на ПЛК писали в основном программисты и им естественно был роднее и ближе ST. Но с развитием ПЛК и появлением других языков, более перспективным может быть тот же FBD, так как на нем можно реализовать так же большинство программ, при чем более наглядных. К тому же вход в него(обучение, освоение) ниже, чем у того же ST, что позволяет большему количеству инженеров писать свои программы для ПЛК.
Интересно, что думают форумчане о написанной программе и перспективах FBD над ST.
https://disk.yandex.ru/d/utKkfkFrt83Bcw
По поводу ST не слушайте никого, вы даже и половины языка не освоили. Когда перейдёте к указателям и структурам, поймёте, что остальные языки полная лажа. Хотя сам использую немного CFC ( или FBD в Лоджике), для наглядности работы программы, на основном листе. Остальное на ST.
По поводу проекта, сделали и хорошо, проекта нет, поэтому и обсуждать нечего. Единственное, не разбили программу на ФБ, как писал.
Как по мне, чем думать над покупкой ненужного китайского частотника, лучше бы занялись работой с ФБ, обменом через биб-ки и далее к массивам, указателям и структурам.
Последний раз редактировалось kondor3000; 07.04.2024 в 13:09.
Ваши права
Ответить с цитированием