Free FBD or IEC1131

Пункт меню "Online/Simulation Mode". Затем "Online/Login". Ну и далее - либо по шагам, либо с точками останова...

Нет, такого пути нет. А зачем? Ведь формат проекта КоДеСиса теперь - фактически стандарт для всех языков программирования, которые используют компании, вошедшие в "Automation Aliance".

Или есть какой-то другой смысл в Вашем вопросе?

С уважением,

Откомпилированный без ошибок CoDeSys проект можно экспортировать в текст. Меню Project->Export.., выберете компоненты, которые нужно экспортировать и получите файл *.exp

Это нужно в двух случаях:

1. Automation Aliance объединяет изготовителей аппаратуры использующих CoDeSys, их более 120. Это не мало. Но,  и других хороших пакетов МЭК программирования около десятка. При экспорте и импорте проектов подобный файл бывает единственным спасением. К сожалению, разговоры о едином переносимом формате идут уже 13 лет, но сейчас все системы МЭК программирования имеют абсолютно разные форматы.

2. Грамотные заказчики АСУ ТП требуют полный комплект печатной документации, включая прикладные программы. При утрате файла проекта, его можно восстановить руками с листа.

1. Перенести С текст действительно проще. Но только текст. Также как и МЭК системах, файл проекта Borland C Вы не сможете перенести в Keil C.

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

 3. Практически все С компиляторы имеют много разных нестандартных расширений. Очень разные бывают команды препроцессора. Перенос текста под другой компилятор пройдет легко, только если программист заранее учитывает такую необходимость.

В МЭК среде программист практически изолирован от аппаратного уровня стандартным образом.  Из большинства фирменных систем программирования ПЛК в универсальные МЭК пакеты (Step 7 – отдельная тема) прикладная программа переносится ты путем перенастройки конфигурации и корректировкой специализированных библиотек.

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

То что в МЭК входит 5 языков не означает необходимость использовать их в одном проекте. Обычно опытные С программисты в МЭК используют SFC в задачах и ST для описания всех POU. Перенос таких программ куда угодно не составляет сложности.

Как и в большинстве других систем, в CoDeSys есть средство конвертирования POU с одного языка на другой. Наиболее «стандартен» в разных МЭК пакетах язык IL, используйте IL тексты при переносе.

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

Сейчас мы используем МЭК среду даже для разработки специализированных встроенных контроллеров. Опытный образец выполняется на универсальном ПЛК отлаживается в CoDeSys на ST. Исключительно удобны встроенные средства визуализации и графической трассировки.

Когда становится понятно что изделие реально пойдет в серию, готовое ПО переписывается в С, оптимизируется, ужимается в «однодолларовый» микроконтроллер.

На мой взгляд, более желательно иметь простую возможность переносить хороший МЭК инструмент под любой процессор, в любой ПЛК, чем приспосабливать прикладную программу под разные компиляторы. Собственно Automation Aliance и дает такую возможность.

Реализация МЭК системы может быть следующей:

1. Прямая компиляция всего проекта в код конкретного процессора. Это дает наиболее быстрый код, очень простая и компактная система исполнения, миним. возможности всяких посторонних «глюков».
2. Компиляция в промежуточный псевдокод – некий универсальный простой ассемблер. Система исполнения должна включать интерпретатор псевдокода, но он простой и легко переносится, есть возможность «скачать» программу из ПЛК обратно, легко реализуется пошаговая отладка.
3. Все транслируется в IL. В ПЛК сидит интерпретатор IL, смысл тот же, но удобнее, можно сделать автономный компактный пульт программирования в ПЛК.
4. Трансляция в C. Язык C используется в проекте наравне с МЭК. Теоретически здорово. Реально генерируется текст для конкретного компилятора. В любой существенно иной платформе нужно слегка править полученный С или написать свой препроцессор. Была такая возможность в CoDeSys и ISAGRAF. Сложностей больше чем плюсов. Посмотрите пакет SoftCONTROL (Softing GmbH), там этот метод реализован вполне технично www.softing.com.

Осенью здесь обсуждалась тема (53 страницы!) «Средство для программирования контроллера: Си или МЭК 61131?». http://forum.cta.ru/forum_posts.asp?TID=109&KW=%EB%E8%F2%E5%F0%E0%F2%F3%F0%E0

Там присутствуют весьма взвешенные высказывания С. Сорокина. Я здесь с ним  вполне согласен, поэтому не буду развивать глубже эту тему.

Я имел в виду реализацию трансляторов полных МЭК пакетов, не только FBD. Набор готовых кодов библиотечных функциональных блоков в памяти контроллера и их вызов из прикладной программы это и есть интерпретатор промежуточного кода. Даже в классическом Бейсике базовые операторы сшиваются из кода. Работает действительно быстро если не пытаться делать свои сложные алгоритмы в FBD. Либо их нужно делать на других языках.

Все современные инструменты МЭК программирования начинались с поддержки только LD или только FBD. Далее они выросли. Например, даже TM6 уже поддерживает все 5 языков.