где бы найти efb toolkit ?

А что такое efb toolkit ? Что-то я ни разу не сталкивался пока с ним...

А откуда взялся ST, из какой системы программирования ? И этот ST как будет выполняться - в режиме интерпретации, да? А нормальный C компилится. Хотя - если устраивает быстродействие ST в выбранной системе программирования - какая разница, что использовать?

Демо-версии EFB-Toolkit нет. Купить можно у Шнейдер - он стоит намного дешевле самого Concept`a.

P.S. Это не ты "eltsin" на форуме www.modicon.com?

Мы делаем проекты под Modicon TSX Quantum с Hot Standby с большим объемом сигналов и технологического оборудования. В первых проетах мы использовали в основном FBD, внутренности функциональных блоков писали на ST или IL. Такие проеты еле-еле вмещалисьв в память контроллера 140 CPU 434 12A. В резервный контроллер передавалась куча данных, скан был длиной до 250 мс.

Теперь мы стали использовать ST, в цикле вызываются блоки на том же ST или IL. К тому же некоторые вещи переписали на Си (с помощью EFB-Toolkit). На Си написаны такие блоки, которые МЭК-языки сделать не позволяют. Теперь памяти свободной чуть ли не 50%, скан 130 мс, куча резервных каналов осталась. К тому же один и тот же проект на разные объекты теперь можно ставить практически не переделывая.

Сейчас делаем новую разработку под Modicon TSX Compact - я изначально на EFB-Toolkit ориентируюсь. В самой программе будет несколько блоков, внутренности которых написаны на Си.

В принципе МЭК-языки тоже нужны. Дело в том, что разработчик ПО пишет функциональные блоки на Си. А "пользователь" (программист, обслуживающий систему) внутрь этих блоков не заглядывает. Он может легко добавить - удалить сигнал, или технологический объект управления из среды МЭК. Это можно сделать не перегружая программу в контроллере, что важно для АСУ непрерывных процессов.

Под "Пользователем" можно понимать разное. Конечно, оператору вовсе необязательно знать, как написана программа - на Си, на МЭК-языках или еще на чем-то. Но в отделе АСУ ТП заказчика работают программисты, которым надо систему обслуживать. Невозможно ведь разработчикам постоянно ездить на объекты, которых может быть не один десяток, и разбросаны они по всей России, для добавления нескольких сигналов и сообщений по ним!

В нашей автоматике процедура наращивания количества сигналов и ТОУ простая, думаю, на Си это было бы сделать сложнее.

Я за такой подход - основные алгоритмы зашиваются в функциональные блоки (в Concept их можно писать на Си или МЭК-языках, на Си все же лучше, но сложнее), сама программа несет минимальный код, состоит из этих блоков. А программисты заказчика, меняя только переменные, могут перенастраивать систему, добавлять сигналы и ТОУ. В тект самой программы им даже нет смысла лазать!