Будучи лучшим / более эффективный [закрытый] Программист PLC
Имейте большой список AIM/бессмысленных данных, заполненный хорошо осведомленными людьми Perl, с которыми Вы дружите.
5 ответов
Программирование ПЛК отличается от обычного процедурного программирования несколькими способами:
1) Релейная лестничная логика - это довольно примитивный язык. Трудно быть таким продуктивным. Большинство программистов ПЛК не используют подпрограммы; это почти как если бы мир ПЛК тот, который забыл тогда и программная инженерия. Вы можете преуспеть, применив как следствие, простые методы разработки программного обеспечения, например, определение интерфейсов между блоками кода, даже если абстрактно.
2) Большая часть программирования ПЛК имеет дело с булевыми уравнениями. Если ты хочешь быть хорошим при программировании ПЛК усердно при работе с булевой логикой: изучите булеву алгебру, особенно такие вещи, как теорема Де Моргана для распределения НЕ по И и ИЛИ (поскольку ПЛК обычно не предлагают операторов НЕ, вам это нужно намного больше часто тогда можно ожидать)
3) Поймите, что программирование ПЛК - это управление и обратная связь в реальном времени. Большинство стандартных языков программирования (например, Java) плохо справляются с этим, если вообще решают. Тщательно подумайте о том, что код ПЛК - это логика, управляющая выходами, и , что приводимые в действие механические системы фактически являются «логикой», которая управляет входами ПЛК . Я часто моделировал механическую систему, используя другой ПЛК, просто чтобы позволить мне отладить мою программу ПЛК, не нуждаясь в реальной заводской машине для контроль. Это также позволяет моделировать сбои; см. пункт 6.
4) Большая часть программирования ПЛК абстрактно связана с переходом из состояний в состояния, где состояние представляет то, что ПЛК знает о внешнем мире, а переходы возникают, когда ПЛК считывает внешний ввод и обнаруживает, что состояние мира имеет несколько изменилось. Узнайте как можно больше о конечных автоматах и диспетчерское управление дискретными системами. Это хорошо окупится.
5) ПЛК часто нуждаются в запоминании прошлых событий. Следовательно, большая часть логики ПЛК занимается установкой / сбросом / тестированием логических / числовых переменных состояния и / или таймеров. Таким образом, хотя код программы ПЛК часто выглядит как чистая логика, на самом деле он имеет множество побочных эффектов, что усложняет рассуждение о программе. На самом деле так же сложно, как писать на более современном языке, таком как C или Java.
6) Обратите внимание на обработку механических сбоев. Большинство программ ПЛК предполагают управляемая система работает как рекламируется; это действительно плохая практика. В реальном мире контролируемые система работает так, как заявлено, только до тех пор, пока не сломается, что она всегда в конечном итоге и делает. Если вы включите диагностический код, чтобы определить, что механически сломано в ваших программах ПЛК, это займет больше времени. написать их, но пользователи полюбят вас, потому что нет ничего хуже, чем заводская машина, которая сломана, но не скажет, как. Остановленный завод это остановившийся банкомат, и руководители заводов это ненавидят.
Разработка программного обеспечения ПЛК имеет свою предысторию:
- являясь дополнительной частью пространства решений для механического и электрического моделирования (общей схемы технологического процесса)
- , повышается зависимость от ПЛК, как более достойной альтернативы реализации, но без независимой техники моделирования
- IEC61499 рекомендует UML в качестве метода проектирования для программирования ПЛК.
Для уточнения:
являясь дополнительными компонентами, ПЛК использовался в качестве контроллеров последовательности / состояния / контура, блокировки защиты, формирования сигнала, и т. д., имеющие функции, указанные в IEC61131. Требование четко отражено в механических и электрических моделях, нет необходимости в независимом моделировании.
возросла зависимость от ПЛК при выполнении требований по исключениям процессов, процедурам восстановления, был разработан многоэтапный анализ режимов отказа и управление последствиями, неосознанное принятие методики проектирования шаблонов. Однако в разных отраслях разные перерабатывающие компании используют разный подход. Как правило, они основаны на традиционных моделях, литературе по спецификациям функционального дизайна, сквозном списке причин и следствий, условном управлении ситуациями с использованием логических диаграмм. Основными принципами являются всестороннее тестирование, непрерывное применение и исправление, возможность многократного использования для совершенствования их подхода к проектированию.
Несмотря на отсутствие программного моделирования ПЛК и отказ IEC61158 (моделирование распределенных объектов / данных / зависимостей Foundation fieldbus), IEC61499 был представлен в 2006 году. с рекомендацией UML в качестве метода проектирования. Однако тенденция к моделированию функциональных объектов была и есть. что приводит к сложным зависимостям объектов из-за временных привязок и привязок состояний, обычно присущих приложениям процессов, которые являются тяжелыми с логической точки зрения, а не с данными, как в ИТ-отрасли. Таким образом, люди начинают выпускать инструменты анализа для проверки следствий и логических противоречий, отдельного моделирования времени и состояния и т. Д., Фактически не упрощая задачу и отклоняясь от инженерного принципа уменьшения проблемного пространства. Этому подходу также не хватает сходства с документацией по механическому, электрическому и технологическому моделированию и их преемственности.
Текущая ситуация:
a. IEC61131 и IEC61499, являющиеся стандартами производителя и освобождающие инженеров по управлению от необходимости работать над проблемами ОС в реальном времени, должны оставаться стандартами приложений в течение долгого времени
b. UML - очень возможный подход к проектированию
c. шаблоны проектирования поверх UML должны гарантировать, что объектные модели подобны / равны / близки моделям процессов (поток данных вместо потока продукта, модель данных должна быть практическими свойствами объекта), шаблоны связывания, шаблон эскалации сбоев, шаблон эскалации блокировки, неявные шаблоны установок и объектов и т. д. Хорошая модель данных в PLC также является ключом к успешному проектированию пользовательского интерфейса или SCADA.
Я успешно реализовал системы, разработав полностью рационализированный набор шаблонов проектирования для водоочистной установки и заводского конвейера. с погрузочно-разгрузочными машинами. Мне нужна среда для разработки шаблонов проектирования, слишком много, чтобы говорить о ней, концептуальная основа для объектов измерения / оборудования / подсистем / процесса / завода, их зависимости в худшем случае, их неявные отношения, некоторые простые правила для ограничения и управления распространением изменений , так далее.
Я согласен с вами по трем упомянутым вами вопросам.
У меня есть некоторый опыт работы с CoDeSys, и я думаю, что 2 из этих проблем исчезли с версией 3.x.
* Is it the lack of code completion?
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)
CoDeSys 3.x обладает интеллектом и удобным редактором, и он привносит объектно-ориентированное программирование в мир ПЛК, что, на мой взгляд, является очень хорошим нововведением.
Я думаю, что это помогает повысить производительность. Я не знаю, делают ли конкуренты CoDeSys аналогичные вещи, но я думаю, что на рынке программирования ПЛК происходят интересные вещи.
Недостаток знаний является общим для всех технологий. Стандарт IEC-1131 разработан таким образом, чтобы его можно было легко понять независимо от уровня подготовки разработчика (LD для электриков, FBD для инженеров по автоматизации, ST для программистов на C / PASCAL ...). так что, на мой взгляд, это не сложнее всего остального. VS также имеет свою сложность: попробуйте создать свой собственный OPC-сервер на C ++, и вы оцените готовность этой функции к использованию в большинстве SoftPLC. В этом случае intellisense не будет большим подспорьем.
Конечно, рынок программирования ПЛК менее динамичен, чем обычные инструменты программирования. Я думаю, что это происходит из индустриального мира, который предпочитает защищенные от логики технологии, а не привлекательные для маркетинга вещи.
Надеюсь, это поможет
Языки программирования - это инструменты. Если вы знаете только один язык, у вас есть только один инструмент. Этот инструмент может быть хорош для одной работы, хорош для пары других и бесполезен для всего остального. Если вы знаете больше инструментов, вы можете делать больше работы.
То, что вы видите, это не только разница между "настоящими" языками, такими как C# и Java, но и разница между приложениями не реального времени на ПК и управлением машинами в реальном времени, что является основным применением ПЛК.
Хорошие программисты знают языки, великие программисты знают процессы. Они понимают не только язык, на котором программируют, но и процесс, который выполняет программирование. Если вы собираетесь писать бухгалтерские программы, вам нужно разбираться в бухгалтерии. Если вы собираетесь написать код ПЛК для управления машиной, вам лучше знать, что делает эта машина и как она работает.
Меня раздражает, когда к программированию ПЛК относятся с пренебрежением так называемые "настоящие" программисты. Несколько сообщений здесь намекнули на основной факт, что программирование ПЛК - это отдельная дисциплина.
«Поймите, что программирование ПЛК - это управление и обратная связь в реальном времени. Большинство стандартных языков программирования (например, Java) плохо справляются с этим, если вообще решают».
«Итак, люди начинают предлагать инструменты анализа последствий и логических противоречий. проверка, отдельное временное моделирование и моделирование состояний и т. д., на самом деле не упрощающие вещи и отклоняющиеся от инженерного принципа сокращения проблемного пространства »
. Намекать на то, что лестничная логика - это« дисциплина, которую забыло время », - значит пренебрегать инструментом для выполнения это функция.В конце концов, Ladder был первым языком, который фактически представлял физические устройства в программном обеспечении - это место рождения объектно-ориентированного программирования как парадигмы.
Кроме того, давайте не будем забывать, что ПК и средства управления на базе ПК совершенно ненадежны. Вылетает; компоненты устаревают и, в лучшем случае, не могут быть куплены в течение нескольких лет; он вылетает; он заражается вирусами и людьми, которые ставят Donkey Kong на свои рабочие места; он вылетает; скучающие операторы деинсталлируют программное обеспечение в третью смену; и я уже упоминал, что он дает сбой?
ПЛК продолжают существовать после стольких лет так называемого «прогресса» в мире ПК, потому что по сей день ПК все еще являются одноразовым товаром, изобилующим ошибками. А вашей многомиллионной сборочной линии нет.
Наконец, я провожу тест на юмор. Меня раздражает то, что ИТ-специалисты пытаются написать код PLC. Бесконечный вопрос (в прямом и переносном смысле), который мы, кажется, получаем: «Почему я получаю сторожевую ошибку, когда возвращаюсь к началу программы?» Или другой личный фаворит - «Как мне написать цикл for-next в лестничной диаграмме?»
Оба выдают фундаментальный недостаток знаний о том, как работают ПЛК, и служат для иллюстрации того, что программирование автоматизации - это отдельная дисциплина, требующая отдельных инструментов .
TM