Pull to refresh

Comments 23

Скажите, а программы для ПЛК, созданные на представленных выше языках, компилируются в конечном итоге в native код или запускаются под каким-либо интерпретатором, который положил туда производитель?
Есть пример того, как программы сначала компилируются из SFC, FBD и т.д. в ST, а потом из ST в С/С++ код, а дальше можно компилировать уже под любую целевую платформу под которую у Вас есть компилятор.
Зависит от конкретного контроллера. Если это ПЛК на «своей» платформе, то, думаю на выходе генерируется native. По крайней мере, на младшие модели того же Beckhoff можно, покопавшись в папке TwinCAT'а (это несколько переделанный под нужды Beckhoff CoDeSys) найти результат компиляции в виде .hex — файла.
А вот в случае с ПЛК на базе WinCE, все же есть некий промежуточный код. Специально заглянул на работающий на одном из объектов Beckhoff CX1010, у него процессор x86, и то, что лежит у него на флешке, как результат компиляции, на код под эту архитектуру не похоже.
я может немного неправильно понимаю: а вот если например, среда разработки запущена (поддерживающая МЭК 61131-3 под операционной системой Windows, а сами ПЛК работаю под linux), то каким образом происходит компиляция сгенерированного native-кода? Кросс-компиляция?
Если сам ПЛК работает под своей ОС, то наверняка генерируется некий промежуточный код, не нативный. А на ПЛК он исполняется службой-интерпретатором.
Мне пришлось работать с контроллерами Mitsubishi и Siemens и могу сказать про обоих — результат компиляции проекта это бинарный файл с с кодом являющимся шестнадцатеричным представлением IL(Instruction List), и выполняется этот код на виртуальной машине, которая обслуживается внутренней, закрытой ОС контроллера. Тоесть IL — это и есть ассемблер этой виртуальной машины. Что касается CodeSys и других «виртуальных» PLC — в них все реализовано абсолютно так же, с одной лишь разницей, что эта виртуальная машина выполняется как приложение какй нибудь ОС — WinCE, WinXP, Linux, QNX итд…
а есть какие-нибудь opensource решения таких виртуальных машин, например, для выполнения ST кода, ну или IL?
ST код не выполняется, он компилируется в IL после чего транслируется в в бинарник для конкретного контроллера. Опен сорс решений как я не пытался найти не смог, в принципе стандарт IL не очень сложен и можно разработать собственную виртуальную машину для его исполнения.
Ребята из Wago (как соавторы Beckhoff в создании ПЛК) утверждают, что у них программа компилируется в native. Про интерпретаторы в Siemens выше сказали.
В принципе, Beckhoff и Wago друг на друга очень похожи. Вплоть до того, что если логотип стереть, их не отличишь с ходу. Поэтому вполне вероятно, что под те серии ПЛК, которые делались вместе с Wago (это BC серия, прежде всего) там действительно native-код.
А вот старшая CX-серия уже не имеет с Wago ничего общего, там интерпретатор, как я уже писал.
У них (бэкхоффские ВС/ВК) еще и модули дискретные и аналоговые взаимозаменяемые ;)
Видимо, взаимозаменяемы модули, которые у бэкхоффа серии KL. У них есть более новая серия EL (там шина межмодульная на базе Ethernet, быстродействие выше на порядки).
Спасибо за освещение этой интересной темы. Я думаю стоит упомянуть, что языки стандарта МЭК 61131-3 можно комбинировать при использовании. Т.е. например, я пишу на языке SFC (который очень похож на диаграмму состояний), графическим способом (на диаграммах) показываю состояния, а например условия перехода из одного состояния в другое можно можно написать на ST (получится что-то на подобии скрипта). Я такое практиковал, получалось. Правда, не знаю, правильно ли это с точки зрения Best Practice 61131-3.
Еще конечно же стоит упомянуть, если касаться МЭК 61131-3 про такие конструкции и части как Functional Block, Configuration, Resources. Думаю тоже небольшой пост просто это написать, надо только время найти на это, чтобы качественно сделать.
Да, комбинировать можно. Хорошо это, или плохо — с какой точки зрения смотреть.
Само собой, что обзором на 2 странички покрыть все возможности не получится. Но, как я и написал, если эта тема интересна — расскажу и про блоки, и про ресурсы, и про области памяти — там много всего, и немало интересного. Ну и про то, как на встроенном дисплее CX1010 написать «Hello Habr!» тоже, в порядке шутки юмора.
Ооо, будет здорово! Если есть возможность пишите больше про эту тему :)
Автор — молодец!
Сименсы — это действительно нужная вещь на производстве.
А вот, например, ПЛК фирмы Unitronics — адская штука, не желаю никому связываться.

Нужно было ПК связать с контроллером по Ethernet — проблем огрёб.
1) Отправили из Израиля бракованную карту — либо где-то дорожка отошла/треснула, либо существует негласное правило эксплуатации — но ее пришлось согнуть «пропеллером», чтобы хотя бы светодиодики как-то замигали.
2) API для обращения к ним по сети — отдельный разговор. Залили на рабочие Vision280 и Vision570 одинаковую прошивку. Запускали на ПК одну и ту же программу. С разными моделями контроллеров она работала по-разному (570-ые вообще отказывались отвечать на запросы). А в документации пишут, что API не специфичен для конкретных моделей
3) Техподдержка не даёт внятных ответов на п.2

Да и вообще все АСУ ТПшники плюются от них.
Ну могу сказать, что тот же Beckhoff тоже не идеален. Был у них такой контроллер BX9000, их сняли с производства, насколько я знаю. Глупейшая недоработка — сэкономили на гальванической развязке порта RS-485, как следствие — летели они со страшной скоростью, особенно по зиме.
Но с обменом с «внешним миром» никогда никаких проблем с ними не было. Есть свой протокол обмена — закрытый, но библиотеки с его реализацией бесплатные. А по Ethernet большинство их ПЛК умеют ModBUS TCP.
Есть ещё маленький конкурент Beckhoffа — WAGO. Мы пользуемся их контроллерами на ARM7tdi, правда я не уверен, запустится ли на них CoDeSys, у нас своя система.
Да не знаю, насколько они прям вот что конкуренты… бекхов, насколько я знаю — осколок ваго. Выше обсуждали их похожесть.
Ничего адского в Unitronics нет — как, впрочем, и выдающегося :)
Дешёвый он. Вот, пожалуй, главный плюс.
Хотелось бы заметить, что под понятием Fieldbus скрывается еще отдельная, весьма занятная, шина, которую там любит Yokogawa. Fieldbus Foundation
Правда реализация иногда доводит КИП-арей до истерики. Особенно когда сеть кусками отваливается часов на 12. А все го лишь устройство рядовое в сегменте вырубилось.
Под Fieldbus подрузамевается гораздо больше шин, например любимчики Сименса PROFIBUS и PROFINET. У Йокогавы, кстати, тоже есть PROFIBUS IO модули, у нас вроде стабильно работают.
Разновидностей filedbus-а очень много, я привел просто несколько примеров. Тот же CAN, например — это просто описание физического интерфейса, уровень 1 модели OSI. А поверх него существует множество протоколов обмена, например широко распространен CANOpen, у бехоффа есть ADS over CAN, и т.д. И есть не только «медные» шины, есть и оптика, например, LightBus.
А насчет «отвалов кусками» — большинство этих шин как физическую среду используют витую пару, толстую и с мощным экраном. И там очень критично выполнение требований заземления этого экрана, лотка, где этот кабель лежит, и т.д. Где-нибудь отошла земля — и вуаля, получите перемежающиеся сбои, которые очень трудно выловить. У шнайдер-электрик есть хорошее пособие по организации сетей RS-485 ModBUS — почти все сказанное там применимо и к другим промышленным шинам.
Sign up to leave a comment.

Articles