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

Первоначально опубликовано KST Первоначально опубликовано Sergey Sorokin Первоначально опубликовано KST Речь идет о управлении ферросплавной печью, 200 точек на период, 12 каналов (не считая дискретных вх/вых)......  Получается, что нужно обрабатывать примерно 10 килоотсчетов/сек на канал, то есть всего примерно 120 килоотсчетов в секунду...... В наст. время  раз в секунду производится опрос всех входов - при этом считываются непрерывные значения синусоид ( или точнее того, что от нее осталось)  примерно 2.5 периода. Мат. обработка - плавающая точка, сглаживание - скользящее среднее, визулизация - на том же PC где и измеряются значения - на пульту плавильщика.  Давно назрел вопрос: как облегчить труд программиста, да вот что-то большая часть диалектов МЭК (или их реализаций) не кажется подходящей.

В такой постановке задача конечно проще. Проблема в том что управление и визуализация у Вас смешаны на одном компьютере. То есть при использовании языков МЭК визуализацию все равно придется писать самостоятельно.

С Уважением

 

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

evgen:

Какие-то у вас пчелы неправильные
на P2-350 миллион раз выполняется за 0.256
секунды или 256нс.



Спасибо за поправку... не миллион, конечно,
а миллиард... пишу девять нулей, а называю
это миллионом.. :-) Но в остальном все,
как и говорилось, - 90 нс на операцию взятия
корня из переменной равной 2.0.

что-то типа того:
long i;
float data;

data = 2.0;

for (i = 0; i < 1000000000; i++) {
    sqrt(data);
}



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

Еще раз спасибо за поправку.

Сергей Сорокин:
Я это лично наблюдал на сессии МЭК всвязи
со стандартом 61158 по филдбасам, но это не
значит, что каждый стандарт – это чье то оружие
в конкурентной борьбе. По крайней мере в МЭК
такая ситуация скорее исключение чем
правило.

Осмелюсь предположить, что Вы просто явились
свидетелем жарких дискуссий... Между тем, то, о
чем я говорю, не обязательно предполагает
ОСТРЫЕ "разборки"... Полистайте статью, гарантирую,
она Вам будет интересна.

Сергей Сорокин:
Я перевел абзац частично что бы подчеркнуть, что не программы
переходят на другой брэнд, а пользователи. Слово
exchange - это все таки не переносимость. Написано, что
«пользователи... могут обменивать приложения с
минимальными усилиями». Слов типа interoperability
и platform я не заметил. То есть PLCOpen ставил перед собой
вполне земные задачи – что бы программист использовавший
систему проектирования Сименс, мог легко перейти
на систему проектирования скажем ABB. На первом этапе
нужно было хотя бы договориться об общих «правилах
языкознания» (синтаксис, семантика и т.п.). С текстовыми
языками особых проблем по переносу обычно не
возникает К вопросам же переносимости проектов включая
графические языки на уровне единого формата
импорта/экспорта проектных данных, реально подбираются
только сейчас.

В данном контексте exchange воспринимается, в частности,
и как "переносимость"...

А самое главное то, что вся инновационная
деятельность PLC Open крутится вокруг проблемы
переносимости... а вместо слов "interoperability и
platform" поищите слова "portability" и "reusability"...
которых нет в стандарте, но которые в обилии встречаются на
сайте PLCopen... даже сейчас, после пяти лет "поумнения".

И, по моим ощущениям, "поумнение" PLC Open все-таки
ощущается, т.к., на мой взгляд, разговоров о
переносимости стало все-таки меньше, чем пять
лет назад... :-)

К счастью у меня сохранились документы PLCopen
того времени. По этим документам я вижу, что
пять лет назад они много болтали о
FxF (File eXchange Format)... им занимался
TC3-TF FxF... цель - "Portability Level
SFC, FBD and LD"... а сейчас об этом ничего
не слышно... да и сам технический комитет №3,
по-видимому, издох...

Так что, увы, должен Вас огорчить, факты говорят о том,
что процесс прямо противоположный:
работы по переносимости скорее сворачиваются, чем
разворачиваются... (могу отсканировать док и отправить
любому желающему)

Сергей Сорокин:
Вы кстати можете как частное лицо
вступить в PLCOpen и принять участие в решении
проблем переносимости.

Сергей, я это знаю, но мне не интересен ни IEC 61131-3,
ни PLCopen, т.к. ПО на базе языков стандарта (в силу
убогости этих языков) не позволяет решать
задач, которые мне приходится сталкиваться в жизни.
И это хроническое состояние стандарта, которое
невозможно исправить интеллектуальными и материальными
затратами на CASE-оболочки и прочие WIMP-интерфейсы.

Хотя опять же подчеркиваю, для каких-то задач и условий
использование этих языков может оказаться экономически
оправданным.

Сергей Сорокин:
Я думаю Ваша статья висит в рамочке над рабочим
столом у всех членов PLCOpen J

Не уверен. Они же не знают русского... :-)
Но все положения, освещенные в статье прошли
апробацию в конференции control.com... список
участников обсуждения вопросов, затронутых в статье,
и людей, давших ценную информацию, приведены в конце
статьи. Среди них и члены PLCopen и члены
стандартизующих организаций, и представители CJ
International... а многие и просто не указаны...
а это и представители Сименс, и просто рядовые
пользователи, и, несомненно, представители
ведущих компаний, которые просто не пожелали
публично заявлять о своем присутствии...

Дискуссия была достаточно горячей, поэтому,
уверен, что основные положения статьи
известны в PLCopen и так или иначе повлияли на
PLCopen сообщество.

= ОБ ФУНКЦИИ SQRT и UL =

Добавление:

Сергей, "кстати" или "не кстати" не знаю,
но в моем Борланде стоят следующие настройки

Floating point -> Emulation,
Instruction set -> 8088/8086...

так что, похоже, нам все же не повезло,
и установкой нужного флажка в UL дело не
поправить... :-(

evgen:
Попадание в кэш для плавучки все-таки не так
актуально, как для обычных операций, а вот громадная
разница в производительности для 16 битного и 32
битного кода в свое время меня просто убила.

Вы говорите весьма интересные вещи...
Я правильно понимаю, что 32-разрядный код
намного медленнее, чем 16-ти разрядный?