Будучи лучшим/более эффективным программистом ПЛК

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

Моя проблема как новичок в том, что я не могу быть действительно эффективным и быстрым, когда я программирую программное обеспечение PLC.

Хотя я очень эффективен, когда я кодирую С# или Java в VS/Eclipse

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

  • Это недостаток завершения кода?
  • Это недостаток общих знаний на стороне автоматизации?
  • Это недостаток инноваций в PLC, а не VS (LINQ, Dynamics, Lambda).

Есть ли у вас опыт работы с ПЛК? И как вы с ней продуктивны?

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

В ожидании многих замечательных ответов!

ОТВЕТЫ

Ответ 1

Программирование ПЛК отличается от обычного процедурного программирования несколькими способами:

1) Логика релейной логики - довольно примитивный язык. Его трудно быть столь же продуктивным.    Большинство программистов ПЛК не используют подпрограммы; его почти как если бы мир PLC    один из которых забыл время и программное обеспечение. Вы можете преуспеть, применяя    как следствие, простые методы разработки программного обеспечения, например, определять интерфейсы    между блоками кода, даже если абстрактно.

2) Большая часть программирования ПЛК связана с булевыми уравнениями. Если вы хотите быть хорошим    при программировании PLC, работать при работе с булевой логики: узнать Булева алгебра,    особенно такие вещи, как теорема Де Моргана для распространения НЕ через И и ИЛИ    (поскольку ПЛК обычно не предлагают операторы НЕ, вам это нужно гораздо больше     часто тогда вы ожидаете)

3) Поймите, что программирование ПЛК - это управление и обратная связь в реальном времени.    Большинство стандартных языков программирования (например, Java) плохо относятся к этому, если вообще.    Подумайте о том, что код ПЛК является логикой, которая управляет выходами,    и , что механические системы, управляемые, являются фактически "логическими", что    управляет входами PLC. Я часто моделировал механическую систему, используя другую    PLC, чтобы позволить мне отлаживать мою программу ПЛК, не требуя реальной машины factory, чтобы    контроль. Это также позволяет моделировать сбои; см. пункт 6.

4) Большая часть программирования ПЛС абстрактно связана с переходом от состояний к штатам,    где государство представляет то, что PLC знает о внешнем мире, и переходы    возникают, когда ПЛК считывает внешний вход и обнаруживает, что мировое государство имеет    немного изменился. Поймите столько, сколько сможете, о автоматах с конечным состоянием    и контроль над дискретными системами. Это будет вам очень приятно.

5) ПЛК часто нужно помнить прошлые события. Следовательно, большая часть логики ПЛК    связанные с установкой/сбросом/тестированием логических/числовых переменных состояния и/или таймеров. Поэтому, хотя код программы ПЛК часто выглядит как чистая логика, на самом деле это    имеет множество побочных эффектов, что делает довольно сложным рассуждение о программе. Так же сложно, как и на более современном языке, таком как C или Java.

6) Обратите внимание на обработку механических отказов. Большинство программ PLC предполагают    контролируемая система работает как рекламируемая; это действительно плохая практика. В реальном мире контролируемые    система работает так, как рекламируется только до тех пор, пока она не сломается, что всегда будет в конечном итоге.    Если вы включите диагностический код, который поможет определить, что механически нарушено в ваших программах ПЛК, это займет у вас больше времени    писать их, но пользователи будут любить вас, потому что нет ничего хуже, чем    a factory, который сломан, но он не скажет вам, как это сделать. Остановленный factory   это остановленный банкомат, а менеджеры factory ненавидят это.

Ответ 2

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

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

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

Чтобы подчеркнуть, что лестничная логика - это "забытое время в дисциплине", это унизить инструмент для выполнения этой функции. В конце концов, Лестница была первым языком, на самом деле представляющим физические устройства в программном обеспечении - это место объектно-ориентированного программирования как парадигма.

Кроме того, давайте не будем забывать, что ПК и элементы управления на ПК полностью ненадежны. Он падает; componentenet устарели и не могут быть приобретены в течение нескольких лет, в лучшем случае; он падает; он заражается вирусами и людьми, которые помещают "Donkey Kong" на свои рабочие станции; он падает; сверлильные операторы отключают программное обеспечение в третьей смене; и я упоминал, что он падает?

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

Наконец, я держу тест юмора. Часть, которая трещит меня, видит, как ребята пытаются писать код ПЛК. Бесконечный вопрос (буквально и образно), который, как нам кажется, получается: "Почему я получаю ошибку сторожевого таймера, когда я возвращаюсь к началу программы?" Или другой личный фаворит - "Как написать следующий цикл в лестнице?"

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

ТМ

Ответ 3

Я согласен с вами по 3 вопросам, которые вы упомянули.

У меня есть некоторый опыт работы с 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 для автоматизации enginneer, ST для программистов C/PASCAL...). поэтому, на мой взгляд, это не сложнее, чем что-либо еще. VS также имеет свою сложность: попробуйте сделать свой собственный OPC-сервер с С++, и вы оцените, что эта функция готова к использованию в большинстве программ SoftPLC. В этом случае intellisense не будет большой помощью.

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

Я надеюсь, что это поможет

Ответ 4

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

То, что вы видите, - это не просто разница между "настоящими" языками, такими как С# и Java, но разница между приложениями реального времени на ПК и управлением машиной в реальном времени, которая является основным для ПЛК.

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

Ответ 5

Взгляните на эти два продукта для Siemens Simatic Step7:

  • SCL (уже в Step7 Professional, также называемом ST или структурированным текстом)
  • CFC (отдельный продукт)

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

Те двое дадут вам эффективность, которую вы ищете, поэтому вы можете полностью забыть о STL/LAD/FBD (за исключением анализа кода других людей). Комбинированные, они очень мощные и RAD-инструменты для программирования ПЛК.

Ответ 6

Программное обеспечение ПЛК имеет свой фон:

  • является дополнительной частью пространства решений для механического и электрического моделирования (общей конструкции процесса)
  • повышенная зависимость от ПЛК более достойная альтернативная реализация, но без независимой методики моделирования
  • IEC61499 рекомендует UML в качестве метода проектирования для программирования ПЛК.

Разработать:

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

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

  • Недостаточное отсутствие моделирования программного обеспечения ПЛК и отказ от IEC61158 (моделирование распределенных объектов/данных/зависимостей Foundation fieldbus), IEC61499 был представлен в 2006 году с рекомендацией UML в качестве метода проектирования. Тем не менее, тенденция была и есть подход к функциональному объектно-ориентированному объекту, что приводит к сложным зависимостям объектов из-за временных привязок и состояний, которые обычно присущи технологическим приложениям, которые являются логически тяжелыми, а не тяжелыми данными, как в ИТ-индустрии. Таким образом, люди начинают выходить с инструментами анализа для проверки последствий и логических противоречий, отдельного временного и государственного моделирования и т.д., Фактически не делая ничего проще, и отклоняются от технического принципа сокращения проблемного пространства. Подход также не имеет сходства и непрерывности от механических, электрических и документирующих процессов.

Текущая ситуация:

а. IEC61131 и IEC61499, являющиеся стандартами производителя, а также бесплатные инженеры по контролю от необходимости работать в ОС реального времени, должны оставаться стандартами приложений на долгое время

б. UML - очень возможный проектный подход

с. шаблоны проектирования поверх UML должны обеспечивать одинаковые/равные/близкие с точки зрения моделей модели (поток данных, а не поток продукта, модель данных, чтобы быть практическими свойствами объекта), шаблоны связующего, шаблон эскалации ошибок, шаблон эскалации блокировки, неявные шаблоны растений и объектов и т.д. Хорошая модель данных в ПЛК также является ключом к успешному дизайну интерфейса или SCADA.

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