|
|
Соцопрос: языки МЭК 61131-3. |
Я думал речь идет о доработке стандарта МЭК1131-3, а не о CoDeSys.
Можно поступить по другому: В цикле вызывать один экземпляр функционального блока, подавая на его входы разные параметры. Единственное - такой блок не должен иметь внутренних переменных, которые надо сохранять на следующий цикл сканирования (их надо выносить во внешние переменные).
В Concept есть такое, только такие блоки на Си писать надо. |
|||
 |
|||
|
я пишу на ST всегда, на LD когда надо модернизировать оборудование с релейной схемой, тогда просто перерисовываешь схему (в общем для чего ЛД когда то и придумали, наверно) |
|||
|
|||
|
кстати, а хде можно почитать про МЭК61131-3, именно про стандарт, а то говорят что разные среды разработки отличаются
|
|||
|
|||
|
|||
|
Возможно зря поднимаю тему, но прошло 2 года, интересно, что изменилось, приблизили ли мы языки высокого уровня к ПЛК или нет? Опубликовал статью: Языки программирования ПЛК. Какой выбрать?, считаю вопрос значимым для подрастающей армии специалистов и тех кто их обучает.
|
|||
|
Интересы: Контроллеры, привода и ЧПУ для АСУТП, помощь в пусконаладке, ремонте и модернизации. Бесплатно)
|
|||
|
|||
|
Я пытался тему по программированию ПЛК развить здесь.
Но не поддержали. Может на форум СТА перенести? |
|||
|
|||
|
Что еще сказать ?.. да всегда можно найти.
К примеру, ".. что можно выжать из железа с помощью языка программирования ? .." Можно - конвейерная обработка, которая щас во всех чипах, ускоряет во много раз. Но это при условии отсутствия ветвлений т.е. условных операторов (УО). А УО нет как раз в древних LD и его текстовом выражении - "булевке". В то время, как ST - сплошные УО. Вот и выходит, что не всё старое - плохо, а всё новое - хорошо .. С уважением, SAN |
|||
|
|||
|
Тема интересная. Я активно обсуждал ее в этом году с разными компаниями и людьми. Пожалуй наиболее содержательно с Эльке ванн дер Валом из PLCopen. Мнения разные, хотя можно выделить некие общие точки, от практики до идей.
ИМХО 1: вариант функциональных блоков в стандарте МЭК 1499. Неплохое усовершенствование, но не стратегическое. Разработчики ПЛК не спешат его реализовывать, работают над своими оригинальными идеями, которые позволят им прыгнуть вперед конкурентов на несколько лет. ИМХО 2: есть абсолютно явная тяга молодежи к языкам ООП во всем мире. Никуда мы от этого не денемся, хотим или нет. Но. . ., в лоб компьютерные языки Java, C# и др. в ПЛК лезут очень криво. Не смотря на всю их мощь, в них не хватает самых элементарных и необходимых для ПЛК систем штук – механизма отображения аппаратуры ввода/вывода, настройки порядка и временных характеристик этих механизмов, средств отладки и диагностики всего оборудования в целом, интегрированных средств моделирования и др. и пр. Что говорить, если программа в ПЛК написана на C++, то наладчик не может даже элементарно заморозить выходы ПЛК и подвигать вручную определенными механизмами без привлечения программиста. В любой, самой затрапезной МЭК 61131-3 среде этому можно научить даже бухгалтера. Второй момент: нельзя наплевать на огромное число существующего ПО для ПЛК. Нельзя наплевать на людей, которые владеют этим в совершенстве. Есть ‘старики’ которые разбуженные ночью по отрывочным словам и наименованиям неких приборов могут сказать что это, как его настроить, как запрограммировать, почему не работает, как быть, что для этого нужно и в каком шкафу лежит. Без таких людей все встанет на продолжительное время. Но ООП им нужен как в бане солярка. Итого: надо втягивать ООП в традиционные языки программирования ПЛК опционально. В PLCopen такой проект ведется и очень похоже на то, что рождается стандарт. ИМХО3: языки МЭК позволяют запрограммировать решение, но не дают ничего для поиска этого решения и не дают технологию разработки. Отсюда вытекают разработки принципиально новых подходов к программированию ПЛК. Например, на базе UML. Идея состоит в построении модели, ее отладке и автоматической генерации кода. Такие научные разработки ведут все серьезные фирмы в Европе и США в сотрудничестве с университетами. В большей части это перспективные проекты, которые показывают дистрибуторам, партнерам, но публикуют информацию очень сдержанно. К 12 году наверняка что-либо родится в коммерческие продукты. Тогда будем обсуждать, ругать, пытаться стандартизировать. |
|||
|
Igor Petrov
|
|||
|
|||
|
Поддержу обсуждаемую тему, вставлю свои пять копеек.
Какие языки МЭК я использую? Стандарт МЭК не только поддерживает, но и поощряет многоязыковое программирование. Связано это с тем, что большая часть языков в нем является проблемно-ориентированными. То есть, разные задачи, и более того, разные части одного приложения удобнее решать на разных языках. Чем я активно и с удовольствием пользуюсь. Для дискретной логики пока не придумали ничего более удобного и наглядного, чем LD. Поскольку эта задача встречается, пожалуй, чаще всего, то я использую LD, наверно, в половине случаев. Однако попытка реализовать на LD более-менее сложный алгоритм может поставить в тупик. Поэтому одного только LD мне недостаточно. В FBD очень наглядно реализована инкапсуляция алгоритмов. Поэтому он идеально подходит для декомпозиции задачи на отдельные блоки. Если сделать это грамотно, то программа будет выглядеть очень наглядно. Поэтому я часто использую FBD (или его развитие CFC), например, для реализации основного POU проекта. ST - обычный алгоритмический язык высокого уровня, на нем в принципе можно реализовать любую задачу. Он незаменим для вычислительных алгоритмов, различных протоколов обмена, да и вообще для любых нетипичных для ПЛК задач. А такие задачи сейчас встречаются часто. Однако злоупотребление применением ST, а в особенности, перенос на него практики программирования на C, ведут к появлению программ, которые невозможно поддерживать. Я часто применяю ST для написания "начинки" функциональных блоков. Теоретически, SFC - очень мощный инструмент, позволяющий повысить наглядность и облегчить написание алгоритмов. На практике, попытки применения SFC приводят либо к тривиальным алгоритмам, где ясно видна его избыточность для данной задачи, либо к ужасающей путанице и большим трудностям в отладке. Поэтому я стараюсь не применять SFC. IL - наименее наглядный из МЭК языков, введенный в стандарт, очевидно, в целях совместимости. На практике я не вижу никакой необходимости им пользоваться. Впрочем, у меня был один случай, где я применил его: я написал скрипт на VBA, который генерировал код на IL с большим количеством однотипных действий автоматически. Некоторые системы позволяют комбинировать код на FBD и LD вместе, благодаря чему можно добиться большей наглядности и компактности. Если такая возможность есть, я ей обязательно пользуюсь. |
|||
|
Инженер-системотехник
+7 (916) 477 3925 |
|||
|
|||
|
Цитата 3-х летней давности !
Не надо смешивать языки - их надо соединять ! С уважением, SAN |
|||
|
|||
Ответить 
|
Страница <1 789 |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
