Средство для программирования контроллера: Си или МЭК 61131?

Нет ответа ни на один вопрос а только амбициозные защиты своей точки зрения вот что я вижу. Огульная критика есть и непонимания гибкости С++, как раз я в С++, сам все расперделяю небуду повторятся я ужу об этом говорил. ПО мы покупаем, со стоимостью проектов это мелоч. И я говорю о С++ ка о языке программирования контроллеров, а ПО для центральных компьютеров ЧАЩЕ всего пишу на VB-6. Бысрей проект можно сделать нанем, да и многопоточность его устраивает. Но это уже не принципиально.

А насчет Modbus, тут я совсем не понял что вы сказали, внимательно надочитать, если хотите отвечать. Я привел пример заложенного в устройсво со слабым каналом протокола, который я немогу переписать в ответ на ваше замечание: "Ведь обычно нужно решить задачу за довольно сжатый срок и если скажем поставщик контроллеров уже позаботился о том, как образ процесса из контроллера будет передаваться в host-компьютер по сети Profibus, то зачем тратить время на повторное решение этой же проблемы и ковыряться с прерываниями." Я хочу сам во многих случаях определять протокол обмена с контролером. А Modbus, мы его иногда используем по Ethernet, а на RS-485 и с 19200  плюс куча устройств которые все равно будудт ждать своей очереди он не очень эфективен для нас.  Я привел пример эфективноти и не спрашивал решения, решение естественно в каждом конкретном случае находится свое.

 

1) Обмен с 15 распределенными модулями УСО по RS485 (протокол I7000 или АДАМ4000)

2) Десять контуров ПИД-регулирования.

3) 5 блоков управления моторами.

4) На верхний уровень данные передается по Ethernet (протокол на выбор).

Например, с использованием МЭК и штатных средств SoftLogic+SCADA на эту задачу уйдет максимум 1 день одного инженера АТП (даже не владеющего языками высокого уровня типа Си)...

А сколько у Вас уйдет времени, чтобы все это реализовать и отладить на Си++?

Сами должны понимать это не тех задание, определить не могу, что вы сними делайте, что выводите на верхний уровень и какая, скорость реакции всей системы на события и т.д.. Даже моторами можно управлять по разному, включать выключать, регулировать скорость и так же для этого применять ПИД. И пока идет монтаж железа, перечисленного вами достаточно времени будет для письма.  Даже простой проект естественно за день и на С++ не сделаешь, да и плохо делать системы за день на любом языке. Из опыта скажу не оптимально получается. Надо оставить после написание проект пусть дня на два на три и потом сябя покритиковать. Насчет вашей задачи скажу что такое количество оборудования это ниже среднего наших проектов, я говорю о железе и о контурах регулирования. Все программы, железо надо рассматривать в комплексе выбирая оптимальную конструкцию.

Пользователям нет необходимости лезть в софт корректировать его, а хорошему программисту не сотавит труда написать на С++ любую программу обслуживания системы. Кстати сроки у нас тоже очень сжатые.

 

Первоначально опубликовано KST .......Что имеется в виду под «вялой»? Не знаю как в Ultralogik, но в типовом контроллере действительно время цикла менее 1 мсек обеспечить сложно. Однако число задач, где нужен более короткий цикл очень невелико.   Приветствую Форум! "Число задач с коротким циклом очень невелико" - любимая отговорка производителей готового продукта. А как быть если только и приходиться, что считывать  значения sin промышленной частоты  по нескольким каналам?

Так ведь действительно число таких задач невелико.

В вашем случае речь наверное идет о системах энергоучета. В этом случае используются специализированные контроллеры, так как нужно мерить обычно до 40 точек на период промышленной частоты, причем мерить по нескольким фазам и не только напряжение, но и ток. Типовые контроллеры для таких задач не подходят.

Специализированные системы по энергоучету и контролю за качеством электроэнергии можно посмотреть на www.prosoft.ural.ru.

С уважением

Сергей Сорокин

 

Здравствуйте!

мне тут сказали добрые люди, что кто-то обвиняет меня в том, что
я чего-то не понимаю...

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

Сергей Сорокин по поводу статьи
"К пятилетию стандарта МЭК1131-3: итоги и прогнозы"
писал:

"автор не совсем правильно понимает цели и задачи таких
организаций как PLC Open и IEC, а
действительные или мнимые недостатки конкретного
продукта ISaGRAF почему то распространяются на сам
стандарт IEC-1131-3 (сейчас он
имеет номер IEC-61131-3). Основная же причина
недовольства автора стандартом лежит в том, что он
рассматривает стандарт «с точки зрения
хорошего инженеринга», забывая что стандарт это не
результат инженерного проекта по разработке языков
программирования."

Кратко резюмируя статью скажу, что основная
мысль в статье была такая:

IEC создал стандарт, который кроме того, что с точки
зрения хорошего инжиниринга весьма слаб, еще и для
целей PLC Open не подходит абсолютно.

В МЭКе решались (скорее всего) задачи защиты
мега-корпораций (см. список участников) посредством
стандартизации. PLC Open декларирует построение
"открытых" систем на базе МЭК 61131-3, а по сути
разрабатывает некий параллельный стандарт. И, что самое
забавное, и пять лет назад и сейчас ОЧЕВИДНО, что
такой стандарт эволюционными методами разработать
невозможно - а это и был основной прогноз статьи.

Будьте добры, Сергей, поясните, что в этом утверждении
неверно.

(Про Си/не Си, LD, FBD можно поговорить отдельно,
т.к. это достаточно второстепенные вещи, хотя и
несомненно интересные).

Первоначально опубликовано KST Речь идет о управлении ферросплавной печью, 200 точек на период, 12 каналов (не считая дискретныз вх/вых).  <SPAN style="FONT-FAMILY: 'Times New Roman Cyr'">Ultralogik и еже с ним не подходят - вот и получается, что кроме С (или др. языка высокого уровня) и применить нечего.</SPAN> <FONT color=black size=6>  <!-- Message ''"" -->

В ISaGRAF нельзя выставить время цикла меньше одной миллисекунды. Но можно поставить реальное время т.е. как успеет -- зависит от "тяжести" задачи и мощности контроллера.

Если ISaGRAF работает в ОСРВ то можно наплодить насколько ресурсов -- это параллельные задачи у каждой из которых своё время цикла.
В DOS будет крутиться только один ресурс.

http://www.fiord.com

"Что же касается приведеной статьи, то мне
совершенно непонятна цель, которую приследовал
её автор. Явно не разобравшись в сути вопроса,
на основании всем известных и хорошо документированных
фактов и собственных заведомо ложных представлений он
пытается с помощью весьма спорных рассуждений
прийти к выводу о неэффективности и нежизнеспособности
стандарта IEC-61131, входящих в него языков, да и
программируемых логических контроллеров вообще.
Интересно, зачем?"

Отвечаю. Цель статьи была сгладить возможный пик
эйфории от рекламной кампании по раскручиванию
МЭК 61131-3... сделать так, чтобы русскоязычный
пользователь прежде, чем выложить килобаксы за
какой-нибудь продукт на базе стандарта МЭК 61131-3,
семь раз подумал...

"Не вижу смысла вдаваться в подробную критику, скажу
только, что человек, понимающий, для чего нужны
контроллеры, языки их программирования и стандарт
на эти языки, легко проследит все ложные положения
статьи и сделанные на их основании неверные выводы.
Да и время, в общем-то (а статье уже пять лет), уже
показало, что автор, мягко говоря, заблуждается."

Опять "заблуждается". Ну елу-палы.. :-)

Напомню, что в конце статьи ясно сказано, что
возможно два варианта развития событий: 1. PLC Open
при попытке достичь своих декларированных целей
развалится. 2. Декларированные цели достигаться
не будут, а будет выбран путь "революционных улучшений".

При этом для пользователя предпочтителен первый вариант
развития событий, а для производителей - второй, более
вероятный. Ну идет все по второму пути и идет...

Слезно прошу, читайте внимательнее статью.