Программирование ПЛК прошу совета

[chegevara]

Здравствуйте.Скоро ну где-то через полтора года по программе будет программирование ПЛК и я хотел бы у аудитории данного форума попросить совета.Хочу спросить с чего следует начать изучать этот вопрос?Какие самые общие советы вы могли бы дать по этому поводу новичку?Какую литература новичку вы посоветуете?Какая литература новичку просто необходима?Ну и прочие напутствия приветствуются.Хочу быть подготовленным к данному курсу,и прошу у вас совета.Спасибо.

[Jackson]

Раз уж я вижу у Вас такую тягу к предмету, что меня лично очень радует, то советую раздобыть возможность работать с реальным железом. Подумать и может купить что-то простенькое, попробоать разные варианты. Например, у меня есть одна задачка к которой я никак не могу приступить в силу разных причин, можно попробовать её реализовать. Правда я для неё планировал что-то вроде ардуино, а это всё-таки не совсем ПЛК - на классическом ПЛК задачку тоже можно решить, но это будет аппаратно дороже. Думайте.

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

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

Я как-то постил тут материалы очень краткого курса логического управления тех.процессом. Могу освежить и разъяснить это с точки зрения трёх основных диалектических законов. Кстати, помните их?

Отправлено спустя 26 минут 20 секунд:
И, кстати, я бы не гнушался и релейными схемами управления - то же логическое. Соответственно литература по синтезу релейных схем управления. Позже могу засесть и попробовать поискать.

[Никита]

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

Есть непроверенная информация о существовании рантайма codesys под raspberry pi. Точнее, информация о существовании проверенная, не проверено как работает и что поддерживается. Может и будет выходом - "и охота, и никаких зверей убивать не нужно" (из м/ф про Простоквашино). Тот же кодесис с мэковскими языками, а убитых зверей уйдет меньше в разы.

[Jackson]

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

Отправлено спустя 1 минуту 27 секунд:

Тот же кодесис с мэковскими языками, а убитых зверей уйдет меньше в разы.

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

[megavolt86]

общие советы вы могли бы дать по этому поводу новичку?

Не ссать! Ничего сложного нет))))
С делфи вы же знакомы, логические операторы они везде одинаковы, транскрипция только отличается...
Главное по мне это владение навыками работы с нужными операторами.
И еще одно не надо тратиться на железо, тот же кодесис от овна бесплатен и позволяет работать в симуляторе, принципы построения конфигурации плк и выполнения простейшей логики можно сделать и в симуляторе, а моргание лампочками - это вторичное))))

[rwg]

рекомендую освежить понятия "управление" и "регулирование". путать одно с другим не следует.

Ещё не стоит путать русское "Контроль" и английское "Control". Тоже совершенно разные слова.

[misha_os]

Если предстоит заниматься программированием ПЛК на языках МЭК, то начните с программируемых реле, на языке LD (LAD у Siemens). Обычно среды разработки и отладки бесплатные. Потом по практикуйтесь на FB и т.д. Очень многое зависит от ПЛК и соответственно среды разработки для данного ПЛК, но это уже нюансы.
По среде от Siemens см литературу от Бергера.

[Jackson]

С делфи вы же знакомы, логические операторы они везде одинаковы

Помнится, в далёкой версии 4.22 от ТрейсМоуд оператор GOTO означал УСЛОВНЫЙ переход, что немало меня удивило. :)

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

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

Я, честно говоря, не понял, почему опыт с реальным железом лишний, и спорить с этим не собираюсь, однако это неправда.

[megavolt86]

Я, честно говоря, не понял, почему опыт с реальным железом лишний

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

З.ы.: операторы то может и отличаются (в описании) в различных средах программирования, главное понимать какую функцию они несут, а понять это поможет справка - благо она бесплатная)))

[Jackson]

На первом этапе можно обойтись и без железа

Можно обойтись, а можно и не обойтись.

[Никита]

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

Весьма дельный совет, тем более что ему, как правило, не учат. Более того, "академические" программисты без некоторых подобных вещей "кушать не могут".

[Romcheg]

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

[Ryzhij]

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

Чет я после праздников туплю...
"С них", это с кого/чего?
С принципов МЭКа?
С задач?
С разработчиков?
С CoDeSys-ов, наконец?

[Jackson]

Весьма дельный совет, тем более что ему, как правило, не учат. Более того, "академические" программисты без некоторых подобных вещей "кушать не могут".

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

А про железо я посоветовал потому что скучно же просто так на экране лампочки зажигать. А может дело получиться. К примеру, я вот поделку для детей задумал - есть вполне конкретная задача которую надо решить. Совсем другой интерес.

[Ryzhij]

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

Сам факт существования такого языка MЭК как SFC, опровергает Ваш тезис, коллега.
Ах, если б всё было так, как Вы пишете!

[Jackson]

Сам факт существования такого языка MЭК как SFC, опровергает Ваш тезис, коллега.

Стоп, я же не говорю что невозможно реализовать. Даже в LD есть операторы перехода. И сам SFC - да, Вы правы совершенно. Я говорю что лично у меня просто не было необходимости использовать.

[Никита]

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

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

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

[Jackson]

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

Нет, тут всё как раз абсолютно.
Эти требования изложены в Правилах Классификации и постройки Морских Судов Норвежского Регистра (DNV), Если не путаю, то глава 4 часть 9 - Требования к вычислительным системам. Могу поискать если интересно.

[+] в частности

Там жёстко сказано, что не должно быть деления на ноль (избежать этого с гарантией можно только если делить на константу), не должно быть циклов с выходом по условию, не должно быть никаких переходов назад, вызываемая подпрограмма должна иметь 100% гарантию завершения и возврата (этому условию удовлетворяют только быстрые задачи с собственным вочдогом в ПЛК) и так далее. Поэтому не все ПЛК одобрены на море. В тогдашнем TSX37 были вочдоги не только на основной цикл ОС, но и на основной цикл программы и на быстрые задачи, это системная функция. Поэтому всё реализовать было довольно легко. И есть жесткое требование представить в составе сопроводительной документации на ПО доказательства выполнения вышеперечисленных требований (помимо философии системы, блок-схем, граф-схем, листинга и прочего). И всё это там похоже смотрели, потому как задали несколько уточняющих вопросов и дали пару толковых замечаний. Надо сказать, что системы, созданные по этим требованиям, безостановочно работают с 2003 года (ттт пусть и дальше работают).

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

[Никита]

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

[Romcheg]

"С них", это с кого/чего?
С принципов МЭКа?
С задач?
С разработчиков?
С CoDeSys-ов, наконец?

С CoDeSys'а конечно же. Есть разработки, которые делались изначально по образу и подобию данной среды разработки.

[Ryzhij]

1) Вообще это интересная позиция, запрещать циклы в системах, которые априори работают по циклу.
Родовое отличие PLC и PAC от PC именно в этом и состоит - в PLC и PAC не надо "вручную" наворачивать своих циклов внутри цикла исполнения задачи.
Всё уже зацикленно до нас.
Непонимание этого обстоятельства и есть самая распространенная "ошибка начинающего программиста" систем на базе PLC и/или PAC.

2) С написания модуля обработки ошибок следует начинать, а не заканчивать любой мало-мальски серьёзный проект ("проект" - в программерском смысле)

[Ryzhij]

С CoDeSys'а конечно же. Есть разработки, которые делались изначально по образу и подобию данной среды разработки.

А-а... Теперь понятно.
Ну, это извечно холиварный вопрос - кто, что, когда и у кого заимствовал.
Курица или яйцо?
Изучение OSCAT-библиотек, существующих как для CoDeSys, так и для Step7 однозначного ответа не даёт.
Оставим это потомкам-историкам.
Для меня взаимо-проникновение идей нормально и очевидно.

[Romcheg]

А-а... Теперь понятно.
Ну, это извечно холиварный вопрос - кто, что, когда и у кого заимствовал.
Курица или яйцо?
Изучение OSCAT-библиотек, существующих как для CoDeSys, так и для Step7 однозначного ответа не даёт.
Оставим это потомкам-историкам.
Для меня взаимо-проникновение идей нормально и очевидно.

Аааа, видимо Вы не в курсе, что Сименс уже дааавно не делает свой Step7 сам? Они его у 3S заказывают (это те, которые CoDeSys делают). Что-то типа ОЕМ-версии CoDeSys, на которую Сименс вешают бирочку свою.
Просто об это запрещено говорить... Тссс, страшная тайна. Вся разработка Step7 ведется в 3S.

Отсюда Вам и ответ, почему формат OSCAT в Step7 тоже читается...

[Ryzhij]

А если не сильно вникать в подробности, то на SFC его явно не разглядеть, там сама суть языка - даже не переходы, а зацикливание вызываемых подпрограмм с выходом по условию. А то и однократный CALL и дальше NOP с условным прыжком.

Коллега, ИМХО Вы несколько неудачно использовали слово "зацикливание".
Ничего подобного там не происходит.
Там, после выполнения условий перехода автомата из одного состояния в другое, происходит смена исполняемых задач ("вызываемых подпрограмм" в Вашей терминологии). Но без всякого "зацикливания". Просто неисполняемые в настоящее время участки кода обходятся.

Вообще, продвигаемый во многих IDE для PLC/PAC объектно-ориентированный подход к программированию, неизбежно и неразрывно связанный с переходами, с вызовом процедур и функций, не зло, а благо.
Это не причина проблем, а эффективное средство их решения.
Тут надо быть элементарно последовательными.
Желаете соблюдать новые стандарты в программировании - соблюдайте их во всём.

[+]

Доводилось слышать рассуждения про опасность "евростандарта" в расположении розеток внизу, у пола.
Мол, опасно для малышей.
На вопрос о применении УЗО по тому же "евростандарту" - недоумённое молчание.
Вот так вот, желаем брать только приглянувшееся. Но, как нельзя быть "немножко беременными", так и в подходах к применению новых нормативов действует принцип "всё или ничего".
Не можешь обеспечить новые нормы безопасности в детской комнате - ставь розетки по "советским" СНИП для дошкольных учреждений, не ниже 1,8 метров от пола.

[Ryzhij]

Отсюда Вам и ответ, почему формат OSCAT в Step7 тоже читается...

Во-первых, формат библиотек там разный.
Во-вторых, где OSCAT и где 3S ?!
Это совершенно разные организации. Типа, как "линюксоиды" и "мелкомягкие".