[Evgeny_CD 0]

Evgeny_CD, спасибо почитаю. Если найду, что можно добавить новый цикл (с новыми элементами управления, пусть по таймеру) - все мои сомнения разрешатся.

Я не возьмусь Вас консультировать - но то, что такое туда добавляется - у меня сомнений нет!

[SM 0]

Но не забываем мы никогда классические решения задач. Может кто-то и забывает, но это их проблемы И не называйте это языками программирования - это языки описания аппаратуры (HDL).

Молодежь на этом форуме забывает... А название - тоже из раздела форума заимствовала.. Все таки какая то реальность бытия здесь отражена :)

Она, молодежь, не забывает. Она еще не знает :) Это стандартно для тех, кто все время работал с МК, решил поработать с ПЛИС.

[Andrew2000 0]

Маленькие замечания.

 

ISaGRAF - интерпретатор.

Других интерпретаторов не знаю. CoDeSys, OpenPCS - компиляторы (т.е. так называемая целевая/управляющая система там присутствует, но пользовательский код (МЭК языки) компилируется).

 

ISaGRAF-у ОС, собственно, и не нужна, ему нужен аппаратный таймер, по которому он будет следить за временем выполнения такта: ввод-обработка-вывод - wait, если быстро, ошибка, если переполнение такта - вот и все реальное время ...

А вот когда появляется задача связи (по Ethernet, например), то тут удобнее ОС: 1 задача - задача связи, вторая задача - интерпретатор TIC-кода (хотя, никто не мешает организовать связь на прерываниях).

 

Siemens STEP7 - больше чем уверен, что компилятор. Новые Siemens PLC вообще построены на чипе Speed7 - http://www.speed7.com/ - спец. CPU заточенные под STEP7.

 

По поводу технологов - их язык FBD - т.е. функциональные блоки (LabView туда же).

Они так видят мир :) И не надо им мешать.

Еще в МЭК считаю полезным SFC.

А ST там для того, если поймают обычного программиста и скажут - пиши на МЭК языке - ему будет куда спрятаться (шутка).

 

Рефлекс, как я понял, это еще один вариант SFC+ST.

(поправьте, если я не прав)

 

Ну приведу еще один язык(пример), который любят наши технологи (тоже аналог SFC+ST):

прог ТАЙМЕР_1 выкл;

сит начало;

переход СЧЕТ;

конец;

сит СЧЕТ;

T_1 = 0; t_1 = 0;

м: t_1 +=1;

переход ДОБАВИТЬ_СЕК если t == 100, //

СЧЕТ.м;

конец;

сит ДОБАВИТЬ_СЕК;

T_1 += 1; t_1 = 0;

переход СЧЕТ.м;

конец;

конец;

 

А когда им предложили ISaGRAF - они отказались - по-русски писать нельзя :)

[Olej 0]

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

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

И в первом, и во втором варианте - специфика предметной области может быть отражена в базисных примитивах. Зачем? -> Упрощение процесса разработки для конкретной области задач за счет технологичности программирования (вместо ручной дрели - электрическая), опять же за счет технологичности - повышение качества ПО в среднем (не ориентируясь на оч.умелые ручки), может быть немного спорная мысль - повышение эффективности самой программы (по известным критериям быстродействия/памяти или даже соответствия требованиям жесткого РВ и другим условиям исходной предметной области). Может быть немного и загнула :)

 

Языки МЭК вызывают у меня ... какие-то смутные ощущения ;), не пойму пока:

 

1. в объяснение почему их 5 (да ещё ISaGRAF от себя 1 вводит, да ещё всё новые предлагаются, как здесь указывали...) я как-то в одном очень заслуживающем уважения месте вычитал примерно следующее: "... комитет долго спорил, чтоб не отдать предпочтение ни одному из уже установившихся поставщиков PLC в ущерб другим ... поэтому их 5 ..." - тут и задумаешься: мы хотим обсуждать высокотехнологическое средство, или кто, как, почём и больше продаст в рыночной стихии - тогда это мне совсем неинтересно.

 

2. кто их использует (здесь уже столкнулись с разночтениями в терминологии: технологи / программисты)? я перед собой ежедневно вижу парней, рисующих этими tools системы автоматики... и вот что я наблюдаю:

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

- заказчик всегда говорит: "с таким инструментом - мои эксплуатационщики всегда могут сесть и внести изменения в систему, подкорректировать её ... потом" - это полный бред: эксплуатационщик в принципе с таким инструментом, в силу его простоты, может "влезть" ... но единственным результатом такого влезания может быть только полное разрушение системы: исправляя в программе ошибку мы всегда вносим 3 новые, и бороться с этой прогрессией - нужно иметь навыки, и навыки эти - программистские.

- но назвать этих парней, "пишущих" на МЭК языках, программистами ... у меня как-то язык не поворачивается: они, обычно, не сильно задумываются, что такое IP-адрес, и очень удивляются, почему IP-адрес записывается как x.y.z.w, а Modbus-адрес - как x.y :(, я обычно этот персонал называю "проектанты" (чтоб каждую вещь хоть как-то называть - нельзя же их называть ни технологи ни программисты).

- начитавшись предисловий, что "... работа такая не требует высокой квалификации и можно привлекать персонал невысокой квалификации..." - наши администраторы хотя бы задумались (хоть вообще об чём-то думали, например, зачем и в чьих интересах такое пишется?): это в наших то условиях? когда хлопчика ещё не закончившего институт и бегающего на занятия между работами - можно нанять за $400, а самого профессионального программиста-"волкодава" - $800 (цифры условные ... региональные ;), но соотношение везде сохраняется).

 

Интересно! Я знала только про портации CodeSys. Конечно, IsaGRAF сразу был ориентирован на различные ОС, а вот без ОС - это в какой-то мере новость.

 

Вот это интересное место. Дело то в том, что в циклической алгоритмике управляющего АСУТП процесса: - ввод - обработка - вывод - , когда это принципиально однонитевой циклический процесс - вполне достаточно на все случаи жизни MS-DOS! И никаких особо специфических функций OS (RT или не RT) - особенно не нужно. До тех пор, пока не привносится каким-то образом параллелизм. Это в точности та же история, когда при работе над MS-DOS v.2 компашка Билли Г., в силу своей невежественности к тому времени, молодости и задора - напрочь исключили возможности параллелизмов из ОС (когда в более ранней и лучше CP/M этому уже уделялось внимание, и уже создавались первые версии QNX). А потом все годы "триумфального шествия" MS-DOS - это была борьба и успешные победы тех трудностей, которых нагородили с самого начала: print-spooler, мультиплексор INT 2F, TSR-программирование кто и во что горазд...

 

Я думаю, что успешная жизнь PLC (более 15 лет с ранних 90-х), когда в первоначальных моделях ничего управляющего более MS-DOS и быть не могло - определяется кажущейся сверхвысокой надёжностью и устойчивостью, обеспечиваемые, на самом деле, принципиально однонитевой цикличной природой вычислительного процесса АСУТП.

 

Вот здесь косвенно тоже это прозвучало:

 

ISaGRAF-у ОС, собственно, и не нужна, ему нужен аппаратный таймер, по которому он будет следить за временем выполнения такта: ввод-обработка-вывод - wait, если быстро, ошибка, если переполнение такта - вот и все реальное время ...

А вот когда появляется задача связи (по Ethernet, например), то тут удобнее ОС: 1 задача - задача связи, вторая задача - интерпретатор TIC-кода (хотя, никто не мешает организовать связь на прерываниях).

 

Да, 1 принципиально требующая параллельности ветвь - всегда появляется при требовании сетевых средств, или, если шире - любых асинхронных обменных процессов.

 

Но есть и другой скрытый механизм параллельности, и это гораздо серьёзнее... Когда рассматривают вот тот цикл работы АСУТП процесса: - ввод - обработка - вывод - часто неявно предполагается, что всё именно так и производится: по циклу ввод начинаются обменные операции, после завершения которых - начинается обработка полученных данных и т.д.

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

Рассмотрим конкретный пример: 900 бинарных сигналов (это реально одна из последних задач, которую я "мозговал"), ввод каждого - не очень быстрый (RS-485 Modbus + не очень быстрая периферия) - скажем 1 мс. (это, кстати, и не так плохо)... По вот той схеме выше: начинаем читать сигнал 1, через 1 мс., получив данные - сигнал 2, ... i, ... i+1 - через чуть больше 900 мс. (1 сек.!) - начинаем логически перебирать эти сигналы, ещё 300 мс., скажем ... и т.д.

Зачем? Мы можем:

- параллельно с уже идущем циклом обработки (предыдущим)...

- запустить операцию на 1-й переменной, и не дожидаясь её завершения - на 2-й и т.д. ...

- через некоторое время операции 1, 2, ... i,i+1,... начнут завершаться, возможно совсем в другом порядке, чем они запускались...

- и вот когда все 900 операций ввода завершатся - тогда мы имеем право обновить буфер входных переменных, и следующий цикл обработки выгребет эти обновлённые данные...

- а все более ранние циклы обработки, которым придёт время начаться ранее полного завершения цикла ввода (здесь всё определяется соотношениями циклов ввода и обработки) - они спокойно возьмут себе старый комплект переменных, но только полный комплект! считанный предыдущим завершившимся циклом ввода (таким образом несколько последовательных циклов обработки могут работать с одним необновляемым набором входных переменных").

И вот здесь простейшая runtime исполняющая система PLC становится ... "просто беда" ;).

[Olej 0]

ISaGRAF - интерпретатор.

Других интерпретаторов не знаю. CoDeSys, OpenPCS - компиляторы (т.е. так называемая целевая/управляющая система там присутствует, но пользовательский код (МЭК языки) компилируется).

 

Но здесь тоже нужно соблюдать определённую осторожность: интерпретатор чего? (или компилятор во что?)

 

ISaGRAF - интерпретатор промежуточной формы TIC, в которую компилируются программные компоненты, созданные на любом из МЭК языков.

 

В этом смысле и Java - интерпретатор, а уж .NET - и подавно ;)...

Тот же считающийся повсеместно интерпретатор (скриптовый язык ;)) Perl в релизе после 5-го - в значительно большей степени компилятор в промежуточный код, чем интерпретатор этого кода.

 

CoDeSys, OpenPCS - компиляторы во что? в систему команд целевой платформы ... в чистом виде, "окончательно и бесповоротно"? Сильно сомневаюсь! ;)

Даже те же С/С++ системы имеют достаточно развитую исполняющую систему: активация, прологи, эпилоги, обработчики исключительных ситуаций, сигналов... всё управление динамической памятью - это всё "интерпретирующие компоненты".

[Andrew2000 0]

Перечитал вниметельнее - выскажу свои мысли.

 

Evgeny_CD:

"

1. Ось - это совокупность стандартов и методологических подходов,

которая обеспечивает:

* разработку кода силами команды (>1 человека), причем код, написанный

одним человеком, с небольшими усилиями используется другим

* повторное использование кода от проекта к проекту

* переносимость между целевыми платформами и средами разработки

"

Нет, извините, Переносимость - да, а остальное к Оси отношение не имеет.

Грамотные "черные ящики" - сила любого проекта.

 

А с остальным я полностью соглашусь.

 

===

 

Vic1:

"

Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)

http://www.natahaus.ru/2006/02/17/programm...ontrollery.html

"

_не слишком доверяя автору_ - а можно подробнее? книгу читал, а где надо не доверять?

 

"

Это все давно известно для задач АСУТП (их основное отличие от задач ЦОС - "мягкое" реальное время,

в остальном - много похожих свойств).

"

Я думаю, "мягкое" реальное время и задачи АСУТП связывать не надо - "мягкое реальное время" -

это как систему построить, а АСУТП разные бывают.

 

====

 

Vic1:

"

Насчет Siemens и его Step7 такой уверенности нет (вроде как без ОС РВ).

И еще, очевидно что подход с интерпретатором TIC-кода для ЦОС и ИИС не подойдет

(если только не уйдем куда-нибудь совсем в сторону изменяемой системы команд процессора под свою задачу ...)

"

Вот Siemens как раз сюда и ушел - см Speed7 - http://www.speed7.com/ :)

А Vipa (брат-близнец Simatic) ставит на свои контроллеры eCOS.

Только одно _но_ - у них в одном контроллере 3 CPU: Speed7 для выполнения технологического алгоритма,

х86 (видимо он с eCOS) для связи с верхним уровнем по Ethernet и какой-нить SAB+ASPC2 для сети Profibus.

(Не уверен на 100%, но общая картина такая)

 

"

Хотя когда появились ПЛК и эти языки МЭК - уж такие размахивали флагом "открытых систем".

А на вопрос про переносимость и включение своего драйвера - да ОЕМ часть обязательно есть

(заплати только огромную сумму)! Ну это off-topic.

"

А Вы обратили внимание на историю МЭК языков (их корни) и какие фирмы этот МЭК между собой сделали стандартом ? :)

 

===

 

Olej:

"

Там ещё интереснее, если быть совсем точным...

Я не знаю как с CoDeSys ...

"

А точно так же как и с ISa, только CoDeSys компилятор, и надо смотреть поддерживает-ли он платформу.

 

===

 

Evgeny_CD:

"

имеет смысл написать свой макро-язык, который ...

"

Так МЭК стандарт так и создавался :)

Только фирмы, создавшие языки были крупными и сделали из внутрифирменного решения IEC.

(И как Siemens свой Profibus сделал МЭк-овским)

 

===

 

SM:

"

Кол-во ресурсов - это площадь - это доллары и центы.

"

"

Да потому, что область-то может и узкая, но внутри нее очень и очень много всего ...

"

 

Все-таки, тут обсуждается два разных подхода. Назовем их "ЦОС" и "АСУТП", условно.

1. "ЦОС" - Вы разрабатываете _изделие_, как правило, массовое, и сдаете его заказчику.

Сперва у Вас присутствует ОС, затем, после оптимизации уходит (а может и остается,

а может видоизменяется, не важно).

(Честно говоря, я так и живу :) Сначала работают несколько задач под ОС,

а в релизе - одни прерывания и ОСь с одной задачей .... для диагностики)

Такие системы, узкоспециализированные _в конечном итоге_, выжимают из аппаратуру ~100%.

2. "АСУТП" - Вы сдаете заказчику _конструктор_, на базе которого он (а может и Вы сами)

строит систему управления производством - здесь многократный запас по производительности,

и "живая" (т.е. ПО меняется) система (добавь еще две ложки .... как в к/ф "33").

 

===

 

Vic1:

"

основное достоинство языков МЭК - введение новых элементов языка, отражающих специфику

предметной области, причем не только новых структур данных, но и структур управления

"

?????

 

"

Упоминаемые здесь скриптовые языки .... А как там обстоит дело с возможностью введения

новых управляющих конструкций языка, (часто требующих доступа к аппаратному уровню целевой системы)?

"

А тут (МЭК) это тоже никак не обстоит.

 

====

 

SM:

"

Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом

в бесконечном цикле ...

"

"

Так как нет диспетчера. Все задачи вызываются последовательно обычной цепочкой CALL'ов на подпрограммы.

Каждая подпрограмма - задача - КА. ... , что в каждом из них программа не может находиться например

более 500 тактов CPU

"

Отличное описание работы ISaGRAF-a, точнее его целевой задачи.

Ессно, эта задача может быть запущена как без ОС, так и как процесс под ОС.

[Andrew2000 0]

Языки МЭК вызывают у меня ... какие-то смутные ощущения ;), не пойму пока:

 

2. кто их использует (здесь уже столкнулись с разночтениями в терминологии: технологи / программисты)?

 

Но есть и другой скрытый механизм параллельности, и это гораздо серьёзнее... Когда рассматривают вот тот цикл работы АСУТП процесса: - ввод - обработка - вывод - часто неявно предполагается, что всё именно так и производится: по циклу ввод начинаются обменные операции, после завершения которых - начинается обработка полученных данных и т.д.

 

МЭК языки испоьзуют (по-моему мнению):

- программисты-технологи, т.е. люди, умеющие составлять программы и разбирающиеся в тех.процессе. они очень любят язык FBD (мое наблюдение).

- обычные программисты, которых наняли для тех же работ и сказали - пишите на МЭК языках, т.к. это круто и только МЭК языки весь мир применяет. Это самый ужасный случай. Они пишут, матеряться, и говорять что на асм/С/С++ написали бы быстрее.

 

Под циклом ввода и вывода в МЭК системых подразумевается отображение входных/выходных данных на внутренние переменные. т.е. как этот ввод/вывод происходит - дело разработчика контроллера (в параллельной задаче, или параллельно аппаратурой, ...)

 

 

Но здесь тоже нужно соблюдать определённую осторожность: интерпретатор чего? (или компилятор во что?)

 

Интерпретатор TICкода, т.е. пользовательской программы - ISaGRAF.

Компилятор в машинные коды (тоже пользовательской программы) - CoDeSys

[Olej 0]

МЭК языки испоьзуют (по-моему мнению):

- программисты-технологи, т.е. люди, умеющие составлять программы и разбирающиеся в тех.процессе. они очень любят язык FBD (мое наблюдение).

- обычные программисты, которых наняли для тех же работ и сказали - пишите на МЭК языках, т.к. это круто и только МЭК языки весь мир применяет. Это самый ужасный случай. Они пишут, матеряться, и говорять что на асм/С/С++ написали бы быстрее.

 

Так не пишите ;)...

Или пишите "на асм/С/С++" быстрее ;).

Я, например, на это так и смотрю: хотите - я на С/С++ вам это сделаю, не хотите - пусть другие на МЭК "лабают", а я посижу в сторонке, посмотрю...

 

И из множества предпринятых попыток "подходов" к этому классу задач, я вынес и осмелюсь сделать такие предположения:

- каждая комерческая система проектирования логики + SCADA - хороша применительно только для той области, для которой она изначально разрабатывалась... , да ещё и лучше всего в руках именно тех, кто её и разрабатывал ;);

- если "идти" на целую цепочку проектов в однотипной области использования - то лучше не использовать ничего из коммерческих tools, а, проанализировав, по образу и подобию ... сделать свой набор tools для наиболее общих случаев или элементов своей области, на тех же С/С++ (asm я сознательно исключаю, т.к. приобрёв в нём весьма приличный опыт - пришёл к выводу, что ничего в asm нельзя сделать того, чего нельзя в С, а если можно - то это только от неумения ;))...

- и потом уже с использованием этого tools - лепить проекты в своей прикладной области.

 

Под циклом ввода и вывода в МЭК системых подразумевается отображение входных/выходных данных на внутренние переменные. т.е. как этот ввод/вывод происходит - дело разработчика контроллера (в параллельной задаче, или параллельно аппаратурой, ...)

 

Всё так, только в том то и дело, что "в зависимости от" :

- цикл на одном и том же оборудовании может отличаться на порядок (не переходя никуда в более производительные платформы);

- уровень/степень надёжности (ошибок, или обратно - уровень тщательности и квалификации) для реализации вот этого "на порядок больше" - тоже может потребоваться на порядок больше.

 

И это не совсем дело "разработчика контроллера", т.е. в прямолинейной как у носорога US-действительности, когда "разработчик" пишет: делай-раз, делай-два, и т.д. - и "всё гарантируется ОК" - можно и так подходить ... только мне хотелось бы знать а чем конкретно вот тот "разработчик контроллера" это гарантирует?

 

Пример: меня очень радует документация Modicon/Schneider Electric ... особенно в том месте, когда они предлагают в пакете разработки логики PLC Unity Pro ... наличие целых до 7-ми, кажется, параллельных задач в логике - ввод - обработка - вывод - ... (приоритетная задача, таймерные процедуры etc.). Вы хорошо себе представляете, что такое асинхронно возбуждаемая таймерная задача, которая начинает с чтения входных переменных (с уже начатой, возможно, обработкой фоновой задачи с прежними значениями переменных), да ещё когда они все написаны на МЭК, в которых в принципе даже не задумывались над синхронизацией значений переменных... На такой провокационный вопрос служба техподдержки Schneider Electric мычит что-то нечленораздельное, что мол, набор переменных одной задачи, и другой задачи - это непересекающиеся наборы, ... только на кой хрень мне параллельные задачи на непересекающихся наборах данных - я не собираюсь делать 7 независимых систем управления на одном PLC: кофеваркой, летательным аппаратом, уличным освещением ... и ещё одним ЦОС ;).

Так что - не так всё там просто!

[=AK= 12]

Чтобы лучше понять суть МЭК-овских языков, настоятельно рекомендую ознакомиться с историей создания ПЛК. Лучше всего читать первоисточник, http://www.barn.org/FILES/historyofplc.html

 

Я бы выделил следующие существенные моменты:

-- ПЛК изначально создавался как средство замены релейных шкафов автоматики. Первые языки программирования ПЛК "имитировали" релейные схемы. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Языки ST и SFR - это более поздние добавки.

-- Языки создавались на сравнительно бедной базе вычислительной техники 70-х ... 80-х годов, как аппаратной, так и программной. "Если нет гербовой бумаги - пишем на простой" (с) Поэтому имитация релейных схем изначально была достаточно условной.

 

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

 

Программы на МЭК-овских языках надежны прежде всего потому, что представляют пользователю очень простую и понятную модель поведения: все операторы в идеале исполняются "одновременно". А заморочки неодновременного исполнения - это уже нюансы реализации, исторические "родимые пятна". В конечном счете, надежность программ зависит прежде всего от человека, а именно - от того, насколько он хорошо представляет, что делается, и насколько он "держит в голове" что происходит в его программе. То есть, насколько хорошо он моделирует систему. Если порядок исполнения операторов неважен (пусть даже условно), это сильно упрощает моделирование и, соответственно, повышает надежность программы. Средства программирования ПЛК являются тому подтверждением.

[Evgeny_CD 0]

Думаю, в свете всех этих PLC языков программирования будет интересна эта книга

http://www.natahaus.ru/2006/03/05/SWITCH__tekhnologija.html

А.А. Шалыто

SWITCH - технология

Алгоритмизация и программирование задач логического управления

Издательство: Наука

Год: 1998

Формат: DjVu

http://rapidshare.de/files/14697466/SWITCH.rar.html

без пароля

 

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно (есть еще заповедники "непуганных идиотов" (я не хочу обижать приверженцев МЭК) - и как только все эти заводы & фабрики работают?), с другой стороны, я наполняюсь оптимизмом - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными - придет время революции в мире PLC. Как следствие, для меня и других разработчиков будет БОЛЬШОЕ поле для деятельности. Разумеется, "старое" будет отчаянно сопротивляться - но кто его, "старого" спросит...

 

Одним из моих выводов (IMHO) - ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC. Не завтра, но рано или поздно он появится. Ибо, с моей точки зрения, терпеть дальше все это безобразие с Бейсик-подобными языками - "держаться больше нету сил" ((С) "Тайна 3 планеты"). А кто привнесет стройную и ясную концепцию, дополненную высокопрофессиональным PR - тот и победит. Стоимость аппаратуры и софта тут не так важна. Т. е. по сути нужны:

* новый хороший язык

* несколько хороших книжек

* GPL реализация всего этого, желательно на любой аппаратной платформе для учебно-ознакомительных целей (ограниченная реализация)

* нормальный коммерческий продукт за вполе нормальные $$$

* и главное, главное - маркеторлоги и PR-щики, которые все это пропихнут.

 

Надо будет присмотреться к миру PLC более внимательно!

 

Нет, извините, Переносимость - да, а остальное к Оси отношение не имеет.

Грамотные "черные ящики" - сила любого проекта.

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

Изменено 5 марта, 2006 пользователем Evgeny_CD

[=AK= 12]

Думаю, в свете всех этих PLC языков программирования будет интересна эта книга

http://www.natahaus.ru/2006/03/05/SWITCH__tekhnologija.html

"Излашается технология алгоритмизации и программирования задач логического управления на основе теории автоматов." Ладно, пускай "излашается"

 

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно (есть еще заповедники "непуганных идиотов" (я не хочу обижать приверженцев МЭК) - и как только все эти заводы & фабрики работают?), с другой стороны, я наполняюсь оптимизмом - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными - придет время революции в мире PLC... ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC

Угу. "Мы наш, мы новый мир построим..." (с) Не разбираясь, навесим на реально работающую технологию "правильные" ярлыки, выкинем на помойку, а потом будем изобретать свой велосипед, пусть изначально кривой, но зато за отдельные деньги. Это и есть стиль мелкомягких, истинная правда... :cranky:

[Andrew2000 0]

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно ... - и как только все эти заводы & фабрики работают?), ... - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными

...

Одним из моих выводов (IMHO) - ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC. Не завтра, но рано или поздно он появится. Ибо, с моей точки зрения, терпеть дальше все это безобразие с Бейсик-подобными языками -

...

Стоимость аппаратуры и софта тут не так важна. Т. е. по сути нужны:

* новый хороший язык

* GPL реализация всего этого, ...

 

Начнем с ужасов.

Настоятельно _не_ рекомендую читать эту статью:

К ПЯТИЛЕТИЮ СТАНДАРТА IEC 1131-3. ИТОГИ И ПРОГНОЗЫ Copyright 1998, Vladimir Zyubin.

1998г - немного устарела, а _главное_ - получите неверное представление о МЭК языках.

 

Что Вы понимаете под ""нормальным подходам" к программизму"? Чего Вам не хватает в МЭК языках?

Это всего _языки_, а подходы - это Ваше дело.

"безобразие с Бейсик-подобными языками" - может Вы эту статью уже прочитали?

Откуда про Бейсик?!?!

 

МЭК языки:

- SFC - Sequential Function Chart - можно назвать диаграммой состояний - каркас программы управления.

- FBD - Functional Block Diagram - как я уже писал, это то, что любят технологи. Это совсем другой подход к программированию. Это не структурный подход и не объектно-ориентированный - это язык, управляющий потоками данных.

Это аналог MATLAB, LabView, и т.д., мне, например, очень тяжело было "переключить" мозги на этот стиль со структурного подхода. Но, есть много людей успешно работающих с MATLAB/LabView/FBD, может Вам и удасться предложить им свой "нормальный подход".

- ST - Structured Text - это Паскаль/Бейсик/С - как его только не называют. Я, когда с ним познакомился, увидел в нем Fortran :) А собственно, что тут удивительного ...

Не нравиться Вам FBD - вот Вам ST. Кстати, объектно-ориентированные зачатки в МЭК языках тоже есть - это Функциональные Блоки (Function Blocks) - не путать с языком FBD.

- IL - Instruction List - "универсальный" Ассемблер, происхождение - STEP5. Нужен был для переноса программ со STEP5. Современное назначение этого языка - организация PLCOpen сертифицирует ПО программирования ПЛК на соответствие стандарту МЭК - и это _единственный_ язык на соответствие которому сертифицированы все известные системы программирования ПЛК :) (см. http://www.plcopen.org/). Изучать/писать на этом языке, я думаю, уже никто не будет.

- LD - Ladder Diagram - язык релейно-контактных схем, кстати, у технологов до сих пор пользуется спросом.

 

"ждем появления аналого Micro$oft"? А что Micro$oft сделали в "нашем" мире? кроме Бейсик-а :)

Свой Micro$oft в мире PLC и так есть - это Siemens со своим STEP5/7 - для тех же целей но не мэк, я свой собственный.

 

"новый хороший язык" - не спорю, никогда не помешает, ждемс :)

"GPL реализация всего этого" - на sourceforge можно найти - какой-то Чех или Словак написал (не помню) - язык документации похож на украинский (только латинскими буквами), тяжело, но читать можно :)

Кроме того - http://linuxplc.org/

 

 

Теперь по теме ветки :)

Когда в ПЛК ОС не нужна - когда у Вас работает только одна задача (POU "Program"), т.е. единственный цикл/такт ввод-обработка-вывод с фиксированным/заданным временем такта, а ввод/вывод данных можно обеспечит параллельно на прерываниях или аппаратно.

Если Вам потребуется более одного цикла (кстати ISaGRAF версии 3 это не поддерживает, только ISaGRAF Pro), например, когда нужно разное время реакции для управления двумя объектами - тут без ОС тяжело.

[=AK= 12]

Настоятельно _не_ рекомендую читать эту статью:

К ПЯТИЛЕТИЮ СТАНДАРТА IEC 1131-3. ИТОГИ И ПРОГНОЗЫ Copyright 1998, Vladimir Zyubin.

1998г - немного устарела, а _главное_ - получите неверное представление о МЭК языках.

Это не статья, а бред.

 

- ST - Structured Text - это Паскаль/Бейсик/С - как его только не называют. Я, когда с ним познакомился, увидел в нем Fortran :)

ST происходит от благородной Модулы. Паскалем его еще можно назвать с большой натяжкой, но уж Бэйсиком, С или Фортраном ST обзывать могут только люди совсем несведущие.

 

- IL - ... происхождение - STEP5.

Не надо повторять зюбинские бредни.

[Andrew2000 0]

ST происходит от благородной Модулы. Паскалем его еще можно назвать с большой натяжкой, но уж Бэйсиком, С или Фортраном ST обзывать могут только люди совсем несведущие.

Да, видимо, Вы правы. Паскаль я совсем не знаю и ничего сказать не могу. А вот Фортран мне вспомнился по индексам в массивах, по FUNCTION и FUNCTION_BLOCK, еще чего-то, не помню...

 

А по-поводу IL - поправте, почему бредни? была у меня когда-то документация на STEP, видел я там такое (правда давно, может память изменяет) или корни еще дальше?

[Evgeny_CD 0]

"Вредная" статья

http://www.msclub.ce.cctpu.edu.ru/plc/iec1131.htm

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

 

Да, стоит признать, что в PLC я профан. Но меня _интуитивно_ смущает другое. Возникает ощущение искуственности созданного мира. Т.е. есть мир "обычного" программизма - от 51 однокристалки до кластера на AMD64, который живет по одним, в общем-то, законам. И есть мир PLC, где сущность "обычного" программизма старательно спрятана за масками МЭК и пр. "языков программирования".

 

Но PLC'шники не одиноки в старании спрятать "отпугивающее мурло" системного программизма. Для этого были изобретены скриптовые языки (Perl, Python, LUA, RUBY, ...), которые

* переносимы с платформы на платформу

* гибки: можно предельно просто писать на "начальном" уровне, а можно использовать язык "на всю катушку", существенно экономя ресурсы на этапе разработки.

 

Для меня так и остается загадкой, почему PLC'шники не использовали богатый мир скриптовых языков "в своих целях". Одна мысль есть - тот же Python "повзрослел" как раз в 98-99 годах, когда МЭК исполнилось 5 лет... LUA, RUBY еще более молодые языки.