Comments 23
Скажите, а программы для ПЛК, созданные на представленных выше языках, компилируются в конечном итоге в native код или запускаются под каким-либо интерпретатором, который положил туда производитель?
+1
Есть пример того, как программы сначала компилируются из SFC, FBD и т.д. в ST, а потом из ST в С/С++ код, а дальше можно компилировать уже под любую целевую платформу под которую у Вас есть компилятор.
0
Зависит от конкретного контроллера. Если это ПЛК на «своей» платформе, то, думаю на выходе генерируется native. По крайней мере, на младшие модели того же Beckhoff можно, покопавшись в папке TwinCAT'а (это несколько переделанный под нужды Beckhoff CoDeSys) найти результат компиляции в виде .hex — файла.
А вот в случае с ПЛК на базе WinCE, все же есть некий промежуточный код. Специально заглянул на работающий на одном из объектов Beckhoff CX1010, у него процессор x86, и то, что лежит у него на флешке, как результат компиляции, на код под эту архитектуру не похоже.
А вот в случае с ПЛК на базе WinCE, все же есть некий промежуточный код. Специально заглянул на работающий на одном из объектов Beckhoff CX1010, у него процессор x86, и то, что лежит у него на флешке, как результат компиляции, на код под эту архитектуру не похоже.
+1
я может немного неправильно понимаю: а вот если например, среда разработки запущена (поддерживающая МЭК 61131-3 под операционной системой Windows, а сами ПЛК работаю под linux), то каким образом происходит компиляция сгенерированного native-кода? Кросс-компиляция?
0
Мне пришлось работать с контроллерами Mitsubishi и Siemens и могу сказать про обоих — результат компиляции проекта это бинарный файл с с кодом являющимся шестнадцатеричным представлением IL(Instruction List), и выполняется этот код на виртуальной машине, которая обслуживается внутренней, закрытой ОС контроллера. Тоесть IL — это и есть ассемблер этой виртуальной машины. Что касается CodeSys и других «виртуальных» PLC — в них все реализовано абсолютно так же, с одной лишь разницей, что эта виртуальная машина выполняется как приложение какй нибудь ОС — WinCE, WinXP, Linux, QNX итд…
+1
а есть какие-нибудь opensource решения таких виртуальных машин, например, для выполнения ST кода, ну или IL?
0
Ребята из Wago (как соавторы Beckhoff в создании ПЛК) утверждают, что у них программа компилируется в native. Про интерпретаторы в Siemens выше сказали.
+1
В принципе, Beckhoff и Wago друг на друга очень похожи. Вплоть до того, что если логотип стереть, их не отличишь с ходу. Поэтому вполне вероятно, что под те серии ПЛК, которые делались вместе с Wago (это BC серия, прежде всего) там действительно native-код.
А вот старшая CX-серия уже не имеет с Wago ничего общего, там интерпретатор, как я уже писал.
А вот старшая CX-серия уже не имеет с Wago ничего общего, там интерпретатор, как я уже писал.
+2
Спасибо за освещение этой интересной темы. Я думаю стоит упомянуть, что языки стандарта МЭК 61131-3 можно комбинировать при использовании. Т.е. например, я пишу на языке SFC (который очень похож на диаграмму состояний), графическим способом (на диаграммах) показываю состояния, а например условия перехода из одного состояния в другое можно можно написать на ST (получится что-то на подобии скрипта). Я такое практиковал, получалось. Правда, не знаю, правильно ли это с точки зрения Best Practice 61131-3.
Еще конечно же стоит упомянуть, если касаться МЭК 61131-3 про такие конструкции и части как Functional Block, Configuration, Resources. Думаю тоже небольшой пост просто это написать, надо только время найти на это, чтобы качественно сделать.
Еще конечно же стоит упомянуть, если касаться МЭК 61131-3 про такие конструкции и части как Functional Block, Configuration, Resources. Думаю тоже небольшой пост просто это написать, надо только время найти на это, чтобы качественно сделать.
0
Да, комбинировать можно. Хорошо это, или плохо — с какой точки зрения смотреть.
Само собой, что обзором на 2 странички покрыть все возможности не получится. Но, как я и написал, если эта тема интересна — расскажу и про блоки, и про ресурсы, и про области памяти — там много всего, и немало интересного. Ну и про то, как на встроенном дисплее CX1010 написать «Hello Habr!» тоже, в порядке шутки юмора.
Само собой, что обзором на 2 странички покрыть все возможности не получится. Но, как я и написал, если эта тема интересна — расскажу и про блоки, и про ресурсы, и про области памяти — там много всего, и немало интересного. Ну и про то, как на встроенном дисплее CX1010 написать «Hello Habr!» тоже, в порядке шутки юмора.
+1
Автор — молодец!
Сименсы — это действительно нужная вещь на производстве.
А вот, например, ПЛК фирмы Unitronics — адская штука, не желаю никому связываться.
Нужно было ПК связать с контроллером по Ethernet — проблем огрёб.
1) Отправили из Израиля бракованную карту — либо где-то дорожка отошла/треснула, либо существует негласное правило эксплуатации — но ее пришлось согнуть «пропеллером», чтобы хотя бы светодиодики как-то замигали.
2) API для обращения к ним по сети — отдельный разговор. Залили на рабочие Vision280 и Vision570 одинаковую прошивку. Запускали на ПК одну и ту же программу. С разными моделями контроллеров она работала по-разному (570-ые вообще отказывались отвечать на запросы). А в документации пишут, что API не специфичен для конкретных моделей
3) Техподдержка не даёт внятных ответов на п.2
Да и вообще все АСУ ТПшники плюются от них.
Сименсы — это действительно нужная вещь на производстве.
А вот, например, ПЛК фирмы Unitronics — адская штука, не желаю никому связываться.
Нужно было ПК связать с контроллером по Ethernet — проблем огрёб.
1) Отправили из Израиля бракованную карту — либо где-то дорожка отошла/треснула, либо существует негласное правило эксплуатации — но ее пришлось согнуть «пропеллером», чтобы хотя бы светодиодики как-то замигали.
2) API для обращения к ним по сети — отдельный разговор. Залили на рабочие Vision280 и Vision570 одинаковую прошивку. Запускали на ПК одну и ту же программу. С разными моделями контроллеров она работала по-разному (570-ые вообще отказывались отвечать на запросы). А в документации пишут, что API не специфичен для конкретных моделей
3) Техподдержка не даёт внятных ответов на п.2
Да и вообще все АСУ ТПшники плюются от них.
0
Ну могу сказать, что тот же Beckhoff тоже не идеален. Был у них такой контроллер BX9000, их сняли с производства, насколько я знаю. Глупейшая недоработка — сэкономили на гальванической развязке порта RS-485, как следствие — летели они со страшной скоростью, особенно по зиме.
Но с обменом с «внешним миром» никогда никаких проблем с ними не было. Есть свой протокол обмена — закрытый, но библиотеки с его реализацией бесплатные. А по Ethernet большинство их ПЛК умеют ModBUS TCP.
Но с обменом с «внешним миром» никогда никаких проблем с ними не было. Есть свой протокол обмена — закрытый, но библиотеки с его реализацией бесплатные. А по Ethernet большинство их ПЛК умеют ModBUS TCP.
0
Ничего адского в Unitronics нет — как, впрочем, и выдающегося :)
Дешёвый он. Вот, пожалуй, главный плюс.
Дешёвый он. Вот, пожалуй, главный плюс.
0
Хотелось бы заметить, что под понятием Fieldbus скрывается еще отдельная, весьма занятная, шина, которую там любит Yokogawa. Fieldbus Foundation
Правда реализация иногда доводит КИП-арей до истерики. Особенно когда сеть кусками отваливается часов на 12. А все го лишь устройство рядовое в сегменте вырубилось.
Правда реализация иногда доводит КИП-арей до истерики. Особенно когда сеть кусками отваливается часов на 12. А все го лишь устройство рядовое в сегменте вырубилось.
+1
Под Fieldbus подрузамевается гораздо больше шин, например любимчики Сименса PROFIBUS и PROFINET. У Йокогавы, кстати, тоже есть PROFIBUS IO модули, у нас вроде стабильно работают.
0
Разновидностей filedbus-а очень много, я привел просто несколько примеров. Тот же CAN, например — это просто описание физического интерфейса, уровень 1 модели OSI. А поверх него существует множество протоколов обмена, например широко распространен CANOpen, у бехоффа есть ADS over CAN, и т.д. И есть не только «медные» шины, есть и оптика, например, LightBus.
А насчет «отвалов кусками» — большинство этих шин как физическую среду используют витую пару, толстую и с мощным экраном. И там очень критично выполнение требований заземления этого экрана, лотка, где этот кабель лежит, и т.д. Где-нибудь отошла земля — и вуаля, получите перемежающиеся сбои, которые очень трудно выловить. У шнайдер-электрик есть хорошее пособие по организации сетей RS-485 ModBUS — почти все сказанное там применимо и к другим промышленным шинам.
А насчет «отвалов кусками» — большинство этих шин как физическую среду используют витую пару, толстую и с мощным экраном. И там очень критично выполнение требований заземления этого экрана, лотка, где этот кабель лежит, и т.д. Где-нибудь отошла земля — и вуаля, получите перемежающиеся сбои, которые очень трудно выловить. У шнайдер-электрик есть хорошее пособие по организации сетей RS-485 ModBUS — почти все сказанное там применимо и к другим промышленным шинам.
+1
Only those users with full accounts are able to leave comments. Log in, please.
ПЛК — что это такое?