Организация программы для ПЛК (переход с AVR на ПЛК)

[morcat]

Многозадачность отъедает ресурсы ПЛК.

Другое дело. Понятно почему так не принято делать.

Надо менять психологию

Вот над этим и бьюсь

получение температур 1 раз в секунду, сканирование датчиков 100 раз в секунду, вычисление регуляторов 1 раз в секунду

Всё это сделано для разгрузки микроконтроллера, чтобы не одновременно выполнять поставленные задачи поскольку ресурсов маловато.

Значит PLC-PRG по сути это последовательный набор действий - так называемый "прогон", связывающий входы с выходами, выполняемый с определённой цикличностью (CycleLenght ms).

[Николаев Андрей]

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

[morcat]

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

Понял. Зато могу задать аппаратную (а не программную как делал с AVR) фильтрацию входных дискретных сигналов: Time of filtration in ms. Могу задать масштабирование аналоговых сигналов: Параметры канала. Очень по-моему удобно.

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

Cycle.jpg

Начинаю потихоньку менять психологию

[swerder]

если убрать штриховые стрелки, то будет похоже

[drvlas]

Начинаю потихоньку менять психологию

Приветствую тебя, мой далекий коллега! Я оттуда же пришел к ПЛК, совесм недавно. Интересно теперь наблюдать, как это происходит

Особо психологию тут и не надо менять, если ты программировал на МК задачи реального времени. Одна из ошибок, которую я делал - переоценивал отличия. На самом деле, если взять грамотно написанную программу той же АВР-ки, в которой есть пофазное исполнение программы - то отличия только в наличии здесь ОС, обслуживающей входы-выходы.

Смотрим на страшилки, которыми автоматчики путают, и немного приглаживаем их. Здесь я умышленно придерживаюсь нестрогого изложения, да простят меня взрослые зубастые ПЛК-шники. Важно, чтобы родная душа меня поняла и двинулась вперед быстрее и проще. А там и сам поймешь, какую чушь я иногда говорю для понятности.
Итак,

1) Петля
Ну что тут особенного? Нужно знать, что ОС ПЛК уже организовала бесконечный цикл. Все, что ты делаешь обычно до своего цикла (а он всегда есть!), свои всякие init() - запихни в условную петлю, для которой теперь ТЫ САМ организуешь ОДНОКРАТНОЕ исполнение. И все. Больше об этой страшной петле не говорим.

2) Остановки
Да, нужно забыть о примочке типа стою, курю, жду повторения программного цикла стопитцот раз. Или жду, пока датчки не покажет событие. Так ты меня прости - об этом пора было забыть давным давно, если ты МК управлял реальной задачей с событиями. Там все равно создавалось либо пофазное прохождение, либо вообще ОСРВ в том или ином виде.
Здесь обслуживание событий в режиме "поставил слежение за флажком и полетел дальше" - the must

3) Возвраты
Вот уж не понимаю, что тут такого. Да можно вернуться куда ХОШЬ! Тот же цикл, например - это многочисленные возвраты. С учетом п.п. 1 и 2 о страшилке 3 можно вообще не думать

4) Конфигуратор ПЛК
Вот это нужно учитывать - но ты, вижу, уже в курсах. Для меня было проблемой просто понять, что вот так вот ручками поназывал переменные (илди просто создал табличку для себя) - и тепереь юзаешь эту область, не думая, как она там опрашивается.
ДОБАВИЛ: даже не так. С пользовательской точки зрения как раз все просто: обращайся себе к переменным из области ввода-вывода, НЕ ДУМАЯ ОБ ИХ ОСОБОМ СТАТУСЕ. Просто переменные. Я вот как раз придавал им некую исключительность, даже создавал копию в "обычном ОЗУ". Не нужно этого делать.
Единственное, что надо понять момент их использования исполняющей системой для ввода-вывода. Этот момент - за пределами твоей програмульки. Раз вся прога включена в цикл, то все, что наваял, будет проходиться за цикл контроллера (не факт, что исполняться, естественно, ведь есть же условные операторы, переключатели и прочее), а в это время входы-выходы НЕ ИЗМЕНЯЮТСЯ. Вот когда дойдешь до конца (а ОС сама перекинет в начало) - в этот таинственный момент выходы установятся, а входы опросятся.
Всего-то и делов.

А про SFC - это бомба! Попиши пока на ST, но потом обязательно вернись к нему.
И, конечно, коллеги правы. Поиграйся с простыми примерами. День-два, неделю-две - это уж как получится. Но без этого никак. Иначе скоро тебя начнут пинать ногами за вопросы, которые не возникают у прилежного ученика.
Вспомнл еще одну проблему. Отнесись флегматично к качеству документации и некоторым кострубастостям КоДеСис. Это нужно принять

Успехов!

[morcat]

Приветствую тебя, мой далекий коллега...

Спасибо за понимание, коллега!

Смотрим на страшилки...

Хорошо излагаете, коллега!

Итак, поступаю следующим образом:

1) Рисую на бумаге слева входы системы
_______датчики температуры - аналоговые входы;
_______пож.датчик, термостаты, переключатели, кнопки и т.д.- дискр.входы.

справа рисую выходы:
_______вкл/выкл приточного вентилятора;
_______вкл/выкл вытяжного вентилятора;
_______управление приводом подогрева воздуха;
_______управление приводом охлаждения воздуха и т.д.

2) Затем беру ручку и для каждого выхода пишу условия его работы (например для вентилятора):
Вентилятор должен включаться когда:
_______нет пожарной опасности;
_______нет опасности замерзания водяного калорифера в режиме "зима";
_______нет сработки датчика термозащиты вентилятора;
_______переключатель "вкл/выкл" находится в положении "вкл" и т.д.

3) Далее соединяю на листе входы и выходы с учётом п.2 с помощью стандартных библиотечных блоков.

Таким образом получаю именно структурную схему системы - это и есть программа ПЛК. В данном случае язык СFC получается.

Конечно, алгоритм весьма упрощён, и ещё необходимо приложить усилия чтобы "причесать" программу (отдельные блоки сделать макросами или подпрограммами), но наглядность по-моему очевидна.

[drvlas]

Итак, поступаю следующим образом:
...
получаю именно структурную схему системы - это и есть программа ПЛК. В данном случае язык СFC получается.

Ну, я CFC не юзал, пусть настоящие спецы подскажут. Да, если реализуется просто логическая схема связи входов с выходами - такого рода представление будет удобно. Мне лично мало такое приходилось программировать, привык в задачам, "раскручивающимся во времени" - а тут уж SFC, мммммммм! лапочка.

Но все же, некоторые простые элементы есть смысл пробовать до того, как переходишь к предметной задаче. Или по ходу создавать левые проекты-примерчики. Я, например, со всяким таймерами и триггерами, со временнЫми пеерменными - постоянно создаю и проверяю. Тут есть камешки под водой (возьми, для примера, дурацкое называние триггером одновибратора - это ж в голову плохо лезет).

[morcat]

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

Полностью согласен. У меня в IAR проектик есть под названием "Debug" в котором все непонятки и решаю. Также и тут поступать буду.

такого рода представление будет удобно

Я на электроприводе учился так что структурные схемы самое то

[Валерий Бурик]

Хочу тоже дать дельный совет. Так как и Вы я тоже пришел с МК51, а потом с AVR. Меня теперь и палкой не загонишь назад в микроконтроллеры! Совет такой, используйте визуализацию. Работу, в моем случае механизма, разбиваю на шаги в SFC. Переход на следующий шаг по условию с датчиков. В квадратиках пишу на ST. Таймеры, счетчики описываю в FB, там нагляднее видно. И самое главное параллельно рисую в визуализации. Накидал квадратиков - датчиков, описал их в конфигурации ПЛК, присвоил им конкретные адреса входов контроллера. Нарисовал кружочек- двигатель, присвоил выход контроллера. FALSE один цвет, TRUE другой (тревожный). Написал действие с входом и выходом. Запустил программу, если не ругается на ошибку, нажал курсором мышки на датчик и смотрю реакцию на двигатель, ага, получилось, иду дальше. Забыл сказать, сначала нужно нарисовать конкретную схему вашего устройства, где входа и выхода контроллера привяжете к реальным сигналам датчиков и исполнительным механизмам.
И как все повторюсь, начните с примеров. Начните с примера "Светофора" что в CodeSys, наберите его вручную. Здесь никак изучение не объедешь.
С уважением и успехов.

[Николаев Андрей]

Приветствую тебя, мой далекий коллега! Я оттуда же пришел к ПЛК, совесм недавно. Интересно теперь наблюдать, как это происходит

Особо психологию тут и не надо менять, если ты программировал на МК задачи реального времени. Одна из ошибок, которую я делал - переоценивал отличия. На самом деле, если взять грамотно написанную программу той же АВР-ки, в которой есть пофазное исполнение программы - то отличия только в наличии здесь ОС, обслуживающей входы-выходы.

Смотрим на страшилки, которыми автоматчики путают, и немного приглаживаем их. Здесь я умышленно придерживаюсь нестрогого изложения, да простят меня взрослые зубастые ПЛК-шники. Важно, чтобы родная душа меня поняла и двинулась вперед быстрее и проще. А там и сам поймешь, какую чушь я иногда говорю для понятности.
Итак,

1) Петля
Ну что тут особенного? Нужно знать, что ОС ПЛК уже организовала бесконечный цикл. Все, что ты делаешь обычно до своего цикла (а он всегда есть!), свои всякие init() - запихни в условную петлю, для которой теперь ТЫ САМ организуешь ОДНОКРАТНОЕ исполнение. И все. Больше об этой страшной петле не говорим.

2) Остановки
Да, нужно забыть о примочке типа стою, курю, жду повторения программного цикла стопитцот раз. Или жду, пока датчки не покажет событие. Так ты меня прости - об этом пора было забыть давным давно, если ты МК управлял реальной задачей с событиями. Там все равно создавалось либо пофазное прохождение, либо вообще ОСРВ в том или ином виде.
Здесь обслуживание событий в режиме "поставил слежение за флажком и полетел дальше" - the must

3) Возвраты
Вот уж не понимаю, что тут такого. Да можно вернуться куда ХОШЬ! Тот же цикл, например - это многочисленные возвраты. С учетом п.п. 1 и 2 о страшилке 3 можно вообще не думать

4) Конфигуратор ПЛК
Вот это нужно учитывать - но ты, вижу, уже в курсах. Для меня было проблемой просто понять, что вот так вот ручками поназывал переменные (илди просто создал табличку для себя) - и тепереь юзаешь эту область, не думая, как она там опрашивается.
ДОБАВИЛ: даже не так. С пользовательской точки зрения как раз все просто: обращайся себе к переменным из области ввода-вывода, НЕ ДУМАЯ ОБ ИХ ОСОБОМ СТАТУСЕ. Просто переменные. Я вот как раз придавал им некую исключительность, даже создавал копию в "обычном ОЗУ". Не нужно этого делать.
Единственное, что надо понять момент их использования исполняющей системой для ввода-вывода. Этот момент - за пределами твоей програмульки. Раз вся прога включена в цикл, то все, что наваял, будет проходиться за цикл контроллера (не факт, что исполняться, естественно, ведь есть же условные операторы, переключатели и прочее), а в это время входы-выходы НЕ ИЗМЕНЯЮТСЯ. Вот когда дойдешь до конца (а ОС сама перекинет в начало) - в этот таинственный момент выходы установятся, а входы опросятся.
Всего-то и делов.

А про SFC - это бомба! Попиши пока на ST, но потом обязательно вернись к нему.
И, конечно, коллеги правы. Поиграйся с простыми примерами. День-два, неделю-две - это уж как получится. Но без этого никак. Иначе скоро тебя начнут пинать ногами за вопросы, которые не возникают у прилежного ученика.
Вспомнл еще одну проблему. Отнесись флегматично к качеству документации и некоторым кострубастостям КоДеСис. Это нужно принять

Успехов!

Вот ей богу порадовали.
Респект