Поиск учебной литературы по программированию ПЛК

[dsai]

Добрый день, уважаемые коллеги!

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

Вопрос:
В связи с вышесказанным хотелось бы Вас попросить направить меня в нужное русло с помощью литературы необходимой. А именно интересуют правила (методики) написания ПО, учебная литература по структуризации, оптимизации и удобных методах отладки ПО.

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

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

P.S. [2] самостоятельный поиск литературы не дал плодов. В основном наталкиваюсь на описание языков программирования и описание штатных ФБ, которые я итак уже успел изучить с помощью справок и видео. Либо же общий университетский материал.

Заранее спасибо за помощь!

[Михайло]

Почему возникает неудовлетворенность самообучением? Что-то до сих пор непонятно и не получается?

[dsai]

Почему возникает неудовлетворенность самообучением? Что-то до сих пор непонятно и не получается?

Сам понимаю, что делаю достаточно много вещей не так, как многие. И процесс отладки затруднён в плане слабой структуризации. Вопросов оптимизации вообще даже не касался раньше, сейчас в связи с тем, что приходится работать с одним простенький контроллером пришлось задуматься над ней.

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

Вот как минимум 2 причины для того, чтобы начать материалы полезные и прекратить частичную самодеятельность

[Valerich]

Сам начинал прогать ПЛК самоучкой лет 10 назад. И по прошествию лет, открывая свои старые проекты, хочется переписать всё по-новой)))

Сам понимаю, что делаю достаточно много вещей не так, как многие.

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

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

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

И процесс отладки затруднён в плане слабой структуризации.

Вот в этом направлении стоит поработать.
При написании ТЗ поделить систему на функциональные блоки и так поблочно и переносить в проект, а не валить всё в кучу.

[paul-th]

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

[pkl58]

Но недавно наткнулся на интересный мануал (руководство по программированию контроллера одной фирмы). В нем увидел множество интересных и полезных идей. А в частности о структуризации программы, что заставило задуматься о правильности подхода написания ПО.

Поделились бы. Многие бы почитали.

[dsai]

Но недавно наткнулся на интересный мануал (руководство по программированию контроллера одной фирмы). В нем увидел множество интересных и полезных идей. А в частности о структуризации программы, что заставило задуматься о правильности подхода написания ПО.

Поделились бы. Многие бы почитали.

Руководство по программированию Siemens s1200

Отправлено спустя 2 минуты 47 секунд:

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

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

Также обращение в разным областям памяти, может влиять. Но документации по этому поводу не нашел.

[Jackson]

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

Весь форум для этого и предназначен. Задавайте вопросы.

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

В общем же, есть разные фундаментальные вещи, которые не помешают, если придутся по душе (да-да). И тут каждый выбирает свою науку. Я, например, выбрал конечные автоматы и методы их решения, с приложением диалектики (философское направление 18-19 веков расцвета). Близкий по теме труд был написан г-ном Шалыто, назывался "SWITCH-технология" (изучил в теории, но практического применения не нашёл).

Вот, например, опыт. А дальше - только собственные мозги. На то и программист, хотя я себя им не считаю.

Отправлено спустя 3 минуты 25 секунд:

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

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

[stesl]

Руководство по программированию Siemens s1200

Вот даже не удивился )
На самом деле вопрос поставлен правильно. В традиционном программировании есть и методики разработанные и подходы и рекомендации. АСУ все же считается этаким не до программированием. Ну по крайней мере, конкретно я - встречал такую снисходительность у коллег, работающих над "классическими" проектами. Так что видимо только обмен опытом нам и остается. Какие то фундаментальные предметы, тот же СИАОД, как то слабо проецируются на реальность АСУ программирования. А яркая отличительная особенность ОСРВ - постоянный цикл, накладывает жесткие ограничения на какие то подходы к кодингу.
Про себя я могу сказать примерно то же самое, что и предыдущие коллеги. Не стоять на месте. Открывать и изучать новые языки МЭК и их возможности. Использовать по максимуму тот потенциал, что дает вендор. Это я сейчас о том псевдо ООП подходе у Simatic, структурные данные и PW в WinCC ) Ну и конечно больше общаться друг с другом

Однако, ветку пофиксил ) Вдруг кто то предложит нечто более реальное

[Jackson]

Вот даже не удивился )

Аналогично старое руководство по PL7 от Шнайдера - тоже всё толково разъяснено. И в самом PL7 очень толковый хелп.

Отправлено спустя 4 минуты 22 секунды:

Так что видимо только обмен опытом нам и остается

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

Какие то фундаментальные предметы, тот же СИАОД, как то слабо проецируются на реальность АСУ программирования.

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

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

[+]

хотя, чаще бывает в обратную сторону: "Дефицит вычислительных средств ведёт к дисциплине мышления" (с). Однако и в обратную сторону это работает, я убеждаюсь в этом постоянно.

[Jackson]

Этим и отличается инженер АСУТП от программиста АСУТП. Инженер создаёт АСУ с учётом алгоритмов и кода, которые он реализует в этой АСУ, даже если алгоритм ещё не создан. Чистый программист не способен это сделать - он по шаблону поставит ПЛК помощнее с максимальным набором в/в, а потом будет думать, как эти в/в обрабатывать и напишет много лишнего кода, который придется отлаживать, за что получить премию за сверхурочную работу. В то время как инженер АСУТП не получит премию по причине отсутствия сверхурочной работы, а освободившееся от отладки время он проведёт либо за углублением фундаментальных знаний либо в объятиях любимой женщины - у него есть выбор.

Так вот Вы, автор, и решите, инженер Вы АСУ, или программист. От этого зависит, что Вам надо для работы.

[Jackson]

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


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

[dsai]

Вот даже не удивился )

Аналогично старое руководство по PL7 от Шнайдера - тоже всё толково разъяснено. И в самом PL7 очень толковый хелп.

Отправлено спустя 4 минуты 22 секунды:

Так что видимо только обмен опытом нам и остается

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

Какие то фундаментальные предметы, тот же СИАОД, как то слабо проецируются на реальность АСУ программирования.

Дефицит вычислительных средств ведёт к дисциплине мышления" (с). Однако и в обратную сторону это работает, я убеждаюсь в этом постоянно.[/spoiler]

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

[stesl]

поставит ПЛК помощнее с максимальным набором в/в

Ну есть такое )

а потом будет думать, как эти в/в обрабатывать и напишет много лишнего кода, который придется отлаживать, за что получить премию за сверхурочную работу. В то время как инженер АСУТП не получит премию по причине отсутствия сверхурочной работы, а освободившееся от отлад

Ну тут уже под какую то общую гребенку

Так вот Вы, автор, и решите, инженер Вы АСУ, или программист. От этого зависит, что Вам надо для работы.

Программист АСУ и должности то такой не встречал. Но я не инженер АСУ. Должность озвучивал. Задачи естественно комплексные, но как то Вам, Джексон, удалось перейти от общего вопроса к частности, конкретно к личности.

Мне не совсем понятна, кстати, общая тенденция на форуме, сделать дешевле. Это потому что работаем на себя в основном? Или так радеем за средства предприятия? У меня в приоритете надежность, степень отказоустойчивости. Цена вообще мало интересует. И если я строю какую то новую систему, то конечно же с заделом на будущее. Лишний модуль в/в я точно поставлю. Потому что задачи возникают постоянно. А ждать такой модуль через систему закупок - ну можно, но долго. В дальнейшем, этот не используемый модуль могу и снять куда то. Все по ситуации.

[VADR]

Мне не совсем понятна, кстати, общая тенденция на форуме, сделать дешевле. Это потому что работаем на себя в основном? Или так радеем за средства предприятия?

Это потому что пытаемся сделать чтобы работало, и работало хорошо, а бюджет ограничен. Обычное явление на предприятиях - отдать за бухгалтерскую софтинку раз в 10 больше, чем за АСУТП агрегата, который эти деньги зарабатывает.

[Velt]

Насчет запаса В/В по своему опыту хочется сказать следующее.
Если речь идет о типовых шкафах автоматики, конструкция и программа которых отлажена и проверена на практике, то избыточные в/в обычно не требуются.
У нас же почти все новые проекты отличаются от предыдущих. Ну в лучшем случае - чем-то похожи. И не раз происходила ситуация, что экономия модулей в/в и других аппаратных ресурсов приводила к необходимости делать перемонтаж в шкафу уже на объекте во время ПНР, что влекло за собой потерю времени и трудовых ресурсов.

Другими словами, экономия бюджета на этапе проектирования и конструирования приводила к его перерасходу на ПНР.

[Jackson]

Мне не совсем понятна, кстати, общая тенденция на форуме, сделать дешевле.

А Вы в магазине давно были? Посмотрите, многие ли покупают лосося за 1900+.
Вот и здесь также.
Не, можно все деньги положить на дорогую и наверное качественно сделанную (что не факт) АСУ, но хочется и на лосося чтобы осталось, хотя бы на "парникового".

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

Другими словами, экономия бюджета на этапе проектирования и конструирования приводила к его перерасходу на ПНР.

Всё должно быть в меру и разумно. Вы нашли для себя обоснование высокой стоимости - хорошо. У других своё обоснование и своя стоимость. Добро пожаловать на рынок.

Отправлено спустя 1 минуту 35 секунд:
Но это уже разговор для другой темы, не надо всё в одну кучу мешать.

[stesl]

Посмотрите, многие ли покупают лосося за 1900+.

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

Добро пожаловать на рынок.

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

И да, согласен, скатываемся к дискуссии не по теме. Прошу прощения.

[dsai]

Много можно говорить на тему того, что можно сделать дорого или дёшево, но суть одна. И то и то должно быть надёжно и хорошо. И во всех случаях должно быть просто. Так как "утяжеление" кода не приводит ни к чему хорошему. Отсюда и стремление найти литературу, учиться и развиваться.

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

[Jackson]

но в свободном доступе данной информации и даже рекомендаций не видел.

Есть, всё есть. Нужно зрить в корень, и там всё просто. Это и есть те самые фундаментальные вещи, о которых я говорил. А готовых примеров "как мне решить задачу" вы не найдёте, потому что частных задач миллиарды, и это как бы ноу-хау на секундочку, если задача чуть сложнее кипячения воды в чайнике.

[Jackson]

А что до конкретных ссылок - это тоже уже дали. Программирование? Называли руководства. Я ещё дополню этот список руководством от Weintek, там есть примеры в разделе про скрипты. По алгоритмизации - например я называл описание одного из методов. Фундаментальные вещи - и их я тоже называл.

[dsai]

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

Понимаю что упирается в ресурсы и фантазию, но должен быть и здравый смысл. А где грань между этим самым здравым смыслом и фанатизмом защиты?

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

Таких вопросов много. Еще раз повторюсь, можно сделать все что придет в голову, но это уже фанатизм. Был один объект, где просили максимум защиты, запуски были тяжёлые, часть защиты пришлось убирать (сначала просили жестко зашить,поэтому с кнопки не выключишь)

[pkl58]

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

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

[dsai]

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

[pkl58]

Вот вам пример как делаю обработку аварийных ситуаций исполнительного механизма, контролируемого датчиком положения:
Выход механизма ВКЛ ( механизм движется из положения 0 в положение 1) - контроль отключения датчика положения 0 по таймеру ( время - необходимое для срабатывания датчика в штатном режиме плюс немного для исключения ложных срабатываний), затем срабатывание датчика положения 1 по тому же принципу. При выходе ВЫКЛ также контроль этих датчиков, только логика обратная .
Итого на один выход четыре аварийных сообщения. Затем дискретные аварии объединяются в двойные слова и сравнивая с 0 этого 32 разрядного слова отслеживается авария.