Циклы FOR и не только на ПЛК

[Belyash_k]

Добрый день, Коллеги!

Недавно в голове возник вопрос как же все-таки работает цикл FOR в МЭКе и все никак не доходят руки сделать программку, поэтому решил спросить у более опытных Коллег следующее:

1) Принцип работы цикла FOR. Как же все-таки он итерируется: внутри одного цикла и при этом стопорит остальную часть кода внутри вызываемого ФБ или все же итерация происходит каждый цикл контроллера?
2) Насколько целесообразно проводить обработку физики (каналов модулей) через подобный цикл, особенно если система модульная и на шине/корзине очень много модулей? Если цикл FOR итерируется каждый цикл, то может ли возникнуть, в теории, такая ситуация, что пока мы дойдем до условного модуля DI (16-ти канального) под номером 15 и до его канала 16 с циклом, например, 200 мс, нам потребуется 240 циклов (15*16, без учета других модулей и считаем, что модули DI идут первыми по порядку) и того 48 секунд (15*16*200 мс), чтобы только определить сработал канал или нет?
3) Касательно циклов WHILE и REPEAT UNTIL в принципе такой же вопрос: как итерируются они?
4) Да и вообще вопрос в целом насколько целесообразно использовать в циклических задачах циклы FOR? Да и даже если они не циклические, а событийные, не вижу принципиальной разницы.

Вопросы возникли после прочтения книги Петрова про ПЛК, там были освещены как раз циклы и было написано про итеративное выполнение (по крайней мере, я так понял).

[ogorsv]

Добрый день!

1. Цикл FOR итерируется внутри одного цикла и при этом стопорит остальную часть кода внутри вызываемого ФБ
Хотите проверить?
Возьмите, например, несколько больших массивов вещественных чисел и попробуйте в цикле перемножать их. При определённом размере и небольшом времени Watchdog вы получите срабатывание сторожевого таймера.

2.Насколько целесообразно проводить обработку физики (каналов модулей) через подобный цикл - часто в руководствах по программированию приводят время каждой инструкции - можно попробовать посчитать, сколько времени займёт одна итерация и сколько - полный цикл FOR. Если для вашей задачи приемлемо - почему бы и нет?
Другой способ - проверять текущее и максимальное время цикла ПЛК онлайн. Проверили время без вашего цикла, вставили цикл - проверили новые значения. Сделали вывод

3.Касательно циклов WHILE и REPEAT UNTIL в принципе такой же вопрос: как итерируются они - так же, в течение одного цикла ПЛК, выполнится цикл, потом пойдёт выполнение логики дальше

4. Насколько целесообразно использовать в циклических задачах циклы FOR - иногда очень целесообразно, я использую. Всё зависит от контекста)

[keysansa]

3.Касательно циклов WHILE и REPEAT UNTIL в принципе такой же вопрос: как итерируются они - так же, в течение одного цикла ПЛК, выполнится цикл, потом пойдёт выполнение логики дальше

Данные циклы как раз, часто и используются в качестве "асинхронного цикла FOR". Т.е. одна итерация - на один цикл программы:

[+]

WHILE (N < HighArrayIdx) DO
arrTest[N]:= ArrTest[N-1] * ArrTest[N];
END_WHILE

[Jackson]

насколько целесообразно использовать в циклических задачах циклы FOR

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

Лично я не использовал, потому что контроллер и так уже циклически выполняет код и можно просто инкрементировать счётчик на каждом цикле и проверять его значение. Это чуть сложнее и визуально менее очевидно, зато гарантия того что цикл не повесит контроллер. Есть сферы применения, где такая гарантия обязательна. А потом вошло в привычку делать так всегда. Зато я всегда спокоен за время выполнение цикла (оно стабильно) и уверен в том что точно нечему завесить контроллер. Ни For-To ни Do-While.
Только в сенсорных панельках использую - они всего лишь сервисный интерфейс, если сдохнет то для техпроцесса не опасно.

[I_m]

Главное чтобы из цикла был гарантированный выход

Это для всех ПЛК характерно? Даже для софтовых, у которых линукс унутре? Мне просто любопытно начёт многопоточности в ПЛК. Оно там бывает?
Просто я (не в ПЛК, конечно) частенько использую конструкции типа

While True Do
<<тут где-то даю продых>>
End

Я смотрю, тот же Овен, например, пихает MS4D в ПЛК. Да и у других производителей вроде тоже подобное есть. А в SCADA вроде как многопоточность должны быть. Может я и ошибаюсь, конечно.

[Jackson]

Это для всех ПЛК характерно?

ПЛК тут вообще ни при чём. Это должно быть характерно для каждой конкретной реализации и зависит от программиста. Программист же софт создаёт, а не с ПЛК он готовый приходит.

Даже для софтовых, у которых линукс унутре?

А это головная боль программиста и есть.

Мне просто любопытно начёт многопоточности в ПЛК. Оно там бывает?

Бывает и давно уже. Я это в Шнайдере видел ещё в TSX37 который уже давно с производства снят. Мне понравилось как реализовано. Но чаще всего лично сам обходился без многопоточности - в одном цикле всё и работает. ПЛК - не анализатор данных, а программируемый логический контроллер всего лишь. Если на него возлагаются функции анализа большого объёма данных - тут не в ПЛК дело, тут "в консерватории надо что-то поправить" (с). А так - цикл в ПЛК уже организован, один, и вписать в него несколько задач сразу которые будут решаться параллельно - можно, но для этого надо пошурупить головой. А можно и for-to или do-while, просто и напрягаться не надо - фактически, компилятор потом сделает то же самое, но так как нужно компилятору, а не программисту, и тогда ждите задержек исполнения основного цикла на все эти новые циклы. За всё надо платить чем-то. Выбор валюты платежа - только за программистом.

[Looker]

А это головная боль программиста и есть.

В древних AB (PLC-5) уже были команды работы с массивами с выбором: 1 за скан, N - за скан,Все.
Циклы в ПЛК - вред. "Сторожевой пес" укусить не сможет, а начальники...

PS.Программистов от Windows не подпускать к программированию ПЛК - мозги не в ту сторону завернуты.

[keysansa]

Даже для софтовых, у которых линукс унутре?

Программа PLC везде циклическая. От времени цикла зависит, как быстро программа реагирует на события. Часто, от превышения времени цикла защищаются WatchDogом, который при превышении цикла вызовет исключение, которое остановит выполнение программы, выведя соответствующее диагностическое сообщение. На Linux просто процессор, скорее всего, мощнее, поэтому циклы FOR не так заметно влияют на цикл программы. Однако, если это не RTOS - то на цикл программы может влиять другая системная задача, которая "отожмет" процессорное время у PLC.

[leon78]

While True Do
<<тут где-то даю продых>>
End

Если программа в ПЛК выполняется с заданным циклом, то ПЛК и так ничего не делает после завершения задачи пользователя и системных задач, пока не выйдет время цикла.
А такая конструкция в ПЛК вредна.
PS. Циклы FOR в ПЛК использую очень часто. WHILE реже, т.к. есть опасность зацикливания.

[I_m]

А такая конструкция в ПЛК вредна.

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

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

[leon78]

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

Обычно любые задачи можно делать циклическими, и задать для них нужный цикл выполнения. Или в используемых вами ПЛК так нельзя?

[I_m]

Или в используемых вами ПЛК так нельзя?

ПЛК - не моя тема. Я так - сбоку, для общего развития. К тем, с которыми имел дело более-менее плотно, термин "программирование" в классическом смысле мало применим. С моей т.з. Ну, и полезно понимать, как там оно унутре дивайса, с которым ты как с чёрным ящиком общаешься.

[Jackson]

Belyash_k, А вопрос-то в чём? кто-то использует циклы, кто-то не использует.

Да и вообще вопрос в целом насколько целесообразно использовать в циклических задачах циклы FOR?

А в целом по больнице температура в норме, включая крематорий и морг.
Там где целесообразно - используют. Иначе не используют.

Насколько целесообразно проводить обработку физики (каналов модулей) через подобный цикл, особенно если система модульная и на шине/корзине очень много модулей?

Вообще нецелесообразно. Цикл ПЛК весь может быть быстрее чем цикл опроса.

Что у Вас за контроллер такой? Если ПЛК снабжён модулями, то он сам себя опрашивает по необходимости и об этом не надо думать.

Короче, это разговор о сферических конях в вакууме. Конкретнее давайте.

[SBeaRM]

Что у Вас за контроллер такой? Если ПЛК снабжён модулями, то он сам себя опрашивает по необходимости и об этом не надо думать

Некоторые пользователи контроллеров ОВЕН любят реализовывать опрос модулей не стандартными средствами Кодесиса, а через сокеты. Под это дело даже куча тем на их родном форуме создано.

[Valerich]

Что у Вас за контроллер такой? Если ПЛК снабжён модулями, то он сам себя опрашивает по необходимости и об этом не надо думать.

Столкнулся с этой проблемой на Дельте старой линейки DVP: там общение с модулями осуществляется API FROM/TO. При большом количестве модулей стал кусаться WatchDog. Пришлось организовывать поочередный вызов API FROM для каждого модуля.

В свежей серии AS регистры модулей уже отражены в памяти ПЛК и проблем нет.

[Jackson]

В свежей серии AS регистры модулей уже отражены в памяти ПЛК и проблем нет.

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

Ко всем: перестаньте уже путать тёплое с мягким и всё станет понятно.

[Jackson]

Некоторые пользователи контроллеров ОВЕН любят реализовывать опрос модулей не стандартными средствами Кодесиса, а через сокеты.

Интересно, зачем?

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

Сторонние внешние модули - их конечно надо опрашивать ручками, при условии что поддержки этих модулей нет в самом ПЛК на системном уровне - если такая поддержка есть то её стОит просто поискать в документации и задействовать.

А вопрос вообще про циклы прикладного ПО был. :)

В ПЛК я такие циклы не использую совсем, уже объяснил почему. А вот была история не в ПЛК, но в Веинтековской панели, которая опрашивала порядка 28 устройств и приличного объёма, пришлось это делать в цикле. Там я писал скрипты для опроса, которые циклически выполнялись как и в ПЛК. Так вот использование циклов там давало сумасшедшие тормоза. Т.е. полный цикл панели спотыкался на каждом опросе. Сначала была решена проблема таймаута - там есть отдельная команда опроса, при которой послав запрос мы не ждём таймаута, а работаем с теми данными, которые получены за контрольное время, или не получены - если не получены значит и не работаем вовсе. Но и этого оказалось недостаточно. В итоге циклы FOR-TO там были, но не для опроса а для обработки результатов опроса, когда цикл гарантированно конечен и он просто пишет полученные данные из локальных переменных в глобальные - он априори не может зависнуть. Кроме того, для каждого такого скрипта был задан фиксированный интервал исполнения, потому что бессмысленно было опрашивать устройства на каждом цикле панели - при таком количестве устройств полное обновление данных за 2 секунды было более чем достаточным. А сам опрос делался минимально возможным числом запросов без всяких циклов. Просто запрашиваем пачку данных и потом их разбираем и рассовываем по глобальным переменным. Последующая обработка, если она нужна, делалась уже в других местах. Точно также был организован и вывод данных на внешние устройства - отдельным скриптом, который забирал данные из глобальных переменных, формировал слова для отправки и только потом всё пачкой отправлялось в интерфейс. Только тогда, когда софт был сделан именно так, рантайм панели перестал тормозить. А потом я даже взял старую реализацию и посмотрел сколько времени исполняется каждый скрипт - действительно увидел, что исполнение спотыкается об каждый цикл, в котором не закончен опрос.

И, кстати, вот там - в панельке Вейнтека - реализована многопотоковость от производителя, потому что скрипты исполнялись не просто по порядку, а по мере их вызова, соответственно могли исполняться и одновременно несколько. И тем не менее основной рантайм спотыкался о прямой опрос.

Вот список всех опрашиваемых устройств с той панельки. В основном на ModBUS-TCPб но несколько и на ModBUS-RTU. Ничего, не самая мощная панелька вполне успевала, после того как офт был переписан и циклы из опроса убраны.

[Sergy6661]

Некоторые пользователи контроллеров ОВЕН любят реализовывать опрос модулей не стандартными средствами Кодесиса, а через сокеты. Под это дело даже куча тем на их родном форуме создано.

Через сокеты это прям... , любое соединение по TCP/IP происходит ч-з "Сокет",т.е соединение.
А пользователям ПЛК Овен приходится реализовывать опрос модулей ввода-вывода потому как штатный конфигуратор не обеспечивает групповой опрос регистров и для оптимизации обмена лучше писать обмен ручками и для этого библиотеки есть вполне удобные. Плюс обмен контролируется полностью и можно не отвечающее долго устройство выкинуть из обмена, что-бы не тормозило.
А по теме- циклами приходится пользоваться когда необходимо получить результат чего-либо прямо сейчас в текущем цикле, напр. найти Мин., Макс., Мид в массиве, вычислить контрольную сумму и пр.
Те-же функции работы со строками (Find) крутят в себе цикл и увеличивают длит. цикла ПЛК.

[SBeaRM]

Интересно, зачем?

Ну аргументы в основном такие:

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

И вот этого я совсем не понимаю. Что значит выкинуть из опроса модуль ввода/вывода? Это же капец какая аварийная ситуация и надо останавливать работу оборудования, потому что контроллер не видит части датчиков или не может управлять частью устройств.

И тут главное: это модули контроллера или просто произвольные модули в/в, сидящие на интерфейсе.

Проблема ОВЕНа в том, что у них модули контроллера это по сути произвольные модули, связь с которыми возможна только через Modbus. В случае с серией 110 - это RTU, а в случае 210 - TCP/IP. И других вариантов у них нет. Внутреннюю шину они так и не смогли реализовать ни в 110 серии ПЛК ни в 210. Правда техподержка заявляет,что отказ от внутренней шины это их осознанный шаг, аргументируя тем, что это универсально и вообще "стильно, модно, молодежно".

[Barash]

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

Это ложь.

И вот этого я совсем не понимаю. Что значит выкинуть из опроса модуль ввода/вывода? Это же капец какая аварийная ситуация и надо останавливать работу оборудования, потому что контроллер не видит части датчиков или не может управлять частью устройств.

Есть агрегаты, которые при отказе части своих систем, продолжают работать с урезанным функционалом

[SBeaRM]

Это ложь.

Речь о ПЛК, использующих CDS 2.3. Там действительно каждый элемент добавленный в конфигурацию опрашивается отдельно, но при этом групповые запросы всё же поддерживаются, поэтому если вы укажете 4-байтовый элемент или string из 10 слов, то он запросит их одним запросом.

[Jackson]

Проблема ОВЕНа в том, что у них модули контроллера это по сути произвольные модули, связь с которыми возможна только через Modbus. В случае с серией 110 - это RTU, а в случае 210 - TCP/IP. И других вариантов у них нет.

Зато можно использовать другие модули, какие угодно. Гибкость.

Внутреннюю шину они так и не смогли реализовать ни в 110 серии ПЛК ни в 210.

Не "не смогли" а "не захотели". Что там мочь-то? В самом простом случае это CAN, в котором модули постоянно шлют телеграммы, а ЦП просто остаётся их слушать и выставлять таймауты между ними, и иногда слать ответки.
Если переложить этот обмен на пользовательскую программу, то это становится уже проблемой пользователя, значит ось проще, меньше заморочек, процессор похилее поставить можно, CAN не нужен. И о ресурсах уже пусть голова болит у пользователя, а не у них. Отсюда и доступный ценник и продажи. Всё просто.

[keysansa]

Интересно, зачем?

Мое мнение - Овен очень часто меняет оборудование, при этом, таргеты старого оборудования не подтягивает к новой версии Codesys. Получается, что контроллер - на новой версии Codesys, а таргеты для старых модулей ввода/вывода - остаются для старой версии. А так как библиотеки без исходного кода - получается чехарда с разрешением плейсхолдеров (в лучшем случае, когда они есть), иначе подключаются 2 или 3 одинаковых библиотеки с разными версиями.

А если все делается через код - все можно переписать в случае кардинального изменения стандартных библиотек.