[Владимир Е. Зюбин 0]

конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...

Вот где собака зарыта во всей это МЭК философии!!!

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

 

IDE разных производителей настолько непохожи, что на этом фоне упрощение за счет стандартизации собственно языков слабозаметна. Можно Петрова почитать. И это если не говорить об местячковых улучшениях стандарта. (См. для примера codesys.ru) От МЭК 61131-3 сохраняются только декларации.

 

Польза от МЭК 61131-3 конечно же есть, но не стоит ее преувеличивать.

 

Кстати, Ваши аргументы относительно ООП и ПЛК не вполне соответсвуют реальности. В последнее время появилась куча (от разных производителей) ПЛК со встроенной ява-машиной внутри... CoDeSys также вводит ОО возможности в свои расширения МЭК-языков. Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

 

Сборка мусора и утечки памяти - это проблема, но не критическая, а для задач класса ПЛК и не актуальная, т.к. там не предполагается активной работы с памятью.

 

Какие из моих утверждений, Вам кажутся бредовыми?

Долго перечислять, много их. Про "тайные мотивы" МЭК и PLCopen пишите бред, про МЭК языки - бред, про ООП в PLC - бред (см. выше), про языки программирования "вообще" - тоже бред, часто противоречивый (то можно С/С++/Паскаль и пр. применять для автоматизации, то нельзя), и т.п.

 

А чем Вас фраза "можно применять, но не эффективно" неустраивает? Где тут противоречия-то? 8-)

Многие действительно и на Си пишут, и на ассемблере. Я не возражаю и допускаю, но считаю это не всегда оправданным.

 

Про ООП и ПЛК я опять же повторюсь, что ООП по сути не подходит для задач промавтоматизации. ООП - это средство программирования WIMP-систем. Так ООП и в Майкрософте используется, а Вирт, так уже поседел без конца это повторяя. :-) Ваши заявления про утечку памяти интересны, но неубедительны.

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

 

Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.

 

Опять Вы про этот IL и STEP5. Разумеется, у меня нет стенограмм заседаний МЭК, где представители Сименс предлагали включить IL в МЭК. Также как и у оппонентов МЭК нет внятного обоснования причин для появления этого ассемблера в наборе языков МЭК.

Единственно, что я слышал (и слышал несколько раз), это связь IL и STEP5. Мне лично такое объяснение кажется убедительным: традиции и распространенность Сименс на рынке, пользователей проще застрелить, чем переучить. Чем-то похоже на историю с Коболом (целая индустрия в США).

 

Если Вам это кажется неубедительным - приводите свои аргументы, попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере. А вдруг, чем черт не шутит, у Вас это получится. Я посыплю голову пеплом и поставлю Вам пару бутылок пива.

[=AK= 12]

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

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

 

Опять Вы про этот IL и STEP5. Разумеется, у меня нет стенограмм заседаний МЭК, где представители Сименс предлагали включить IL в МЭК.

Это не я "опять". Посмотрите свою статью 2005 года "Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы", там примерно половина текста скопирована из первой статьи 98 года ("автоплагиат" своего рода). Включая измышления о том, что IL произошел от STEP5. Причем подано в безапелляционной форме, поэтому кто-то принимает за чистую монету. Свои аргументы против я привел ранее, ищите где-то на 4-й странице этого топика.

 

попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере

То есть, на IL? Вы уже оскомину всем набили своими глупыми нападками на IL. Скачайте книгу http://www.fen-net.de/karlheinz.john/Bookview.htm, там подробно написано какой МЭК-овский язык для чего используется. (ST+IL) в PLC образуют такую же пару, как (C+ассемблер) при программировании микроконтроллеров. Попытайтесь эмбедщиков убедить, что на С им можно писать, а на ассемблере и на смеси С+ассемблер нельзя, так вас засмеют, и правильно сделают.

 

Кстати, в этой книге есть немного истории создания МЭК-овского стандарта.

[Владимир Е. Зюбин 0]

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

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

Все правильно, Алексей, Вы говорили про сбор мусора, про утечку это я от себя добавил, и считаю, что к месту, т.к. это более серьезная проблема ООП, чем сбор мусора. В общем же, насколько я понимаю, Вы аппелируете к динамическим операциям с памятью. Или я опять не прав?

 

Если я прав, то опять повторюсь: ваши аргументы насчет динамических операций с памятью интересны, но неубедительны. Я и сам могу кучу всякого вспомнить начиная от диск-своппинга, но проблема комплексная, и пользователь при выборе средств проектирования рассматривает комплекс параметров.

Основной из которых - эксплуатационные издержки, сопровождаемость, стоимость разработки. Было бы на ООП просто программировать, всем было бы начихать на проблемы ООП. Возможная задержка на сотню миллисекунд на "уборку мусора" для 95% приложений ПЛК роли не играет. Да и насколько актуальна проблема динамических манипуляций с ОЗУ для задач ПЛК - это большой вопрос.

 

Опять Вы про этот IL и STEP5. Разумеется, у меня нет стенограмм заседаний МЭК, где представители Сименс предлагали включить IL в МЭК.

Это не я "опять". Посмотрите свою статью 2005 года "Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы", там примерно половина текста скопирована из первой статьи 98 года ("автоплагиат" своего рода). Включая измышления о том, что IL произошел от STEP5. Причем подано в безапелляционной форме, поэтому кто-то принимает за чистую монету. Свои аргументы против я привел ранее, ищите где-то на 4-й странице этого топика.

 

Так ничего с 1997 года не изменилось, как IL был похож на сименсовского собрата, так и остался...

 

Хорошо, приведу Вас полностью, с 4-ой страницы:

Зюбин - единственный, кто утверждает, что IL произошел от STEP5. При этом не приводит никаких оснований для такого утверждения. Поскольку практически любое самостоятельное утверждение Зюбина является тяжким бредом, то это, очевидно, следует отнести туда же.

 

Первым языком ПЛК, разработанным в 70-х, был "ладдер диаграм", из которого впоследствии произошел LD. Это графический язык, который инструментальной системой транслировался в промежуточный код. Промежуточный код затем исполнялся (интерпретировался) в PLC. Вот этот промежуточный код и был предтечей IL.

 

Первыми производителями ПЛК были Модикон и Аллен-Брэдли, Сименс стал делать ПЛК на несколько лет позже (когда точно - не знаю, но позже, это точно). Поэтому еще до того как появился Step5, контроллеры Модикон и Аллен-Брэдли использовали нечто подобное IL. Пусть они в отличие от Step5 не оформляли свой промежуточный код как язык, на котором пользователь мог бы писать программы, но он был.

Комментарий по этому поводу у меня будет такой:

Алексей, то, что Вы пишете, несерьезно. Несуразица какая-то. Такое впечатление, что Вы просто пытаетесь доказать, что Зюбин не прав, причем, делаете это как-то неубедительно... Ну хорошо, я не прав, но где Ваш-то правильный ответ на вопрос, почему IL оказался среди языков МЭК 61131-3?

Неужели Вы считаете, что причина этого в том, что это промежуточный язык Модикона и Аллен-Бредли... Подумайте, что же Вы пишете и что пытаетесь доказать.

 

попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере

То есть, на IL? Вы уже оскомину всем набили своими глупыми нападками на IL.

Какие нападки, Алексей? Кто на кого нападает-то?!

Я говорю, что праобраз IL используется в Сименс, что это ассемблероподобный язык.

Что (и это очевидно) это не ассемблер и смысла в таком низкоуровневом по сути языке нет.

 

Скачайте книгу http://www.fen-net.de/karlheinz.john/Bookview.htm,

Спасибо за ссылку, эту книгу я уже листал пару лет назад.

там подробно написано какой МЭК-овский язык для чего используется. (ST+IL) в PLC образуют такую же пару, как (C+ассемблер) при программировании микроконтроллеров. Попытайтесь эмбедщиков убедить, что на С им можно писать, а на ассемблере и на смеси С+ассемблер нельзя, так вас засмеют, и правильно сделают.

 

Кстати, в этой книге есть немного истории создания МЭК-овского стандарта.

Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

 

Я кажется понял, в чем у Вас проблема. Понимаете, Алексей, дело в том, что IL - это не ассемблер, это просто ассемблероподобный язык, исполняющийся, как правило, под интерпретатором... к архитектуре вычислительной платформе он не имеет никакого отношения.

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

 

Но ни то, ни другое не имеет к ситуации с МЭК никакого отношения. До платформы с помощью IL не "докопаться", и есть ST. Вполне сносный, но, увы, паскалеподобный язык. Кстати, спросите у эмбедщиков, как они к Паскалю относятся... ;-)

[Andrew2000 0]

Со стандартом Профибас та же история...

Это какая же та же ??? Profibus - изначально Siemens. Просто Siemens сделал его IEC-ом.

[Andrew2000 0]

Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

А какое отношение эти XML и java имеют к ООП в PLC? Не надо путать среду разработки и среду исполнения.

 

Сборка мусора и утечки памяти - это проблема, но не критическая, а для задач класса ПЛК и не актуальная, т.к. там не предполагается активной работы с памятью.

Замечательно! Еще одна фраза в копилку =AK= бредней от Зюбина

 

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

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один.

 

 

 

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

Назовите хотя бы одну систему IEC61131, кроме всем известного ISaGRAF, работающую в режиме интерпретатора в PLC (Soft PLC под виндами не предлагать).

Или ISaGRAF - это и есть "как правило, под интерпретатором" ?

[Владимир Е. Зюбин 0]

Со стандартом Профибас та же история...

Это какая же та же ??? Profibus - изначально Siemens. Просто Siemens сделал его IEC-ом.

"та же" - имеется ввиду, что в стандарте описывается несколько протоколов (DP, PA, FMS), а автор стандарта - мегакорпорация.

[Владимир Е. Зюбин 0]

Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

А какое отношение эти XML и java имеют к ООП в PLC? Не надо путать среду разработки и среду исполнения.

 

Я не путаю. Отношение такое, что java-машина используется в целой гамме современных сетевых ПЛК от разных производителей. Тенденция такая. Это то, что касается среды исполнения. Что касается среды разработки, то нужно ли здесь этот вопрос поднимать? Среды разработки создаются на языках ООП с нормальным WIMP-интерфейсом. Методология программирования в рассматрвиваемом случае - МЭК61499, на основе МЭК 61131-3.

 

Сборка мусора и утечки памяти - это проблема, но не критическая, а для задач класса ПЛК и не актуальная, т.к. там не предполагается активной работы с памятью.

Замечательно! Еще одна фраза в копилку =AK= бредней от Зюбина

 

Хотелось бы поменьше пафоса и побольше конструктива. Что Вас тут поразило, мне неясно.

Большинство программ для ПЛК даже не знают, что такое calloc или malloc. Я уже не говорю про малобюджетный класс ПЛК на 51-х и прочих Atmel-ах, где и диспетчера памяти-то нет... а ОЗУ всего-то

с десяток килобайтов, а то и сотня байтов.

 

Можете считать это бреднями, но это жизнь.

 

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

 

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один.

 

один я уже привел: www.holobloc.com

хотите больше - поисследуйте здесь:

http://www.google.ru/search?hl=ru&q=Java+PLC

(есть ссылки не по теме, но есть и по теме)

 

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

Назовите хотя бы одну систему IEC61131, кроме всем известного ISaGRAF, работающую в режиме интерпретатора в PLC (Soft PLC под виндами не предлагать).

Или ISaGRAF - это и есть "как правило, под интерпретатором" ?

 

Тут основной момент не "интерпретатор", а связь с архитектурой платформы.

Вы правильно назвали ИнфоТим, уже упоминался holobloc, по-моему, в проекте MathPLC

java-машину используют. Про остальные не скажу. Скажу только, что интерпретатор - это наиболее удобный способ обеспечить контролируемую межплатформенную переносимость (в аппаратном смысле).

И искать нужно там, где декларируется либо многоплатформенность, либо проект делается небольшими силами (тут используются обычно ява-машины).

 

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

 

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

[Владимир Е. Зюбин 0]

По поводу интерпретаторов нашлось прямо тут на форуме, так что просто повторю:

Я например занимаюсь адаптацией iCon-L на разные платформы.

Это нечто вроде CoDeSys, но более дружелюбная система.

 

В этих системах нет чистой интерпретации или компиляции.

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

...

[=AK= 12]

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

Для PLC это не является доминирующими факторами. Главное - надежность, это окупает все. Раз вы этого не знаете, все ваши рассуждения на темы PLC не имеют ни капли смысла.

 

Возможная задержка на сотню миллисекунд на "уборку мусора" для 95% приложений ПЛК роли не играет.

Бездоказательно и по сути неверно. Основную роль играет надежность, в данном контексте - предсказуемость и однозначность поведения. Если PLC "запнется" на сотню миллисекунд, то последствия могут быть катастрофическими. Никого не интересует, что "в основном работает правильно, но иногда, очень редко, при несчастливом стечении обстоятельств, может глючить", такое поделие - это уже не PLC. Какие бы ярлыки на него не пытались навесить маркетологи - ффтопку, в крайнем случае - сойдет для неответственных применений. Потому что когда рванет бак или встанет конвейер, то разница между стоимостью настоящего надежного PLC и "улучшенного псевдо-PLC" окажется мизерной по сравнению с другими издержками.

 

Так ничего с 1997 года не изменилось, как IL был похож на сименсовского собрата, так и остался...

Это не довод. Все IL-подобные языки похожи, это всего лишь ассемблер виртуальной машины, оптимизированной на исполнение LD. Все компании (включая Сименс) "срисовывали" LD и IL с того, что сделали основоположники PLC, т.е. Modicon и Allen-Bradley. С учетом того, что разработка IEC 61131-3 началась с доклада Allen-Bradley, разумнее предположить, что за основу IL и LD были взяты наработки этой компании.

 

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

Еще раз, IL - это ассемблер виртуальной машины. А в некоторых PLC это настоящий ассемблер процессора. Даже без ссылки на старый Симатик S100, сейчас однокристальные процы заточенные на МЭК 61131-3 стали доступны (cм. PLC Chip164, PLCHIP-M2-12800 и др). Не надо бредней про "отсутствии такого соответствия". Это в вашем Рефлексе смысла нет, никому он не нужен.

 

Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

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

 

Кстати, спросите у эмбедщиков, как они к Паскалю относятся... ;-)

Вот я, прожженный и проканифоленный эмбедщик со стажем, спрашиваю себя: как я отношусь к Паскалю? Отвечаю: хорошо отношусь, и к человеку, и к языку. Зато к "ученым", много лет обгаживающим PLC индустрию, отношусь плохо.

[Andrew2000 0]

Хотелось бы поменьше пафоса и побольше конструктива. Что Вас тут поразило, мне неясно.

Большинство программ для ПЛК даже не знают, что такое calloc или malloc. Я уже не говорю про малобюджетный класс ПЛК на 51-х и прочих Atmel-ах, где и диспетчера памяти-то нет... а ОЗУ всего-то

с десяток килобайтов, а то и сотня байтов.

Ладно, приведу Вас полностью:

"

Кстати, Ваши аргументы относительно ООП и ПЛК не вполне соответсвуют реальности. В последнее время появилась куча (от разных производителей) ПЛК со встроенной ява-машиной внутри... CoDeSys также вводит ОО возможности в свои расширения МЭК-языков. Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

 

Сборка мусора и утечки памяти - это проблема, но не критическая, а для задач класса ПЛК и не актуальная, т.к. там не предполагается активной работы с памятью.

"

Так о чем тогда говорим? О "малобюджетный класс ПЛК на 51-х" или типа Logo, или про PLC в которые можно заталкать Java, или про PLC с целым набором сетевых интерфейсов/протоколов?

 

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

А как же Speed7 у того же Siemens/Vipa ?

(=AK= еще больше примеров привел)

[Olej 0]

Конечно не следует. ООП в PLC почти не применяется по совсем иным причинам.

 

1. не "почти не применяется", а "почти не применялись"...

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

 

2. но время это (~20 лет!) - закончилось, года 2-3 назад (но по-настоящему только сейчас), когда на рынок стали ibhjrj поступать soft PLC на базе открытых платформ и операционных систем: WAGO, VIPA, AutomationX ... "имя им легион"(с) (и именно с тех пор подразделении PLC Siemens начала под ногами земля гореть - знаю это непосредственно с приватных слов руководителя австрийского партнёра Siemens)...

Аргументы? их будет ;) ... , но для начала:

 

Например, мало кто знает даже, какие процессоры используются в ПЛК фирмы Сименс. :-)

 

Я не до такой степени ковырял Сименс, но та же абсолютно история со всеми брандами... "тайна за семью печатями"... и когда меня это совсем допекло, я просто взял и "расковырял" PLC Modicon (Schneider Electric), не из старшей линейки, но и не из самой младшей 2006г. (внимание!) производства: ... AMD186 33Мгц.! - это x386, который имеет и модель защиты памяти заметно отличающуюся (по-крайней мере - несовместимую по ПО) со всеми последующими (x486/Pentium etc.). А потом в глубинах фирменной документации SE (до которых заведомо никто не доберётся) раскопал и для более старших моделей линейки Quantum: 486 100Мгц, 586 133Мгц, и т.д. Как тут не вспомнить Б.Пастернака: "... какое, милые, у нас тысячелетье на дворе?"(с).

И всё бы это было бы ничего, если бы эти PLC бодро не распродавались в 2006г. по ценам $2-$4.5 тыс.! - никто из вас не пробовал "врулить" 386SX эдак тысяч за 4 "зелёных"? ;).

А какая ОС работает как runtime в любом из брандовых PLC? вот куда более сакраментальный вопрос, на который посложнее будет найти ответ! Но по ряду косвенных признаков (да и по тому, что PLC со своим runtime ведут себя идентично на процессорах с разной моделью защиты памяти) я си-и-и-льно предполагаю, что там тривиальный MS DOS... Да и не нужно им более ничего, собственно, если там крутится одна строго цикличная задача, нет асинхронной многозадачности (да и вообще нет никакой), и эта принципиальная "однонитиевость" гарантирована закрытостью PLC, и тем, что никто туда ничего не добавит...

И это не потому, как такой "плохой" SE - нет, точно та же история с PLC любого из брандов: Allan Bredley, Siemens, etc.

 

3. а на предмет "не применяются" ... посмотрите на tolls тех же AutomationX (PLC tools + SCADA) - ООП, программные классы, создаваемые под отраслевые сущности...

 

...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:

 

Да, канешно ;)...

Это почти дословно из Ремарка:

- В том что мы проиграли войну - виноваты евреи!

- Да, конечно, ... и велосипедисты.

- ... а почему велосипедисты?

- А почему евреи? (с).

 

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

 

1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);

 

А что, в радиолокационных системах, или авиационных бортовых системах - там нет такой красивой детали как "гомеостатика"? там мы ничем не управляем? (конечно, MS Windows мы в сравнениях не будем употреблять, договорились?).

 

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

 

Цикличность, ... или более строго та её часть, которая предполагает строго цикличное выполнение фаз ввод-обработка-вывод - так она совсем и не так обязательна в таком явном выпячивани, она может быть заложена и в любом другом ПО, которое чем-то управляет... куда важнее здесь синхронность, единомоментность ввода и вывода, которая и выпячивает цикличность на поверхность рассмотрения.

 

3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;

 

Красиво ... ;)

А в чём же провинилось любое другое ПО в смысле "событийного полиморфизма"?

И кто мешает выразить его там?

 

4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);

 

А в чём же времнные сущности (и возможности) меньше выявлены в любой realtime OS и realtime ПО?

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

 

5) логический параллелизм исполнения, отражающий независимость и параллелизм процессов на технологическом объекте, активная работа с потоками управления, конвергенция, дивергенция и т.д.

 

Логический - да. Но не дай Бог - физический, когда PLC со своей убогой начинкой полезут реально распараллелить эти логические ветки. А тот же, любой степени "глубокомыслия" логический параллелизм - прекрасно отображается на тему примитивов синхронизации того же POSIX, вот на нём и реализуйте глубокий логический параллелизм, скрыв реализацию под любым "высокоуровневым" языком, тем же МЭК...

 

Кстати, тот же tools МЭК реализован как составная часть ПО soft PLC того же aXcontroller, как только 1 из возможных примеров, но вместо этого контроллера - вы можете взять любой стандартный PC (хотя бы на период разработки), и всё оно там так же точно "закрутится" ... возможно как только одна из нескольких задач операционной системы QNX, к примеру (при желании всё то же можно крутить и под Linux, и под Windows - кому что ближе)... И выполняйте на здоровье в этой конфигурации свои МЭК-программы, но не препятствуя разработчику, помимо этого и на своё усмотрение, параллельно раскрутить HTTP-сервер, и организовать, скажем, удалённое управление в технике Ajax ... или кто на что горазд ... "в меру своей распущенности"(с).

 

Вот чего избегала индустрия PLC 20 лет!

[Владимир Е. Зюбин 0]

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

Для PLC это не является доминирующими факторами. Главное - надежность, это окупает все. Раз вы этого не знаете, все ваши рассуждения на темы PLC не имеют ни капли смысла.

Вы слишком зациклены на надежности. Да еще и рассуждаете о ней как о качественной характеристикие, в то время, как характеристика эта количественная.

 

В общем, не надо про надежность. Особенно в таком смехотворном стиле: "Главное - надежность, это окупает все". Для меня это прямое указание на то, что ни одно реальное ТЗ Вы в глаза не видели.

Также это указывает на то, что Вы не разу технико-экономическое обоснование не составляли, а в ВУЗе, если и был у Вас предмет по экономике, то преподавался он из рук вон плохо.

 

Возможная задержка на сотню миллисекунд на "уборку мусора" для 95% приложений ПЛК роли не играет.

Бездоказательно и по сути неверно. Основную роль играет надежность, в данном контексте - предсказуемость и однозначность поведения. Если PLC "запнется" на сотню миллисекунд, то последствия могут быть катастрофическими. Никого не интересует, что "в основном работает правильно, но иногда, очень редко, при несчастливом стечении обстоятельств, может глючить", такое поделие - это уже не PLC. Какие бы ярлыки на него не пытались навесить маркетологи - ффтопку, в крайнем случае - сойдет для неответственных применений. Потому что когда рванет бак или встанет конвейер, то разница между стоимостью настоящего надежного PLC и "улучшенного псевдо-PLC" окажется мизерной по сравнению с другими издержками.

 

Алексей, не нагнетайте панику на пустом месте. Про взрывы НПЗ и АЭС. И про сверхнадежные ПЛК.

Лучше полистайте последние номера журналов. Весь мир движется в сторону ПЛК на основе Wintel.

Это гораздо на порядок дешевле и не уступает в надежности закрытым решениям от Сименс.

 

Так ничего с 1997 года не изменилось, как IL был похож на сименсовского собрата, так и остался...

Это не довод. Все IL-подобные языки похожи, это всего лишь ассемблер виртуальной машины, оптимизированной на исполнение LD. Все компании (включая Сименс) "срисовывали" LD и IL с того, что сделали основоположники PLC, т.е. Modicon и Allen-Bradley. С учетом того, что разработка IEC 61131-3 началась с доклада Allen-Bradley, разумнее предположить, что за основу IL и LD были взяты наработки этой компании.

 

Алексей, Вы меня уже утомляете. Для Вас не довод, а для меня довод: ситуация с МЭК с 1997 года не изменилась.

 

Будьте конструктивны. Приведите свою версию, почему в МЭК61131-3 оказался псевдоассемблер очень похожий на сименовский язык? И, ради Бога, оставьте IL в покое.

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

Еще раз, IL - это ассемблер виртуальной машины. А в некоторых PLC это настоящий ассемблер процессора. Даже без ссылки на старый Симатик S100, сейчас однокристальные процы заточенные на МЭК 61131-3 стали доступны (cм. PLC Chip164, PLCHIP-M2-12800 и др). Не надо бредней про "отсутствии такого соответствия". Это в вашем Рефлексе смысла нет, никому он не нужен.

 

Так Вам Рефлекс не нравится, что ли? 8-) Йехехех. Ну так бы и сказали стразу. А по мне, так очень изящный язык. Пользователи его хвалят. Кстати, пользователи с опытом работы в ISaGRAF. Мне это особо приятно, т.к. в настоящей реализации у Рефлекса даже IDE нет.

 

Я понимаю Ваши чувства, но не могли бы Вы держать себя в рамках. И контролировать то, что Вы пишете. Ну делает кто-то там процессоры под IL, да и пусть. Или Вы считаете, что IL закладывался в МЭК из-за этого? 8-) Какая интересная точка зрения!

 

 

Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

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

Алексей! Да где Вы такое увидели? Где я утверждаю, что на ассемблере программировать глупо?

Что-то Вы не так поняли, перечитайте то место еще раз. И опять же Вы допускаете неточность: МЭКовский IL - это не ассемблер, а лишь ассемблероподобность.

 

Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

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

 

Ну и на чем Вы пишете ПО своих эмбед-систем? Неужто на Паскале? 8-)

Вопрос-то об этом был. Если на Паскале, то мне Вас искренне жаль.

Я, кстати, к работам Вирта очень хорошо отношусь (не его ли случайно Вы Паскалем окрестили? ;), но это не мешает мне использовать Си по назначению.

 

А Ваши эмоции по поводу моих работ, к сожалению, не подкреплены конструктивной составляющей.

Изменено 6 мая, 2006 пользователем Владимир Е. Зюбин

[Olej 0]

Уже не 1 раз прозвучал термин "надёжность":

 

Устройство можно назвать PLC только если оно работает надежно. ООП в смысле надежности имеет не только плюсы (программу писать/отлаживать быстрее), но и минусы (требует больше памяти и производительности проца, а "вкусности" ООП вроде сборки мусора вообще загоняют надежность и предсказуемость поведения в болото). Минусов больше, поэтому в PLC обычно не применяется.

 

Для PLC это не является доминирующими факторами. Главное - надежность, это окупает все.

 

Бездоказательно и по сути неверно. Основную роль играет надежность, в данном контексте - предсказуемость и однозначность поведения. Если PLC "запнется" на сотню миллисекунд, то последствия могут быть катастрофическими. Никого не интересует, что "в основном работает правильно, но иногда, очень редко, при несчастливом стечении обстоятельств, может глючить", такое поделие - это уже не PLC. Какие бы ярлыки на него не пытались навесить маркетологи - ффтопку, в крайнем случае - сойдет для неответственных применений. Потому что когда рванет бак или встанет конвейер, то разница между стоимостью настоящего надежного PLC и "улучшенного псевдо-PLC" окажется мизерной по сравнению с другими издержками.

 

Так об какой "надёжности" мы говорим?

1. О надёжности "железки" PLC? чем она возрасла, от того, что AMD186 процессор затолкали в ящик под названием PLC?

2. О надёжности ПО PLC (МЭК или не МЭК, как больше нравится)?

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

3. В ПО есть ошибки, которые имеют склонность когда-то выявляться или не выявляться, тем создавая подобие "надёжности" (Э.Дейкстра: "... не бывает ПО не содержащего ошибок"(с) - Дэйкстре вы верите? ;))...

Почему я должен считать, что в закрытом ПО закрытого PLC Siemens, Schneider Electric, etc. , доступ к кторому имеют, и следовательно его тестировали ... 10-100-1000 чел. - скрытых внутренних ошибок меньше, чем в ОС Linux или QNX, доступ к которому (и его тестирование и выявление скрытых дефектов) имеют 100000 чел.? и не на протяжении ... 5 лет существования линейки PLC Quantum, а на протяжении 15 лет для Linux, 25 лет для QNX...

А в тех же фирменных tools проектирования ПО (программирование у меня рука не подымается написать) от Schneider Electric - у меня есть несколько явных и вопиющих ошибок поведения (в режиме отладки) того, что изображено на языке функциональных диаграмм, и всех этих случаев я, с некоторых пор, сохраняю скрин-шоты - всяк желающий может полюбопытствовать... Почему я должен полагать, что такого же количества ошибок нет и в runtime среде ПО PLC, в которую будут загружаться эти функциональные диаграммы?

 

И вот что особо интересно. Когда рекламные материалы "поют" о надёжностных характеристиках ПО PLC, то ... почему-то не принимается в учёт то, что "голый" PLC, без сопуствующего ПО человеко-машинного интерфейса (HMI) составляет не очень большую часть их общего применения... А бранды отрасли - предлпгают вместе с ПО для программирования PLC и SCADA системы, в том числе и для проетирования HMI ("всё для блага человека" ;) ). А никто не задумывался - а почему же все бранды, для эксклюзивно-надёжностных комплексов предлагают SCADA ПО ... под ОС Windows? ... у которой "период полураспада" (если её даже руками не трогать) ... 3 мес.? 6 мес.? 9 мес.? "Ваша программа выполнила недопустимую операцию, и сейчас будет прекращена на-хрен!". А надолго ли хватит на 100% функций оставшегося без "головы" PLC ... чтоб не "рвануло", как здесь кто-то переживал...

 

Вот я, прожженный и проканифоленный эмбедщик со стажем, спрашиваю себя: как я отношусь к Паскалю? Отвечаю: хорошо отношусь, и к человеку, и к языку. Зато к "ученым", много лет обгаживающим PLC индустрию, отношусь плохо.

 

А вот я, скажем, эмбедщик с заведомо не меньшим стажем ;) ... плохо отношусь к Паскалю.

Ну и что отсюда следует? кроме "предпочтений"?

Так же точно, как и "обгаживаю PLC индустрию" в её сложившемся состоянии, хотя и не "учёный"...

И что отсюда следует?

Тоже ничего... кроме "нравится/не нравится"

Так зачем нужна такая "аргументация"?

[Andrew2000 0]

Отношение такое, что java-машина используется в целой гамме современных сетевых ПЛК от разных производителей. Тенденция такая.

"от разных производителей" - и таких, про которых никто не слышал.

Приведите пример, если можно - прямую ссылку.

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

Еще попадались дипломные работы...

Ни одного известного имени.

 

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один.

один я уже привел: www.holobloc.com

хотите больше - поисследуйте здесь:

http://www.google.ru/search?hl=ru&q=Java+PLC

(есть ссылки не по теме, но есть и по теме)

На www.holobloc.com я обнаружил только "Function Block Development Kit", про ПЛК ни слова, может плохо искал?

 

Я неверно поставил вопрос - я попросил "Soft PLC под виндами не предлагать" но ниже, а сюда это тоже относиться. Так что повторю вопрос:

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один (Soft PLC под виндами не предлагать).

[Olej 0]

Я неверно поставил вопрос - я попросил "Soft PLC под виндами не предлагать" но ниже, а сюда это тоже относиться. Так что повторю вопрос:

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один (Soft PLC под виндами не предлагать).

 

Пожалуйста,

посмотрите ПО AutimationX для aXcontroller (soft PLC): там именно объекты-класы строятся под целевые (отраслевые) объекты, логика работы которых (классов) описывается (в том числе) и в МЭК, потом эти объекты могут наследоваться-укрупняться другими объектами и ... поехали.

P.S. в качестве ОС там (кроме нелюбезной вам винды) есть альтернативно: Linux & QNQ - по-моему, вполне достойный выбор на любой вкус - ПО многоплатформенное, портируемое, что нередко сейчас уже для открытых архитектур, но чего никогда не смогут себе позволить "закрытые" производители.