Соцопрос: языки МЭК 61131-3.

Первоначально опубликовано _IP_   Давайте креативно обсуждать недостатки МЭК языков. Сейчас удачный момент, вполне можем добавить то, чего в нем не достает. Есть идеи?

Такссс.

1. В CoDeSys v2xx в CFC неудобно таскать блоки, т.к. область выделения бывает очень маленькой. Хорошо бы чтобы можно было хватать и перетаскивать за все пространство блока (а редактировать текстовые названий блока можно двойным нажатем мышки или долгим нажатием).

2. Было бы не плохо просто перетаскивать блоки и функции из левого меню (POUs) мышкой на рабочее поле (CFC и др.).

3. Двойным нажатие на функциональный блок в CFC-диаграмме открывать (по возможности, например созданный в этом проекте пользователем) структуру соответствующего блока.

4. Например в LabVIEW проводки подсвечиваются в соответствии с типом данных (bool - зеленым, int/byte... - синим, real - оранжемым и др.) в CFC тоже можно было бы такое сделать :)

Первоначально опубликовано Chupakabra2 1. В CoDeSys v2xx в CFC неудобно...

OK. Спасибо! Однако... Эти пожелания относятся исключительно к CoDeSys. Цветовыделение,  интерактивные подсказки типов в текстовых языках, указание парных скобок, свертывание тела циклов и др. и пр. добавлены в V3.

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

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

Нужно ли такое?

Первоначально опубликовано globus ...использовать внешний код приходилось исключительно в случаях работы с железом...

Терзает меня смутное сомнение, что Си или ассемблерную вставку приходится пихать в том случае, когда железо выбрано не совсем оптимально. В результате приходится выжимать из него то, на что оно не было заточено разработчиком. Конечно, наши инженеры именно в этом и мастера (не от хорошей жизни).   Наш человек может на AVR слепить штуку, куда немец поставит Пень5, но…  Если бы ПЛК были более стандартизованы, совместимы и взаимозаменяемыми, то во многих случаях можно было бы не мыкаться, а заменить ПЛК на тот, в котором сразу есть нужная функциональность. 

 

_IP_ : .. что в Си есть такого чего нет в МЭК языках ...

Один конкретный пример,  API-функция сброса сетевых сокетов - WSACleanUp(). Эта функция не "экзотика", а постоянно используется системными программистами в профессиональных приложениях. Она позволяет самостоятельно восстановить и переинициализировать сокетное соединение, что особенно важно для необслуживаемых систем.
Подобных системных функций требуется немного (у каждой платформы свои). Но дело не в количестве, а в ключевой роли этих функций. Именно они делают из демо-примера программу промышленного уровня.

Скажите,"чистый" МЭК-язык обеспечит мне этот уровень ? Кубиками  .. if .. else, .. for ..  можно играться на любом языке. А нужны не игральные кубики, а среда разработки промышленных систем.

Еще раз хочу сказать - в МЭК-языки ничего постороннего внедрять не надо, их можно бесконечно улучшать в своем качестве. Они выполняют свою роль, и работают на своем уровне абстракции оборудования. А иметь возможность стыковаться с модулями из других областей : будь-то базы данных, XML-скрипты, средства визуализации и многое т.д. - обязательно !

С (большим) уважением, SAN

Первоначально опубликовано _IP_  Т.е. получается, что в контроллере может быть несколько МЭК приложений, каждое использует свои входы/выходы и практически независимо – можно останавливать, перезагружать, отлаживать одно приложение, в то время как прочие продолжают спокойно работать.

Идея в общем неплохая. Только сможете ли вы  тогда гарантировать неизменность времени выполнения программ?

Первоначально опубликовано _IP_ Нужно ли такое?

Время покажет!

Первоначально опубликовано _IP_ Терзает меня смутное сомнение, что Си или ассемблерную вставку приходится пихать в том случае, когда железо выбрано не совсем оптимально. В результате приходится выжимать из него то, на что оно не было заточено разработчиком. Конечно, наши инженеры именно в этом и мастера (не от хорошей жизни).   Наш человек может на AVR слепить штуку, куда немец поставит Пень5, но…

Бывало и такое. Дело же ведь не только в железе но и в софте.

Первоначально опубликовано _IP_ Если бы ПЛК были более стандартизованы, совместимы и взаимозаменяемыми, то во многих случаях можно было бы не мыкаться, а заменить ПЛК на тот, в котором сразу есть нужная функциональность.

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

Первоначально опубликовано Leonid Uretsky ...Написал функцию на Си, на вход которой подается структура с адресами массивов. А функция по этим адресам уже находит необходимое значение параметра....не хватает в МЭК 61131-3 работы с указателями на переменные.

В CoDeSys есть указатели на переменные  (на функции нет). Кроме того, можно делать массив функциональных блоков! Через конфигурационные переменные можно подставить каждому экземпляру свои данные. Это мало кто использует, хотя получается очень красиво. (См. последний ответ тут). Еще в МЭК функция может возвращать структуру. В Си этого нет.

Еще интересная новая идея делать функции с параметрами типа ANY (любой). Некоторые стандартные МЭК блоки (например, сложение) кушают любой тип данных, но сделать из них свою столь же всеядную функцию нельзя. Конечно, это здорово усложнит транслятор системы программирования. Пока такого ни у кого нет (скоро будет в CoDeSys V3).

Первоначально опубликовано globus ...Только сможете ли вы  тогда гарантировать неизменность времени выполнения программ?

А в чем проблема? Во многих ПЛК сейчас сидит ОС РВ и циклические МЭК задачи вызываются с точностью до микросекунд. Задача с высшим приоритетом прерывает низкоприоритетные.

Первоначально опубликовано globus ...Батенька, это вы против буржуазии попрете! Любая контора заинтересована подсадить вас целиком и полностью на их железо.

А как же PC? Море изготовителей делают совместимое оборудование и все счастливы