128 советов начинающему программисту ПЛК

[leon78]

В школе была у меня интересная книжка "128 советов начинающему программисту".
И даже на работе она мне как то помогла - делал по ней перевод времени в другой часовой пояс и в разные единицы в контроллере. Предлагаю сделать похожий сборник советов для ПЛК.
Сразу оговорюсь:
1. Возможно, я нарушаю правила форума - тогда извиняюсь.
2. Все советы носят рекомендательный характер, а так же могут взаимосиключать друг друга. Тем более, если пишут разные люди.
3. Здесь речь идеи именно о ПЛК, программирование контроллеров DCS - отдельная тема, опыт у меня в ней очень небольшой. Коллеги, которые могли бы про это написать, сейчас плотно сидят на объектах. Может есть люди, которые бы завели такую тему для DCS?
4. Я занимюсь в осоновном контроллерами одной фирмы, поэтому возможно какие то советы будут привязаны к этим контроллерам. Прошу вас присоединяться, чтобы не получилось однобокого взгляда на тему.

[leon78]

Если ваш контроллер обрабатывает больше 10 сигналов, если проект будет установлен хотя бы на 2х разных объектах, если вы не хотите запутаться в куче линий - пишите программу на ST

[leon78]

Если программа с какими-то отличиями будет использована хотя бы на 2х объектах - весь похожий код выносите в функциональные блоки. Иначе при исправлени ошибок или модернизации возникает путаница, что менялось в одной программе, а что в другой.

[leon78]

Не увлекайтесь вложением функциональных блоков одного в другой. Это отнимает много памяти и увеличивает цикл сканирования контроллера

[pike]

Если ваш контроллер обрабатывает больше 10 сигналов, если проект будет установлен хотя бы на 2х разных объектах, если вы не хотите запутаться в куче линий - пишите программу на ST

Мягко говоря, спорное утверждение. Журнал Control Engineering частенько проводит опросы кто на каких языках пишет, пока уверенно выигрывает LD. Я, например, то же в линиях не путаюсь.
Все зависит от возможносте среды программирования по структурированию проекта, навыков программиста и (!!!) подготовки тех кто этот проект будет потом обслуживать (электрики в гробу видели ST и IL).

Если программа с какими-то отличиями будет использована хотя бы на 2х объектах - весь похожий код выносите в функциональные блоки. Иначе при исправлени ошибок или модернизации возникает путаница, что менялось в одной программе, а что в другой.

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

[leon78]

Мягко говоря, спорное утверждение...

Вот и напишите это как совет, противоречаший совету 16#0000

[leon78]

Никто не хочет меня поддержать, продолжаю сам. Буду стараться дополнять список советов при наличии времени.

Речь в данном совете пойдет об обмене данными между PLC и HMI по протоколу Modbus во всех его видах или аналогичному.
1. Заранее подготовьте распределение адресов, которые будет читать ЧМИ из ПЛК.
2. Переменные, которые надо читать часто, храните отдельно от переменных, которые надо читать редко. Например, значения аналоговых параметров храните отдельно от настроек аналоговых параметров.
3. Оставляйте резервы. Будет потом очень непросто при ПНР или доработке двигать кучу адресов, если понадобиться добавить несколько сигналов.
4. Расчитывайте на то, что за один запрос ЧМИ должен прочитать как можно больше регистров. При обмене по сети один запрос на много регистров всегда лучше кучи запросов по несколько регистров.
5. Не храните булевские переменные для чтения ЧМИ - храните биты в регистрах. Помните, что 2 булевские переменные занимают целый 16-битный регистр!
6. Если есть флаги состояния или режима работы оборудования, не храните их поотдельности. Пример:
хранить сочетание бит 00 - закрыта, 01 - промежуток, 10 - открыта, 11 - неисправность намного лучше, чем хранить 4 независимых бита на каждое состояние.
7. Если в системе есть какие-то небольшие ЧМИ, требующие чтения небольшого количества данных, делайте для них в одном месте дублирование этих данных. Лучше эти ЧМИ прочитают необходимые данные одним запросом, чем будут делать кучу запросов по всему адресному пространству.

[Jackson]

Полезная ветка однако.

А вот то же самое бы еще в стихах - вообще бы было прекрасно :) :)

[leon78]

А вот то же самое бы еще в стихах - вообще бы было прекрасно :) :)

Зря вы смеетесь. Человеку с опытом многие вещи кажутся прописными, но начинающий много шишек набьет, чтобы до них дойти.

Вот книга, про которую я говорил в начале:
http://www.infanata.org/2007/12/12/ochk ... .-128.html

[Jackson]

Зря вы смеетесь. Человеку с опытом многие вещи кажутся прописными, но начинающий много шишек набьет, чтобы до них дойти.

Да я не смеюсь - просто настроение хорошее. :)

Если, закачав программу, получаешь STOP ERROR,
Не спеши копаться в коде - код, возможно, ни при чём.
Лучше глянь на сам контроллер (и в его же мануал),
Всё ль со схемами в порядке? Ничего не коротит?
Есть такие PLC-шки, очень умные они -
Каждый модуль видит чётко, что подключено к нему.
Если где-то нет питанья или выход подгорел,
То не будет код работать, как его ты ни крути!

[leon78]

Если, закачав программу, получаешь STOP ERROR...

Надо переобозвать это в совет 16#0004 :)

[leon78]

В DCS системах есть механизм передачи сообщений (алармов). В ПЛК этот механизм надо делать самим.
Для чего это надо? Ведь можно привязать сообщения к каким-то битам, состоянию дискретных параметров и т.п.
Приведу пример. У вас цикл сканирования ПЛК 50мс. ЧМИ может читать данные раз в 1 с. Получается, что ЧМИ "не видит" 19 изменений параметров из 20. Так же некоторые события являются не прямым следствием изменения параметров, а привязаны к выполнению алгоритма.
Ниже предлагаю один из вариантов реализации, требующий от SCADA ЧМИ наличия развитого программного языка. К сожалению, не все SCADA его имеют.
1. Договариваемся, что любое сообщение может иметь код от 0 до 65535, кажому коду соответствует некий текст. Как удобно сделать систему кодировки, постараюсь написать отдельно. Дополнительно можно договориться, чтобы каждому сообщению кроме текста соответсвовал определенный цвет и звуковой сигнал.
2. Выделяем в регистрах ПЛК, читаемых ЧМИ, буфер. Например на 500 регистров. И плюс один регистр - указатель буфера.
3. Делаем в ПЛК функциональный блок, который делает следующее:
- получает код сообщения для записи в буфер;
- записывает в элемент буфера, на который указывает указатель, код сообщения;
- увеличивает указатель на 1. Если указатель > 499, то указатель = 0.
4. Программа ЧМИ должна следить за указателем и хранить у себя ее копию. Если указатель и копия отличаются, то ЧМИ должен вычитать все непрочитанные коды из буфера, вывести на экран и добавить в архив.

[pike]

В современных программируемых терминалах и SCADA тоже существует нормальный инструмент для работы с авариями/событиями (Alarm&Event List/Alarm&Event History). Очень удобно и со временем, и с датой, и с буффером громадненьким.
Аварии не должны "мигать", если зафиксирована авария поднимаем соотвествующий флаг и ни кого не должно волновать, что она исчезла. Сброс этого флага только с учетом кучи условий и в том числе с подтверждением от оператора.

[leon78]

В современных программируемых терминалах и SCADA тоже существует нормальный инструмент для работы с авариями/событиями (Alarm&Event List/Alarm&Event History). Очень удобно и со временем, и с датой, и с буффером громадненьким.
Аварии не должны "мигать", если зафиксирована авария поднимаем соотвествующий флаг и ни кого не должно волновать, что она исчезла. Сброс этого флага только с учетом кучи условий и в том числе с подтверждением от оператора.

Ну на все сигналы и события флагов не наделаешь. В предложенном механизме сообщений можно завести специальный код - "метка времени". Тогда к сообщениям дата и время события (т.е. контроллера) будут привязаны, а не время, когда SCADA их прочитала.

[pike]

Ну на все сигналы и события флагов не наделаешь.

??? Это как? Есть авария, но нет сигнала который отключает это, и включает то? Жуть.

В предложенном механизме сообщений можно завести специальный код - "метка времени". Тогда к сообщениям дата и время события (т.е. контроллера) будут привязаны, а не время, когда SCADA их прочитала.

Принципиальна ли разница в регистрации данных в 1 сек (а это единственный раз такое было в моей практике, да и то из-за ошибок в выборе комплектующих)? На практике, выбор оборудования всегда осуществляется так что бы цикл обмена между плк чми всегда был заведомо (и существенне) меньше 1 сек. Делается это не столько из-за регистрации данных, сколько из учета удобства работы оператора, которых ни что так не бесит, как "тормоза" чми. Так что всегда, на серийниках скорость 115000 или Ethernet + оптимизированные, для работы с данным оборудованием, протоколы связи.
Вот если есть действительная необходимость вести не зависимые от чми логи, то тогда надо использовать возможности плк. Правда в этих случаях дополнительно логи требуется хранить на какой нибудь CompactFlash.

[leon78]

??? Это как? Есть авария, но нет сигнала который отключает это, и включает то? Жуть.

Я к тому, что в системе может быть 2 тыс сигналов, и только 100 из них - аварийные. На аварии согласен, надо делать флаги. Но на все остальные сигналы зачем? И без буфера событий будет потерян порядок возникновения события. Например, срабатывает защита, выключается система. Если делать сообщения по флагам, то может вполне быть зафиксирована в начале выключение системы, а потом срабатывание защиты. Теряется причинно-следственная связь!

[pike]

Я к тому, что в системе может быть 2 тыс сигналов, и только 100 из них - аварийные.

Интересные у вас системы. У меня на 50 диск. вх/вых + 1 анал. вход. почти 100 аварий. Дальше маштабируем.

На аварии согласен, надо делать флаги. Но на все остальные сигналы зачем? И без буфера событий будет потерян порядок возникновения события. Например, срабатывает защита, выключается система. Если делать сообщения по флагам, то может вполне быть зафиксирована в начале выключение системы, а потом срабатывание защиты. Теряется причинно-следственная связь!

Это как такое может получиться, если учесть что плк работает по циклу и обмен с чми циклический (или с обменом химичим в плане "оптимизации")? В худшем случае они могут получить одно и тоже время возникновения. Дальше возвращаемся к скорости обмена данными плк<->чми.

[leon78]

Интересные у вас системы. У меня на 50 диск. вх/вых + 1 анал. вход. почти 100 аварий. Дальше маштабируем.

Ну у всех свои недостатки.

На аварии согласен, надо делать флаги. Но на все остальные сигналы зачем? И без буфера событий будет потерян порядок возникновения события. Например, срабатывает защита, выключается система. Если делать сообщения по флагам, то может вполне быть зафиксирована в начале выключение системы, а потом срабатывание защиты. Теряется причинно-следственная связь!

Это как такое может получиться, если учесть что плк работает по циклу и обмен с чми циклический (или с обменом химичим в плане "оптимизации")? В худшем случае они могут получить одно и тоже время возникновения. Дальше возвращаемся к скорости обмена данными плк<->чми.

Допустим, завели вы для флагов аварий и прочих сообщений кучу битов. Например, у нас есть системы с 20тыс. разных сообщений. Если хранить их в 16тибитных регистрах, это уже получается 1250 регистров. Для чтения по Modbus TCP уже потребуется как минимум сделать 10 запросов. Если вы применяете чисто механизм SCADA, нет никакой гарантии что первые по порядку регистры после завершения скана ПЛК читаются раньше чем последние. А даже если это и так, то со 100% вероятностью будут ситуации, когда за 1 скан возникает несколько событий, для которых бит сообщения "о причине" будет лежать позже чем бит сообщения "о следствии". Т.е. за 1 скан вы получите кашу из сообщений, а в какой последовательности они произошли (вернее с какой последовательностью сгенерил их ваш алгоритм) вы никогда не узнаете.
Приведу по памяти сообщения, которые может выдать система за 1 скан:
Температура подшипника максимальная аварийная.
Агрегат остановить автоматически.
Задвижку закрыть автоматически.
Если не заморачиваться с последовательностью, может получиться каша:
Задвижку закрыть автоматически.
Агрегат остановить автоматически.
Температура подшипника максимальная аварийная.
тут всего 3 сообщения, а их за скан может быть и 100!

[pike]

В случае с тремя сообщениями:
Температура подшипника максимальная аварийная - однозначная авария, для удобства оператора выделяется, условно красным цветом, кодом А124...
Агрегат остановить автоматически - класс событий аварией не являющийся, но может являться ее следствием, выделяем желтым цветом, заносим в соответствующую группу с кодом.
Задвижку закрыть автоматически - банальное действие...
В общем в каком порядке не ставь, авария видна и если оператор знаком с тем как все работает в принципе все понятно.

Если вы применяете чисто механизм SCADA, нет никакой гарантии что первые по порядку регистры после завершения скана ПЛК читаются раньше чем последние.

Еще раз - если плк работает циклически (самодиагностика, программа, сети, вх/вых), если опрос идет циклически (каждые 300мс по 2000 тегов, например, на винде), то как получается, что данные поступают как попало?

[leon78]

После "небольшого" перерыва продолжаю.

1. ST выполняется быстрее FBD. Если не предусматривать специальных мер, постоянно выполняются все блоки FBD, даже если по алгоритму в данный момент времени они не нужны. В ST выполняются только те части программы, которые должны выполниться по алгоритму.
2. Память данных для ST меньше, чем для FBD. Дело в том, что в ST один экземпляр функционального блока можно вызвать сколько угодно раз. В FBD для каждого вызова надо делать свой экземпляр.
3. В FBD нельзя сделать нормальные циклы.
4. В ST намного легче реализовать многие вещи, чем в FBD.
5. Сталкиваясь с DCS, многим не хватает именно текстовых языков программирования. Если бы в DCS были только текстовые языки, думаю никто бы не переживал.

[Михайло]

Я программирую в LD и не парюсь. Если у Вас тормозит ПЛК, то поменяйте на более быстрый, нечего изобретательством заниматься!

Второй язык, который я знаю - IL, он самый быстрый, мощный и компактный. IL - это по сути ассемблер, язык самого низкого уровня. FBD и LD чуть-чуть менее компактные, но практически незаметно. Не понимаю, с какого вдруг перепугу язык высокого уровня ST стал самым быстрым и компактным?

[leon78]

Второй язык, который я знаю - IL, он самый быстрый, мощный и компактный. IL - это по сути ассемблер, язык самого низкого уровня. FBD и LD чуть-чуть менее компактные, но практически незаметно. Не понимаю, с какого вдруг перепугу язык высокого уровня ST стал самым быстрым и компактным?

Согласен что IL самый быстрый, но он сложнее, чем ST, в разработке и дальнейшем понимании кода.

[leon78]

А на ASMе писать не пробовали? Он еще быстрее :) И еще более сложнее в понимании и в скорости разработки. Ваш Заказчик будет просто счастлив от подобных реализаций, ага ;)

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

[pike]

1. ST выполняется быстрее FBD. Если не предусматривать специальных мер, постоянно выполняются все блоки FBD, даже если по алгоритму в данный момент времени они не нужны. В ST выполняются только те части программы, которые должны выполниться по алгоритму.
2. Память данных для ST меньше, чем для FBD. Дело в том, что в ST один экземпляр функционального блока можно вызвать сколько угодно раз. В FBD для каждого вызова надо делать свой экземпляр.

То что вы описываете это особенности "железки" конкретного производителя (а иногда даже и серии контроллера),без указания которого ваши советы "тень на плетень". Я например знаю несколько разных контроллеров в которых программа на ST занимает больше места, чем на LD, а использование FB одинакого влияет на объем программы. Ну, и про быстродействие тут тоже много чего интересного бывает, но в привязке к конкретной железке.

3. В FBD нельзя сделать нормальные циклы.

Задачи в плк и так циклические.

4. В ST намного легче реализовать многие вещи, чем в FBD.

А какие-то в FBD (или мы CFC говорим?)... Старый спор какой из 5 языков лучше, стал сродни спору кто лучше: блондинки, шатенки или рыжие.

[Михайло]

Просто leon оказался очередным программистом и не представляет простоту языка LD. Я знаю много языков, в том числе объектно-ориентированные, но в дискретно-логических задачах лучше LD ничего нет! :) LD формирует особое мышление, которое облегчает программирование.