Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Когда не нужна ОС РВ?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Страницы: 1, 2, 3, 4, 5, 6, 7, 8
Olej
Вспомнилось - решил добавить:

Цитата(Evgeny_CD @ May 4 2006, 13:29) *
Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят".


- так оно того стоит! (как поётся в одной старой песне: "... за это можно всё отдать"(с)):
- объём (денежный) сегмента рынка АСУТП-автоматизации относится к объёму всего остального рынка "общекомпьютерного" применения за несколько последних лет как 4:1 (см. упоминавшуюся здесь книжку Петрова, но примерно те же цифры проскальзывают и в других источниках).
Kopa
Цитата(Olej @ May 5 2006, 10:05) *
Вспомнилось - решил добавить:

Цитата(Evgeny_CD @ May 4 2006, 13:29) *

Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят".


- так оно того стоит! (как поётся в одной старой песне: "... за это можно всё отдать"(с)):
- объём (денежный) сегмента рынка АСУТП-автоматизации относится к объёму всего остального рынка "общекомпьютерного" применения за несколько последних лет как 4:1 (см. упоминавшуюся здесь книжку Петрова, но примерно те же цифры проскальзывают и в других источниках).

Что то близкое сделал автор выполняя скрипты автоматизации на сервере используя связку
Net и Forth, а многие используют nncron скриптовый планировщик.
http://szgroup.narod.ru/NetForth/

Переизобретать велосипед не всегда имеет смысл.
=AK=
Цитата(Evgeny_CD @ May 4 2006, 19:59) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 11:35) *
К сожалению, ООП для этого класса задач просто не подходит...
У меня нет опыта работы с PLC, но из всего Вами описанного не следует неприменимость ООП в том или ином виде для решения задач PLC.

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

Цитата(Evgeny_CD @ May 4 2006, 19:59) *
сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC

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

Цитата(Evgeny_CD @ May 4 2006, 19:59) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 11:35) *

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

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

Цитата(Evgeny_CD @ May 4 2006, 19:59) *
Нда, надо будет как-нибудь революцию во всем этом PLC мире устроить.

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

Цитата(Владимир Е. Зюбин @ May 4 2006, 17:05) *
Какие из моих утверждений, Вам кажутся бредовыми?

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

Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.
Владимир Е. Зюбин
Можно ли удалять свои сообщения? Лишнее после правки появилось.
Владимир Е. Зюбин
Цитата(Evgeny_CD @ May 4 2006, 16:29) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 11:35) *
...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:
1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);
2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);
3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;
4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);
5) логический параллелизм исполнения, отражающий независимость и параллелизм процессов на технологическом объекте, активная работа с потоками управления, конвергенция, дивергенция и т.д.

К сожалению, ООП для этого класса задач просто не подходит...
У меня нет опыта работы с PLC, но из всего Вами описанного не следует неприменимость ООП в том или ином виде для решения задач PLC.
Я согласен, что в "чистом" виде С/С++/Python могут быть неудобны для технолога. Но никто не мешает сделать метаязык, который будет оперировать "правильным" объктами, и сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC приложение пойдет на чем угодно - как, как Вы заметили, этого вся и боятся.


Согласен. Рефлекс, кстати, и есть такой специализированный язык. По синтаксису похожий на Си.
Более того, текущий транслятор языка на выходе генерирует файла ня языке Си.
Написан транслятор на Си. А может быть написан и на Си++ или другом языке, да и генерировать выходные файлы он тоже мог бы на любом другом языке, хоть на Питоне. Даже интерпретатором мог бы быть. Это дело вкуса того, кто захочет реализовать язык Рефлекс.

Могу пояснить, почему был выбран Си: это первый платформонезависимый язык, который появляется на микроконтроллерах. Практически на всех, даже на "хилых", типа 51-го.

Цитата(Evgeny_CD @ May 4 2006, 16:29) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 11:35) *
Кстати, тому же LD из МЭК 61131-3 лет шестьдесят... он старее, чем Си и Питоны вместе взятые. Первые работы по нему - 40-е годы прошлого века. МЭК - это попытка стандартизации, причем, многие говорят, что при этом еще присутствовало и желание законсервировать текущее положение, т.е. конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...
Вот где собака зарыта во всей это МЭК философии!!!

Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят". Ну а поскольку конкуренты умаются переводить всего это громадье на нормальные технологии, то задача решена - можно продавать за 5k$ простенький 386EX контроллер с убогой софтиной, зато типа "супернадежный и проверенный", и, главное, с логотипом Siemens.

Нда, надо будет как-нибудь революцию во всем этом PLC мире устроить. А то они там "прижукались" и думаю, что все можно... :biggrin:


На мой взгляд, МЭК61131-3 - это типичный пример использования процесса стандартизации в конкурентной борьбе. Случай не единичный. Основные признаки такого трюка - несколько продуктов объединяются в одном стандарте (в нашем случае - пять языков), ну и члены комитета - сплошь представители мегакорпораций (в нашем случае - Сименс, АББ, Аллен-Бредли и т.д.) Со стандартом Профибас та же история... наши зарубежные коллеги его даже переименовали из Profibus в ProfiTbus.
;-)

Но, справедливости ради, нужно отметить, что сами по себе языки МЭК могут быть приемлемы и удобны. Хоть на них сложного алгоритма и не реализовать, но, недавно слышал, программы 80% ПЛК
содержат не более двадцати операторов. Такая вот специфика, в которой револючию придется делать.
Владимир Е. Зюбин
Цитата(=AK= @ May 6 2006, 08:53) *
Цитата(Evgeny_CD @ May 4 2006, 19:59) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 11:35) *

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

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


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

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

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

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

Цитата(=AK= @ May 6 2006, 08:53) *
Цитата(Владимир Е. Зюбин @ May 4 2006, 17:05) *

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

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


А чем Вас фраза "можно применять, но не эффективно" неустраивает? Где тут противоречия-то? 8-)
Многие действительно и на Си пишут, и на ассемблере. Я не возражаю и допускаю, но считаю это не всегда оправданным.

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

Цитата(=AK= @ May 6 2006, 08:53) *
Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.


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

Если Вам это кажется неубедительным - приводите свои аргументы, попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере. А вдруг, чем черт не шутит, у Вас это получится. Я посыплю голову пеплом и поставлю Вам пару бутылок пива.
=AK=
Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *
Ваши заявления про утечку памяти интересны, но неубедительны.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *
Опять Вы про этот IL и STEP5. Разумеется, у меня нет стенограмм заседаний МЭК, где представители Сименс предлагали включить IL в МЭК.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *
попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере

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

Кстати, в этой книге есть немного истории создания МЭК-овского стандарта.
Владимир Е. Зюбин
Цитата(=AK= @ May 6 2006, 12:19) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *

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

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

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

Цитата(=AK= @ May 6 2006, 12:19) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *

Опять Вы про этот 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?
Неужели Вы считаете, что причина этого в том, что это промежуточный язык Модикона и Аллен-Бредли... Подумайте, что же Вы пишете и что пытаетесь доказать.

Цитата(=AK= @ May 6 2006, 12:19) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 15:08) *

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

То есть, на IL? Вы уже оскомину всем набили своими глупыми нападками на IL.
Какие нападки, Алексей? Кто на кого нападает-то?!
Я говорю, что праобраз IL используется в Сименс, что это ассемблероподобный язык.
Что (и это очевидно) это не ассемблер и смысла в таком низкоуровневом по сути языке нет.

Цитата(=AK= @ May 6 2006, 12:19) *
Спасибо за ссылку, эту книгу я уже листал пару лет назад.
Цитата(=AK= @ May 6 2006, 12:19) *
там подробно написано какой МЭК-овский язык для чего используется. (ST+IL) в PLC образуют такую же пару, как (C+ассемблер) при программировании микроконтроллеров. Попытайтесь эмбедщиков убедить, что на С им можно писать, а на ассемблере и на смеси С+ассемблер нельзя, так вас засмеют, и правильно сделают.

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

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

Но ни то, ни другое не имеет к ситуации с МЭК никакого отношения. До платформы с помощью IL не "докопаться", и есть ST. Вполне сносный, но, увы, паскалеподобный язык. Кстати, спросите у эмбедщиков, как они к Паскалю относятся... ;-)
Andrew2000
Цитата(Владимир Е. Зюбин @ May 6 2006, 08:26) *
Со стандартом Профибас та же история...

Это какая же та же ??? Profibus - изначально Siemens. Просто Siemens сделал его IEC-ом.
Andrew2000
Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *
Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *
Сборка мусора и утечки памяти - это проблема, но не критическая, а для задач класса ПЛК и не актуальная, т.к. там не предполагается активной работы с памятью.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *
ООП - это мэйнстрим, он практически везде, и, уверен, в тех же МЭК средствах, и не только в средах разработки, но и исполнения тоже.

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



Цитата(Владимир Е. Зюбин @ May 6 2006, 13:16) *
дело в том, что IL - это не ассемблер, это просто ассемблероподобный язык, исполняющийся, как правило, под интерпретатором... к архитектуре вычислительной платформе он не имеет никакого отношения.

Назовите хотя бы одну систему IEC61131, кроме всем известного ISaGRAF, работающую в режиме интерпретатора в PLC (Soft PLC под виндами не предлагать).
Или ISaGRAF - это и есть "как правило, под интерпретатором" ?
Владимир Е. Зюбин
Цитата(Andrew2000 @ May 6 2006, 16:41) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 08:26) *

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

Это какая же та же ??? Profibus - изначально Siemens. Просто Siemens сделал его IEC-ом.
"та же" - имеется ввиду, что в стандарте описывается несколько протоколов (DP, PA, FMS), а автор стандарта - мегакорпорация.
Владимир Е. Зюбин
Цитата(Andrew2000 @ May 6 2006, 17:04) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *

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

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


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

Цитата(Andrew2000 @ May 6 2006, 17:04) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *

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

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


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

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

Цитата(Andrew2000 @ May 6 2006, 17:04) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 09:38) *

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


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


один я уже привел: www.holobloc.com
хотите больше - поисследуйте здесь:
http://www.google.ru/search?hl=ru&q=Java+PLC
(есть ссылки не по теме, но есть и по теме)

Цитата(Andrew2000 @ May 6 2006, 17:04) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 13:16) *

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

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


Тут основной момент не "интерпретатор", а связь с архитектурой платформы.
Вы правильно назвали ИнфоТим, уже упоминался holobloc, по-моему, в проекте MathPLC
java-машину используют. Про остальные не скажу. Скажу только, что интерпретатор - это наиболее удобный способ обеспечить контролируемую межплатформенную переносимость (в аппаратном смысле).
И искать нужно там, где декларируется либо многоплатформенность, либо проект делается небольшими силами (тут используются обычно ява-машины).

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

Но опять же вернусь к основной мысли: дело тут не в интерпретаторе, а в соответствии языка (IL)вычислительной платформе. Вернее, в отсутствии такого соответствия.
Владимир Е. Зюбин
По поводу интерпретаторов нашлось прямо тут на форуме, так что просто повторю:
Цитата(AlexandrY @ Jan 19 2005, 16:35) *
Я например занимаюсь адаптацией iCon-L на разные платформы.
Это нечто вроде CoDeSys, но более дружелюбная система.

В этих системах нет чистой интерпретации или компиляции.
Если компиляция то очень не оптимальная поскольку должны быть максимально независима от платформы, если интерпретация, то она может быть в виде таблицы вызовов и может работать даже быстрее чем компилированный модуль если процессор поддерживает быструю косвенную адресацию.
...
=AK=
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *
Основной из которых - эксплуатационные издержки, сопровождаемость, стоимость разработки.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *
Возможная задержка на сотню миллисекунд на "уборку мусора" для 95% приложений ПЛК роли не играет.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *
Так ничего с 1997 года не изменилось, как IL был похож на сименсовского собрата, так и остался...

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *
что это ассемблероподобный язык. Что (и это очевидно) это не ассемблер и смысла в таком низкоуровневом по сути языке нет.

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

Цитата(=AK= @ May 6 2006, 12:19) *
Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

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

Цитата(=AK= @ May 6 2006, 12:19) *
Кстати, спросите у эмбедщиков, как они к Паскалю относятся... ;-)

Вот я, прожженный и проканифоленный эмбедщик со стажем, спрашиваю себя: как я отношусь к Паскалю? Отвечаю: хорошо отношусь, и к человеку, и к языку. Зато к "ученым", много лет обгаживающим PLC индустрию, отношусь плохо.
Andrew2000
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *
Хотелось бы поменьше пафоса и побольше конструктива. Что Вас тут поразило, мне неясно.
Большинство программ для ПЛК даже не знают, что такое calloc или malloc. Я уже не говорю про малобюджетный класс ПЛК на 51-х и прочих Atmel-ах, где и диспетчера памяти-то нет... а ОЗУ всего-то
с десяток килобайтов, а то и сотня байтов.

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

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *
Но опять же вернусь к основной мысли: дело тут не в интерпретаторе, а в соответствии языка (IL)вычислительной платформе. Вернее, в отсутствии такого соответствия.

А как же Speed7 у того же Siemens/Vipa ?
(=AK= еще больше примеров привел)
Olej
Цитата
Конечно не следует. ООП в PLC почти не применяется по совсем иным причинам.


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

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

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


Я не до такой степени ковырял Сименс, но та же абсолютно история со всеми брандами... "тайна за семью печатями"... и когда меня это совсем допекло, я просто взял и "расковырял" PLC Modicon (Schneider Electric), не из старшей линейки, но и не из самой младшей 2006г. (внимание!) производства: ... AMD186 33Мгц.! - это x386, который имеет и модель защиты памяти заметно отличающуюся (по-крайней мере - несовместимую по ПО) со всеми последующими (x486/Pentium etc.). А потом в глубинах фирменной документации SE (до которых заведомо никто не доберётся) раскопал и для более старших моделей линейки Quantum: 486 100Мгц, 586 133Мгц, и т.д. Как тут не вспомнить Б.Пастернака: "... какое, милые, у нас тысячелетье на дворе?"(с).
И всё бы это было бы ничего, если бы эти PLC бодро не распродавались в 2006г. по ценам $2-$4.5 тыс.! - никто из вас не пробовал "врулить" 386SX эдак тысяч за 4 "зелёных"? wink.gif.
А какая ОС работает как runtime в любом из брандовых PLC? вот куда более сакраментальный вопрос, на который посложнее будет найти ответ! Но по ряду косвенных признаков (да и по тому, что PLC со своим runtime ведут себя идентично на процессорах с разной моделью защиты памяти) я си-и-и-льно предполагаю, что там тривиальный MS DOS... Да и не нужно им более ничего, собственно, если там крутится одна строго цикличная задача, нет асинхронной многозадачности (да и вообще нет никакой), и эта принципиальная "однонитиевость" гарантирована закрытостью PLC, и тем, что никто туда ничего не добавит...
И это не потому, как такой "плохой" SE - нет, точно та же история с PLC любого из брандов: Allan Bredley, Siemens, etc.

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

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


Да, канешно wink.gif...
Это почти дословно из Ремарка:
- В том что мы проиграли войну - виноваты евреи!
- Да, конечно, ... и велосипедисты.
- ... а почему велосипедисты?
- А почему евреи? (с).

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

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


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

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


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

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


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

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


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

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


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

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

Вот чего избегала индустрия PLC 20 лет!
Владимир Е. Зюбин
Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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

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

Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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


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

Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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


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

Будьте конструктивны. Приведите свою версию, почему в МЭК61131-3 оказался псевдоассемблер очень похожий на сименовский язык? И, ради Бога, оставьте IL в покое.
Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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


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

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


Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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

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

Цитата(=AK= @ May 6 2006, 19:51) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 18:46) *

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

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


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

А Ваши эмоции по поводу моих работ, к сожалению, не подкреплены конструктивной составляющей.
Olej
Уже не 1 раз прозвучал термин "надёжность":

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


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


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


Так об какой "надёжности" мы говорим?
1. О надёжности "железки" PLC? чем она возрасла, от того, что AMD186 процессор затолкали в ящик под названием PLC?
2. О надёжности ПО PLC (МЭК или не МЭК, как больше нравится)?
Я, вообще то, не знаю что такое надёжность ПО - в ПО нет подлежащих старению и износу частей, ... поэтому теория надёжности к нему неприменима ... хотя, как не странно, ведёт себя ПО похоже положениям теории надёжности.
3. В ПО есть ошибки, которые имеют склонность когда-то выявляться или не выявляться, тем создавая подобие "надёжности" (Э.Дейкстра: "... не бывает ПО не содержащего ошибок"(с) - Дэйкстре вы верите? wink.gif)...
Почему я должен считать, что в закрытом ПО закрытого 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 ("всё для блага человека" wink.gif ). А никто не задумывался - а почему же все бранды, для эксклюзивно-надёжностных комплексов предлагают SCADA ПО ... под ОС Windows? ... у которой "период полураспада" (если её даже руками не трогать) ... 3 мес.? 6 мес.? 9 мес.? "Ваша программа выполнила недопустимую операцию, и сейчас будет прекращена на-хрен!". А надолго ли хватит на 100% функций оставшегося без "головы" PLC ... чтоб не "рвануло", как здесь кто-то переживал...

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


А вот я, скажем, эмбедщик с заведомо не меньшим стажем wink.gif ... плохо отношусь к Паскалю.
Ну и что отсюда следует? кроме "предпочтений"?
Так же точно, как и "обгаживаю PLC индустрию" в её сложившемся состоянии, хотя и не "учёный"...
И что отсюда следует?
Тоже ничего... кроме "нравится/не нравится"
Так зачем нужна такая "аргументация"?
Andrew2000
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *
Отношение такое, что java-машина используется в целой гамме современных сетевых ПЛК от разных производителей. Тенденция такая.

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

Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *
Цитата(Andrew2000 @ May 6 2006, 17:04) *

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

один я уже привел: 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
Цитата(Andrew2000 @ May 6 2006, 18:20) *
Я неверно поставил вопрос - я попросил "Soft PLC под виндами не предлагать" но ниже, а сюда это тоже относиться. Так что повторю вопрос:
Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один (Soft PLC под виндами не предлагать).


Пожалуйста,
посмотрите ПО AutimationX для aXcontroller (soft PLC): там именно объекты-класы строятся под целевые (отраслевые) объекты, логика работы которых (классов) описывается (в том числе) и в МЭК, потом эти объекты могут наследоваться-укрупняться другими объектами и ... поехали.
P.S. в качестве ОС там (кроме нелюбезной вам винды) есть альтернативно: Linux & QNQ - по-моему, вполне достойный выбор на любой вкус - ПО многоплатформенное, портируемое, что нередко сейчас уже для открытых архитектур, но чего никогда не смогут себе позволить "закрытые" производители.
Thistle
Кстати насчёт DOS в качестве ОС Olej прав: в журнале "Современная электроника" №3 за 2006 год есть занятная статья "Концепт-микроконтроллер IPC@CHIP", так в ней прямо и написано, цитирую:"IPC@CHIP RTOS построена на базе MS DOS и совместима с ней сверху вниз. Прикладные программы , созданные для DOS , будут работать и в ОСРВ . Основные дополнения IPC@CHIP RTOS- это многозадачность и поддержка стека TCP/IP." ещё там пишут что "создание веб сервера для этого одноплатного микроконтроллера является типовой задачей." Значит рогресс действительно не стоит на месте , в том числе и в области PLC... однако он иногда движется весьм а странными путями: "Программирование такого прибора сводится к соединению с ним по FTP и загрузке нужных HTML-страниц. Динамические элементы можно реализовать через CGI, написав CGI-приложение.Через FTP происходит и "прошивка" программы на встроеный flash-диск"
Andrew2000
Цитата(Владимир Е. Зюбин @ May 6 2006, 19:08) *
Вы слишком зациклены на надежности....
В общем, не надо про надежность. Особенно в таком смехотворном стиле: "Главное - надежность, это окупает все". Для меня это прямое указание на то, что ни одно реальное ТЗ Вы в глаза не видели.
Также это указывает на то, что Вы не разу технико-экономическое обоснование не составляли, а в ВУЗе, если и был у Вас предмет по экономике, то преподавался он из рук вон плохо.

Ну, теперь прояснилось smile.gif Встретились =АК= - человек, у которого всегда на готове банка вазилина, припасенная для встречи с заказчиком, по-поводу сбоя контроллера (и чего-то) на реальном объекте,
и Зюбин - умеющий писать ТЗ, статьи, а главное - технико-экономическое обоснование, и ни разу не видевшего реальный конвеер, останов которого на 1 час окупит не один ПЛК ценой в несколько $k.
Но, видимо, никуда от этого не деться - люди близкие к производству, и сотрудники кафедр различных НИИ и учебных институтов общий язык не находят sad.gif(

Цитата(Владимир Е. Зюбин @ May 6 2006, 19:08) *
не нагнетайте панику на пустом месте. Про взрывы НПЗ и АЭС. И про сверхнадежные ПЛК.
Лучше полистайте последние номера журналов. Весь мир движется в сторону ПЛК на основе Wintel.
Это гораздо на порядок дешевле и не уступает в надежности закрытым решениям от Сименс.

гораздо на порядок дешевле - "стоит-то оно стоит, так никто-ж его не покупает" (с) к/ф Формула Любви
мир движется в сторону ПЛК на основе Wintel - а куда еще? это проще для производителя ПЛК класса "радиолюбитель" и они отберуть рынок неответственных применений у Siemens и т.д.
А в ПЛК главное предсказуемость и еще раз предсказуемость, чего в Win нет.
=AK=
Цитата(Olej @ May 7 2006, 00:48) *
Так об какой "надёжности" мы говорим?
1. О надёжности "железки" PLC? чем она возрасла, от того, что AMD186 процессор затолкали в ящик под названием PLC?

Как вершину айсберга, упомяну:
-- Наработку на отказ, которая хоть много от чего еще зависит, но на нынешнем этапе развития техники прямо связана с наличием/отсутствием движущихся частей. Поэтому "супер-пупер быстрые и дешевые" пентюхи, рассеивающие полсотни ватт, в PLC никому не нужны, т.к. без вентиляторов работать не могут. Кроме того, наработка на отказ вообще находится в обратной зависимости от температуры компонентов. Быстрее проц --> больше потребление --> выше температура --> ниже надежность. Наконец, наработка на отказ в среднем находится в обратной зависимости от сложности изделия, т.е. от кол-ва компонентов и кол-ва связей между ними. Настоящие PLC имеют наработку на отказ (MTBF) порядка 10 лет, писюки и "пионэрские" недо-PLC - примерно на порядок меньше.
-- Устойчивость к воздействию помех. Настоящие PLC примерно на порядок более устойчивы к помехам, чем бытовые писюки или недо-PLC.

Как этого добиваются разработчики PLC - даже не каждому посвященному будет видно. Что дает простор шапкозакидателям для кудахтанья: "открыл фирменный дорогущий PLC, а там такое старье стоит, сейчас мы им революцию устроим". Вы способны по внешнему виду платы сказать, работают ли какие-то ее компоненты в режимах, близких к максимально допустимым? Например, при покупке ПК, обращаете ли внимание на то, что написано на электролитах, стоящих на материнке (температура, брэнд)? И способны ли сходу оценить температурный рельеф материнки в рабочем режиме, чтобы получить оценочное представление, сдохнет ли она через пару лет из-за высыхания электролитов, или будет служить 10+ лет без проблем?

Еще мне вспоминается разговор с одним электронщиком из ЮАР, лет десять назад. Его фирма разрабатывала несложную электронику для автоматизации тех процессов, типа нормализаторов сигналов и т.п. Он рассказывал примерно так: "Вроде делаем все правильно, по науке. Смотрим, как наши конкуренты из японского Омрона делают, никакой особой разницы не видим. Начинаем испытывать на помехоустойчивость: наше устройство сбоит при 500В помехи, а омроновское - при 4кВ продолжает работать. Чудеса!" И ведь не чайник был, весьма грамотный инженер.

Цитата(Olej @ May 7 2006, 00:48) *
хотя, как не странно, ведёт себя ПО похоже положениям теории надёжности.

Я тоже так считаю. Чем сложнее - тем ненадежнее. Поэтому, если задача позволяет, в PLC лучше поставить простую однозадачную MS DOS, чем вынь или даже линукс. При этом желательно возложить на "основной" х86 проц вспомогательные задачи (связь, диагностика, и пр.), а пользовательскую прогу исполнять специализированным сопроцессором, то ли в виде PLC-on-Chip, то ли FPGA.

Цитата(Olej @ May 7 2006, 00:48) *
Почему я должен считать, что в закрытом ПО закрытого PLC Siemens, Schneider Electric, etc. ... - скрытых внутренних ошибок меньше, чем в ОС Linux или QNX

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

Цитата(Olej @ May 7 2006, 00:48) *
А надолго ли хватит на 100% функций оставшегося без "головы" PLC ... чтоб не "рвануло"

Надолго. Тем более что в грамотно спроектированной системе эта ситуация является штатной. Например, что будет, если кабель связи с верхним уровнем ненароком обрезали? Только "пионэры" проектируют системы управления без учета деградации. Рванет если у самих PLC крышу снесет, и то, правильный PLC при этом сделает все возможное, чтобы встать и оставить свои выходы в предусмотренном заранее, "безопасном" с точки зрения объекта управления, состоянии.

Цитата(Olej @ May 7 2006, 02:19) *
посмотрите ПО AutimationX для aXcontroller (soft PLC)

Вот это, что ли http://www.mnrcan.com/xtreme_qa.phtml ? И каким боком это можно назвать PLC?
Olej
Цитата(Thistle @ May 6 2006, 22:41) *
Кстати насчёт DOS в качестве ОС Olej прав: в журнале "Современная электроника" №3 за 2006 год есть занятная статья "Концепт-микроконтроллер IPC@CHIP", так в ней прямо и написано, цитирую:"IPC@CHIP RTOS построена на базе MS DOS и совместима с ней сверху вниз.


Ну молодец, Thistle, ну порадовал старика... wink.gif. Мне очень не хватало этого штришка для "замыкания картины мира"... и не в контексте этого разговора, а более широко... после 9.05.2006 мне нужно "родить" для системного интегратора "концепцию и обоснование" СУ всего транспортного узла мариупольского комбината Ильича (не слабая такая штучка) ... я и раньше "знал" wink.gif , что "не будет" там ... но вот этой медной монетки на весы не хватало, чтобы я "твёрдо знал": не будет там на дух ни Siemens-ов ни Modicon-ов...
Хватит врулять нам "стекляные бусы"!

Цитата
Прикладные программы , созданные для DOS , будут работать и в ОСРВ .


Это уже просто по поручику Ржевскому: " .... ? - пикантно, пикантно..."(с).
Ох и клоуны, ой да молодцы...
Я году в 1990-м работал с мультитаскером DOS, C-Task, кажется так это называлось... Только у них не хватало наглости называть это ОСРВ, а называли они это "библиотека". Те, кто помнят MS DOS должны помнить как это делается (хотя бы технику TSR): вручную сохраняем контекст, регистры там... , сохраняем всю область PSP (!), начинаются фокусы с Fun 52h - list of list ...
Только что-то мне подсказывает, что C-Task "намного более" wink.gif мультизадачный чем ОСРВ IPC@CHIP RTOS:

Цитата
Основные дополнения IPC@CHIP RTOS- это многозадачность и поддержка стека TCP/IP."


А что у них такое стек TCP/IP?
Какой стек? полный стек TCP/IP - это собрание "мелочей" из тысяч RFC ... Когда мне в QNX говорят, что у меня есть 2 альтернативных на выбор стека TCP/IP: tiny, с функциями такими то и такими то; или full - NetBSD ... то я знаю что такое NetBSD стек, и знаю что "более" стека, чем NetBSD - не бывает...
А здесь что? что туда включено: ARP разрешение? сегментация IP? алгоритм Нэйгла? отсроченное подтверждение? адаптивное управление окнами приёма-передачи?
А мне бранд говорит (по тех. документации): а что сочли нужным - так то и включили!
А давайте посмотрим:
- TCP/IP у них используется только как транспорт для Modbus...
- TCP/IP принципиально протокол потоковый, а Modbus - ориентирован только на фиксированные сообщения ... как?
- а так ... из всего TCP/IP там наверняка только тупая отправка пакета Modbus, "раскрашенного" заголовками TCP + IP + MAC ;(
- но в таком случае, да ещё при том, что MS DOS регулярно крутит цикл - ввод - обработка - вывод - , то достаточно всего только в этот цикл добавить: - обработка - "посмотреть что там в аппаратном буфере Ethernet лежит"- вывод - ввод - , где "посмотреть" - это просто функциональный вызов, хотя ... если функцию назвать "задача", то и многозадачность получается wink.gif ...

Modbus - это особая песня... и эту песню нужно послушать, чтобы понять, что же там происходит в "мире особых задач" (кстати, все Profibus, и CAN отчасти - все они ничуть не лучше):
- судя по всему это уродство придумал электрик по фамилии Modicon взявши первое что пришло электрику в голову (потому что 2-м - пришло бы что-то более путное), ещё такое приходит в голову с тяжёлого похмелья, по себе знаю wink.gif... это уже в то время, когда была проработана 7-ми уровневая модель ISO, методы доступа к среде MAC уровня... но электрики книжек не читают: "нам ли, товарищи, заимствовать у греков"(с)...
- потом (и на теперь) это стало "священной коровой" всея автоматчиков...
- не станем останавливаться на таком мелочном уродстве, как разграничение пакетов по тайм-ауту...
- ... но синхронный slave-master ... sad.gif
- если бы не Modbus-приверженность автоматчиков, то мы бы по уровню пром-автоматики сегодня находились бы точно не 2006г., а в 2011г. как минимум...
- и теперь, если нам нужно контролировать состояние 1000 физических шнурков, скажем, с периодом не хуже 100мс. (реально чаще) из соображений HMI верхнего уровня - то нам необходимо непрерывно (в течеии многих лет!) "молотить" непрерывно поток 10000 переменных в секунду (тут уже не важно: бит, байт - здесь уже ничего не лечит) из которых 1-на, возможно, изменится с характеристическим временем 15 мин., ... 2 часа., ... 6 часов.
- чем мы априори увеличиваем необходимый и достаточный информационный поток в ... 3600 х 10000, скажем, раз - неслабо? а потом с достоинством преодолеваем в "супер-пупер надёжной архитектуре" эти трудности...
- если бы это был, к примеру, протокол QNET я бы мог, к примеру, по ionotify() заказать меня уведомлять асинхронно, когда изменится любая из переменных...
- и не "гипотетически мог бы", а в:
http://qnxclub.net/modules.php?name=Forums...=viewforum&f=18
где-то (кому интересно - найдёт детальнее) из тем я приводил полный код приложения, делающего это - что-то около 80 строк С-кода...
- и всё это при том, что QNET (который тогда назывался FLEET) - существовал и работал за 10 лет до того, как в дурной головушке только начала зарождаться "идея" Modbus...

Могли разработчики закрытых PLC предусмотреть такие и другие возможности ... в ранних 90-х ? ... гипотетически, при несуразном предположении, что электрики иногда даже книжки читают...
Нет! не могли!
Потому что дать "такое" - это значило бы открыть протоколы и программную структуру PLC, а значит ... отказаться от "бобла", самого идущего в руки на ближайшие 20 лет...
А вот в soft PLC, любом из хороших (я о них ещё напишу ниже): WAGO, VIPA, AutomationX, и других, которых я обидел не упомянувши - реализовать подобные вещи, что "два пальца ...".
Olej
Цитата(Andrew2000 @ May 7 2006, 00:39) *
А в ПЛК главное предсказуемость и еще раз предсказуемость, чего в Win нет.


Приехали...

А у DOS-а значит - есть? то бишь "предсказуемость": в реальном режиме при однонитевом выполнении в едином и всем доступном адресном пространстве ... со всеми другими "вкусностями"...

Вам никогда не приходилось материться перед чёрным экраном висящего DOS?
Если нет - спросите у старших товарищей: как много новой лексики они усвоили за этим занятием...

При чём здесь Win? ... и при чём здесь велосипедисты?

А QNX? Вы пробовали любыми действиями завалить эту систему?
А я специально несколько лет придумывал и коллекционировал придумки как это сделать, и знаю несколько штук - это когда сильно и умышленно постараться...
Я даже подумываю такую забаву сделать: предлагать пользователю сесть за экран QNX и завалить его любыми действиями и в бесконечное время ("всё дозволено"(с)) - я коньяк ему за это выкатываю ... и "симметрично", естественно wink.gif.

Цитата
Вот это, что ли http://www.mnrcan.com/xtreme_qa.phtml ? И каким боком это можно назвать PLC?


А самым прямым боком ... разбирайтесь внимательнее: "тщательнЕе надо, ребята, тщательнЕе"(с) М.Жванецкий.
Я это вживую пощупал, может это и нужно для просветления "каким боком", но и по поверхностным описаниям, думаю, можно уловить...
Так нет же, подлецы, какую они подлянку встругнули:
- реализовав практичеки все полевые шины и протоколы...
- они теперь из шкафа Siemens (Schneider Electric, Allan Bredley, и др. - нужное подставить по вкусу) выбрасывают "к вот той маме" (где ему и место) "голову" - процессорный модуль...
- ... и вместо него тулят aXcontroller ...
- ... и весь шкаф MIO продолжает работать, так и не поняв, что голову родную ему подменили...
- и, в конце концов, фирма AtomationX вышла на Соломоново решение: а на кой хер нам ещё и широкую номенклатуру MIO производить - вон Siemens на все потребы напроизведёт ... и все они сюда подходят "по определению".

Не влезая в глубину, вот по такому примитивному формальному признаку: если PLC шкафу титулованного брэнда подменить PLC "голову", и оно всё продолжит работать и не поймёт, что его "подставили" - лепится это каким-то боком в гордое имя PLC, или не лепится?
=AK=
Цитата(Olej @ May 7 2006, 17:46) *
Modbus - это особая песня... это уже в то время, когда была проработана 7-ми уровневая модель ISO

"Не надо пороть чушь, ей же больно" (с) Первая редакция ISO/OSI вышла в 1984г, когда Модбасу исполнилось уже лет 10, наверное.

Вообще, Модбас - штука совершенно удивительная. У него, конечно, есть болячки и "родимые пятна". Однако просто поразительно, что разработчикам удалось заложить в него такие крепкие и добротные основы тогда, в далекие 70-е. Сколько после него всяких "передовых" интерфейсов возникло и сгинуло без следа, а старик все живет и здравствует. Попробуйте-ка, сваяйте свой протокольчик на RS485, и почти наверняка место ему будет на помойке, т.к. будет он сбоить безбожно, особенно в условиях индустриальных помех. И ни ISO/OSI не поможет, ни (тем более) куча RFC, которые понятием "помехоустойчивость" не оперируют вообще, просто не знают такого слова. А Модбас RTU, хоть не идеален, но с точки зрения помехоустойчивости сделан вполне правильно.

Цитата(Olej @ May 7 2006, 18:14) *
вот по такому примитивному формальному признаку: если PLC шкафу титулованного брэнда подменить PLC "голову", и оно всё продолжит работать и не поймёт, что его "подставили" - лепится это каким-то боком в гордое имя PLC, или не лепится?

Не лепится. В лучшем случае лепится имя "эмулятор", а в худшем (но более правдоподобном) - "симулятор".

Цитата(Olej @ May 7 2006, 18:14) *
Вам никогда не приходилось материться перед чёрным экраном висящего DOS?

Угу. Вы еще скажите, что это врожденная и неустранимая ошибка в функции void main(void){ } к этому приводит. Наверное, "инверсия приоритетов" в ней, или какие-то еще боковые эффекты wink.gif
Olej
Цитата(=AK= @ May 7 2006, 04:46) *
Как вершину айсберга, упомяну:
-- Наработку на отказ, которая хоть много от чего еще зависит, но на нынешнем этапе развития техники прямо связана с наличием/отсутствием движущихся частей. Поэтому "супер-пупер быстрые и дешевые" пентюхи, рассеивающие полсотни ватт, в PLC никому не нужны, т.к. без вентиляторов работать не могут.


Зато нужны, например, Geode, которые на 700-800Мгц даже не теплятся (без каких либо средств охлаждения, естественно, за ненадобностью).

Цитата(=AK= @ May 7 2006, 04:46) *
Быстрее проц --> больше потребление --> выше температура --> ниже надежность.


Так что может быть так?: быстрее проц --> меньше потребление --> ниже температура --> выше надежность.

Цитата(=AK= @ May 7 2006, 04:46) *
Наконец, наработка на отказ в среднем находится в обратной зависимости от сложности изделия, т.е. от кол-ва компонентов и кол-ва связей между ними. Настоящие PLC имеют наработку на отказ (MTBF) порядка 10 лет, писюки и "пионэрские" недо-PLC - примерно на порядок меньше.


Во-первых, "сложность" и "к-во компонентов" - это 2 большие разницы, как говорят в Одессе...
MTBF модуля SIMM 4Мб и 512Мб имеют практически одно значение, при различии в сложности (число транзисторов) в 128 раз... так что кол-во элементов имеет значение при расчётах только на одном структурном уровне, т.е. количество: чипов, плат, модулей, блоков ... как, собственно, и расчитывается MTBF в теории надёжности (или если совсем точно - там считается от обратного велличины лямбд экспоненты ... если вам приходилось это делать).

А вот на aXcontroller, к примеру, MTBF даётся 23 года sad.gif ... "а как же нам с девственностью то быть?"(с) как спрашивал академик Зельдович wink.gif...

Цитата(=AK= @ May 7 2006, 04:46) *
-- Устойчивость к воздействию помех. Настоящие PLC примерно на порядок более устойчивы к помехам, чем бытовые писюки или недо-PLC.


Так гордое имя PLC - это такая характеристика ящика?

Но, если серьёзно, то вот эта фраза (и предыдущая) ... натолкнула ...
Вы говорите "настоящие" PLC ... вы же наверняка знаете, какие это - настоящие wink.gif - просветили бы?
Если вы хотите, чтобы выяснение истинного положения вещей - было корректным (т.е. мы могли бы "корректировать" высказывания на position wink.gif), то хорошо бы объясниться (всем беседующим!) who is who ... т.е. не ФИО (которое меня мало занимает, как и вас моё), а вот так, ... "как художник художнику"(с) :
- интересы какого брэнда вам (вашей фирме) вменено представлять? ... т.е. с чего вы "кушаете"?
Тогда мы могли бы дальше обсуждать: корректно, объективнее и (!) результативнее.
Я вот, доложу, для определённости - не "кушаю" ни с одного поставщика ни железок, ни ПО. В этом нет ничего ни плохого, но и ничего хорошего ... просто это - факт, который я гарантирую ... своим словом wink.gif.
(правда иногда закрадывается мысль начать целенаправленное тестирование продукций разных изготовителей, лучше именитых wink.gif - а "кушать" с неразглашения того, что выяснится в результате ... но это уже другая песня).

Цитата(=AK= @ May 7 2006, 04:46) *
Как этого добиваются разработчики PLC - даже не каждому посвященному будет видно. Что дает простор шапкозакидателям для кудахтанья: "открыл фирменный дорогущий PLC, а там такое старье стоит, сейчас мы им революцию устроим". Вы способны по внешнему виду платы сказать, работают ли какие-то ее компоненты в режимах, близких к максимально допустимым?


Я, во многих случах - способен. За всех остальных участников беседы - не скажу wink.gif.

Но вернёмся к теории надёжности...

Цитата(=AK= @ May 7 2006, 04:46) *
Я тоже так считаю. Чем сложнее - тем ненадежнее. Поэтому, если задача позволяет, в PLC лучше поставить простую однозадачную MS DOS, чем вынь или даже линукс. При этом желательно возложить на "основной" х86 проц вспомогательные задачи (связь, диагностика, и пр.), а пользовательскую прогу исполнять специализированным сопроцессором, то ли в виде PLC-on-Chip, то ли FPGA.


Ну и почему же это лучше? поставить простую (это вы наверное дословно переводите с английского: "простой" = "убогий" = "ущербный"...?) MS DOS?.
- Выпьем же за то, что грузины лучше, чем армяне...
- Ну чем, чем лучше?
- Чем - армяне!
У Вас, ей Богу, такая же аргументация получается.

В ПО, в отличие от "железной" теории надёжности, где как мы пришли к единодушию - ничего не портится, всё определяется ошибками (т.е. там всё, что может испортиться - оно уже испорчено изначально, и стечением времени хуже не станет)... При этом действительно формально срабатывают качественные зависимости из счёта MTBF... только MTBF исходных компонент "железок" (как от которых, так и от их числа зависит результат) могут различаться ... ну в 8 раз (как вот те вольты у вашего южного африканца), а в программных компонентах ... в 1000? в 10000? в 100000? раз ... в зависимости от "вглядывания в глубину" разработчиков + методология фирмы разработчика...
И вот в результате обработчик клавиатуры, скажем, MS-DOS имеет лямбда 10**-8, а аналогичных функций модуль QNX - 10**-13. И во сколько раз же должен быть проще "простой MS-DOS" по числу модулей, чтобы сравняться с надёжностью многомодульного QNX? Помилуйте, ... тогда получается не операционная система - а "Hello world!" wink.gif ... "так долго не живут, Маша"(с).
И даже не любый вам Linux настолько кошернее любого MS-DOS, что ... ну коньяк всякому кто его завалит я не выкачу, но пиво - готов wink.gif.

Цитата(=AK= @ May 7 2006, 04:46) *
Важнее знать, что думают люди, которые проектируют системы управления, выбирают оборудование и платят за него деньги. А они, судя по всему, имеют свое мнение, противоположное Вашему или зюбинскому. Причем их мнению, имхо, доверять можно больше, т.к. за ними практика - критерий истины.


Вы мне просто не поверите wink.gif, но так совпало - что я тоже этим занимаюсь wink.gif. Вот какие бывают совпадения!
А ещё такие люди частенько приходят ко мне за советом и рекомендациями, ... и иногда даже при этом денежки несут (что совершенно превращает сотрудничесво - в идилию)...
И вот тогда мы снова с ними возвращаемся к вопросу:

Цитата(Olej @ May 7 2006, 00:48) *
Почему я должен считать, что в закрытом ПО закрытого PLC Siemens, Schneider Electric, etc. ... - скрытых внутренних ошибок меньше, чем в ОС Linux или QNX


- так что, как вы видите, я просто на 1 промежуточный ход заглянул вперёд вас, и на вопрос этот всё равно кому-то придётся отвечать wink.gif...
=AK=
Цитата(Olej @ May 7 2006, 19:45) *
Зато нужны, например, Geode, которые на 700-800Мгц даже не теплятся (без каких либо средств охлаждения, естественно, за ненадобностью).

Угу. Если при 1ГГц он рассеивает 6W, то при 0.7ГГц, конечно, "даже не теплится" wink.gif

Наверное, видели советский ВМ86? Никогда не обращали внимания, что, в отличие от i8086, у него DIP корпус был не сплошной, а состоял как бы из трех квадратиков, чем-то напоминая костяшку домино? У "фирменного" 8086 рассеивание было, помнится, 1Вт. А отечественный, в силу недостатков технологии, рассеивал чуть больше, около 1.2Вт. Так вот, при таком рассеивании "сплошной" корпус постепенно трескался вследствии термоударов при каждом включении, и проц сдыхал раньше времени. Тогда какой-то умелец (снимаю шляпу!) предложил делать "прорези" в кропусе, чтобы уменьшить тепловой стресс. Даже "фирменный" при 1Вт был горячий...

Цитата(Olej @ May 7 2006, 19:45) *
Цитата(=AK= @ May 7 2006, 04:46) *

Вы способны по внешнему виду платы сказать, работают ли какие-то ее компоненты в режимах, близких к максимально допустимым?

Я, во многих случах - способен.

"В чем секрет вашего мастерства?" (с) Может быть, техническая эзотерика вкупе с многолетней медитаций? smile.gif

Ладно, шутки шутками, но пора завязывать треп. Все это совершенно бесплодно. Тянутся такие разговоры аж с 60-х годов, со времен первых "кавалерийских наскоков" ЭВМ-щиков на пром автоматику. В конце 60-х появились PLC, только они оказались способны надежно работать в цеховых условиях и заменить релейные шкафы. И в 70-е тоже пытались "ЭВМ в цеха" ставить, и в 80-е, и даже с частичным успехом, однако в среднем - не прижились. С моей точки зрения, softPLC ничего в этом раскладе не меняют, и никакого нового слова не говорят. Еще одна реинкарнация пром-РС, которые появились всего-то на несколько лет позже самих писюков, и раздавали те же самые обещания. А заглянешь в цех серьезного завода (скажем, автомобильного) - где они? Нету. Стоят у любых более-менее серьезных пацанов в цехах на ответственных местах AB. Вот у виноделов, говорят, действительно, всякий сброд встречается, и Сименс, и Мицубиши, и даже Адвантек. Вы же на железнодорожниках своих поэксперементируйте, они стерпят, они и не такое терпели.
733259
Цитата
Ладно, шутки шутками, но пора завязывать треп. Все это совершенно бесплодно. Тянутся такие разговоры аж с 60-х годов, со времен первых "кавалерийских наскоков" ЭВМ-щиков на пром автоматику. В конце 60-х появились PLC, только они оказались способны надежно работать в цеховых условиях и заменить релейные шкафы.
Чем, ну чем устройство на AMD186, под DOS-ом не ЭВМ! Где коренное отличие от других, неужели бренд сам по себе придаёт надёжности в "цеховых условиях"!
Olej
Цитата(733259 @ May 7 2006, 17:28) *
Чем, ну чем устройство на AMD186, под DOS-ом не ЭВМ! Где коренное отличие от других, неужели бренд сам по себе придаёт надёжности в "цеховых условиях"!


Вот именно об этом же и речь!
Устройство на AMD186, под DOS-ом - это вне всяких сомнений ЭВМ, и цена такой ЭВМ в самый буйный базарный день $100 ... ну ещё $5 набросим за MS DOS.
А коренное отличие в "цеховых условиях" и кроется в том, что аппологеты брэндовости втюхивают это потребителям (а это косвенно - всем вам/нам, со всеми иже с ними пенсионерами и немощными...) за $4500... не всегда из чисто теоретических предпосылок, правда wink.gif.
Вот, собственно, и всё коренное отличие.
Andrew2000
Цитата(Olej @ May 6 2006, 20:49) *
Пожалуйста,
посмотрите ПО AutimationX для aXcontroller (soft PLC):

Спасибо за ссылку, посмотрю.
А я пока старался ориентироваться на это:
http://www.triconex.com/us/eng/triconexPro...con/default.htm
http://www.invensys.ru/triconex/live/page.asp?pid=8547
(а может кто эти контроллеры живьем видел - какие впечатления?)
Andrew2000
Цитата(Olej @ May 7 2006, 12:16) *
Modbus - это особая песня... и эту песню нужно послушать, чтобы понять, что же там происходит в "мире особых задач" (кстати, все Profibus, и CAN отчасти - все они ничуть не лучше):

С чем сравниваем Profibus и CAN?
Не надо больше про Modbus, это все равно, что сейчас обсуждать - какая маленькая и тяжелая оперативная память на магнитных барабанах получается (Modbus на RS485), а про Modbus-TCP и говорить не интересно - это просто тянется как порт RS232 в современных ноутах - через переходник на USB.

Цитата(Olej @ May 7 2006, 12:16) *
... это уже в то время, когда была проработана 7-ми уровневая модель ISO, методы доступа к среде MAC уровня...

А кто реально пользуется этими абстрактными 7-ю уровнями? TCP/IP - нет, Profibus - нет, протоколы на CAN-е - нет (точнее на картинках пытаются натянуть свои уровни на ISO), может QNet? проясните - я его не знаю (если не ошибаюсь - ему тоже 7 уровней не нужны - он вроде только в локальной сети)
А как у QNet-а с доступом к среде MAC уровня? Тут два варианта - либо как у Profibus (что хорошо), либо как у TCP/IP (что плохо), как у CAN не выйдет - физика не позволит.

Цитата(Olej @ May 7 2006, 12:16) *
- не станем останавливаться на таком мелочном уродстве, как разграничение пакетов по тайм-ауту...

Что Вы имеете в виду? А как организовать многомастерность на шине? Как в Ethernet - не годится, а как в Profibus, CAN - вполне.

Цитата(Olej @ May 7 2006, 12:16) *
- если бы это был, к примеру, протокол QNET я бы мог, к примеру, по ionotify() заказать меня уведомлять асинхронно, когда изменится любая из переменных...

Никто Вам это не мешает сделать ни в Profibus, ни в CanOPEN, например.

Цитата(Olej @ May 7 2006, 12:16) *
А вот в soft PLC, любом из хороших (я о них ещё напишу ниже): WAGO, VIPA, AutomationX, и других, которых я обидел не упомянувши - реализовать подобные вещи, что "два пальца ...".

VIPA - soft PLC??? раскажите! я всегда считал, что они Speed7 используют.
WAGO - возможно это CoDeSys RTOS-расжирение (опечатался, но исправлять не стал smile.gif) под винды, ну так WAGO производителями PLC никогда и не были - тока-тока освоили модное направление - soft PLC на Wintel-е.
(про AutomationX еще не прочитал...)
Andrew2000
Цитата(Olej @ May 7 2006, 12:44) *
Приехали...
А у DOS-а значит - есть? то бишь "предсказуемость": в реальном режиме при однонитевом выполнении в едином и всем доступном адресном пространстве ... со всеми другими "вкусностями"...
Вам никогда не приходилось материться перед чёрным экраном висящего DOS?
При чём здесь Win? ... и при чём здесь велосипедисты?

Да, в DOS есть, а в Win нет. И самое страшное это виртуальная память и отложенные прерывания.
А ошибки есть везде.

Цитата(Olej @ May 7 2006, 12:44) *
А QNX? Вы пробовали любыми действиями завалить эту систему?

Завалить с клавиатуры - и пытаться не буду, а ошибкой в программе (той самой - Soft PLC) не сомневаюсь, что можно, и даже QNX4. Но не в этом дело. Заваливать систему и не надо, достаточно если ядро выгрузит зависшую задачу SoftPLC - внешне от DOS-системы это ничем не отличается.
Может я старомоден, но я себя чувствую комфортно, только если могу посчитать на калькуляторе поведение системы, т.е. время реакции.
Я это могу сделать в Profibus (не путать с Profinet), в CanOpen. Могу сделать в PLC c многозадачной ОС, где нет виртуальной памяти, есс-но учитывая максимальное количество прерываний.
Возможно, в современных условиях это в большинстве случаев не актуально, т.к. 1ГГц пень на все с большой вероятностью среагировать успеет, не то, что PLC на 20МГц Siemens-е где это надо рассчитывать.
Но я уверен, что большинство именитых PLC работают под управлением именно многозадачных ОС (не многопроцессных, т.е. с единым адресным пространством).
=AK=
Цитата(733259 @ May 7 2006, 23:58) *
Чем, ну чем устройство на AMD186, под DOS-ом не ЭВМ! Где коренное отличие от других,

Надежностью отличается.
Цитата(733259 @ May 7 2006, 23:58) *
неужели бренд сам по себе придаёт надёжности в "цеховых условиях"!

Как это ни смешно... Хороший брэнд означает школу, т.е. аккумулированный и систематизированный многолетний опыт в предметной области, базирующийся на результатах труда поколений (хорошо оплачиваемых) инженеров. Еще он означает ответственность, которая вытекает из стабильности фирмы.
Andrew2000
Цитата(=AK= @ May 7 2006, 13:05) *
Попробуйте-ка, сваяйте свой протокольчик на RS485, и почти наверняка место ему будет на помойке,

Ну, у Siemens он называется Profibus, у B&R - Mininet - до недавнего времени не плохо жили smile.gif



Цитата(Olej @ May 7 2006, 21:38) *
Устройство на AMD186, под DOS-ом - это вне всяких сомнений ЭВМ, и цена такой ЭВМ в самый буйный базарный день $100 ... ну ещё $5 набросим за MS DOS.
А коренное отличие в "цеховых условиях" и кроется в том, что аппологеты брэндовости втюхивают это потребителям (а это косвенно - всем вам/нам, со всеми иже с ними пенсионерами и немощными...) за $4500...

Я думаю, что потребитель, покупающий что-то типа triconex, которому нужна электромагнитная совместимость, или/и защита от помех, или/и -40+85'C, корпус с каким-нить IP, и управлять ответственным производством, и т.д. - выложит $k и даже смотреть не будет на чем (каком ЦПУ) этот контроллер сделан.
А если пользователю достаточно надежности офисного ПК, то глупо платить за контроллер больше чем за офисный ПК + SoftPLC.

А вот и веточка соответствующая нашлась smile.gif
http://electronix.ru/forum/index.php?showtopic=7377&hl=
733259
Цитата
Надежностью отличается.
Немного странно, что надёжность железа PLC в этой дискуссии служит аргументом против Рефлекса и др. "новых веяний" ("кавалерийских наскоков" ЭВМ-щиков). Существуют же "нормальные" промышленные компьютеры, неужели они недостаточно надёжны? Интересны аргументы апологетов PLC против (только для примера) http://www.nnz-ipc.ru/cgi-bin/main.pl?mode...&uid=1147065267
http://www.nnz-ipc.ru/html.news/wincon_8x4x.html

ЗЫ: А вот вообще круть (ИМХО) http://www.nnz-ipc.ru/html.news/lincon.html
Olej
Цитата(=AK= @ May 7 2006, 04:46) *
Цитата(Olej @ May 7 2006, 02:19) *

посмотрите ПО AutimationX для aXcontroller (soft PLC)

Вот это, что ли http://www.mnrcan.com/xtreme_qa.phtml ? И каким боком это можно назвать PLC?


Это вы смотрите совсем что попало wink.gif ...
Вот:
http://automationx.com/produkte/eprodukte.php?area=3
Olej
Цитата
С чем сравниваем Profibus и CAN?
Не надо больше про Modbus, ...


Здесь возникла путаница ... которую отчасти я и создал, потому как слишком поспешил вперёд, не объяснив о чём это я...

Все СУ, которые попадают под "сферу интересов" PLC можно поделить, чисто условно и по-верхам, на:
1. системы автономные + локальные - когда все алгоритмы управления жёстко описаны на все случаи жизни, вмешательство в работу управляющего алгоритма не требуется и даже вредно, а объект управления целиком локализован ... ну, в пределах нескольких десятков, пусть малых сот, метров.
Примеры:
- СУ металло-обрабатывающего центра;
- СУ автоматизированной конвейерной линии;
2. системы не автономные + локальные, когда есть пульт-мнемосхема оператора, который вмешивается, до противного асинхронно, в работу...
Примеры:
- недавно видел описание в журнале завершённой системы - СУ всеми агрегатами тепловоза, оператор может вмешаться, и одновременно с штатной работой запустить программу полной диагностики, например, тяговых агрегатов;
- то же, наверное, СУ всех силовых агрегатов морского судна, чем занимается, к примеру, НПО "Аврора", которые для этого развили технологию switch-программирования школы Шалыто, о чём здесь упоминали...
3. системы не автономные + не локальные (территориально распределённые), когда расстояния между отдельными узлами сбора и обработки составляют от единиц до десятков и сотен километров.
Примеры:
- СУ всеми береговыми маяками Ирлпндии - сделана под RealFlex;
- СУ безопасности движения тунелей и виадуков Австрии + Швейцарии: 120 тыс. точек управления, ~4000 км. общая протяжённость - сделана под AutomationX;
- СУ безопасности железнодорожного и паромного движения Новой Зелландии: общая протяжённость ~4000 км. ... что интересно: выполнялась отделением Siemens, которое отказалось от использования Siemens продукции, и сделали под RealFlex...

Меня интересуют на сейчас системы класса "3".

"Вниз" обмен, когда PLC использует для обмена с модулями DIO 16 или 32 точки: Modbus, Profibus, ... CAN, ... что хотите - здесь всё проще, и ... может быть.

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

Вот здесь и выясняется, что, например, что "мировой бранд" Modicon/Schneider может предложить "вверх" только slave Modbus over TCP/IP... И так будет в любой закрытой PLC архитектуре, потому как:
- не может такой производитель "допустить" какие-то специфичные и развитые протоколы в свою архитектуру извне...
- а если бы и мог ... то опять же не смог wink.gif - потому что такие взаимодействия требуют очень развитой асинхронности (параллелизма задач), а у производителя так ... пс-с-с-с: MS-DOS, в котором и те что есть фиксированные компоненты и то еле вместе держатся и не разваливаются...

Цитата
А кто реально пользуется этими абстрактными 7-ю уровнями? TCP/IP - нет,


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

Вот тот же Modbus over TCP/IP: типичный протокол прикладного уровня - Modbus -> TCP -> IP -> MAC.
Когда утверждается, что Modbus обеспечивал евиданную помехоустойчивость, пусть на RS-485 физической среде ... у меня это возбуждает огромное любопытство: какие же это поля в пакете протокола - ответственны за помехоустойчивость? я, в роде, как истоптал этот формат вдоль и поперёк, драйверы его писал ... ну не вижу, не вижу я там форматности, хоть как-то повышающем помехоустойчивость по сравнению с любым пыонэрским протоколом ... может к окулисту надо?
Да и не дело это прикладного протокола - отвечать за помехоустойчивость.

Цитата
А как у QNet-а с доступом к среде MAC уровня? Тут два варианта - либо как у Profibus (что хорошо), либо как у TCP/IP (что плохо), как у CAN не выйдет - физика не позволит.


Не понял я здесь ни вопроса, ни утверждения... sad.gif
QNET - протокол уровня транспорта, который может работать (по желанию) хоть над MAC-уровнем, хоть над IP-уровнем.

Цитата
Никто Вам это не мешает сделать ни в Profibus, ни в CanOPEN, например.


Мешает, потому как кроме возможности протокола асинхронно (т.е. со slave, если хотите) отправлять сообщения - нужна ещё программная реализация на стороне сервера (того же slave-ва) что уведомлять? на что реагировать? как? - чего в закрытой PLC реализации сделать нельзя.
Olej
Цитата(733259 @ May 8 2006, 08:25) *
Немного странно, что надёжность железа PLC в этой дискуссии служит аргументом против Рефлекса и др. "новых веяний" ("кавалерийских наскоков" ЭВМ-щиков).


Я не увидел здесь противопоставление "против" как и "наскоков" особенно... (хотя может не туда смотрел? wink.gif).
Вопрос немного другой: открытый/закрытый PLC?
Если он закрытый - то принцип один: "жри что дали", и если дали МЭК (или даже его подмножество, что бывает), то ни о чём "сверх" обсуждать не приходится - никакого Рефлекса туда затолкать нет возможности физически, значит не о чем говорить...

Цитата(733259 @ May 8 2006, 08:25) *
Существуют же "нормальные" промышленные компьютеры, неужели они недостаточно надёжны?


Существуют. И в хорошем исполнении их надёжность не ниже брандовых PLC.
Но здесь есть своя тонкость:
- у любого PC (промышленного или нет) - не может быть "от рождения" каналов для ввода/вывода 1000 дискретных сигналов... (а 1000 - это, в общем, и близкая к минимальной цифра);
- значит их нужно "сделать", например приткнув туда PCI-адаптер Profibus, на который повесить стандартный набор Siemens MIO...
- плюс для них драйверов или сделать или навесить (в лучшем случае - использовать целевые средства типа ISaGRAF, CoDeSys, ... или тех же AutomationX)...
Но вот на этом "приткнуть" и "навесить" ("с миру по сосенке"(с)) - можно сильно растерять всю надёжность.

Цитата(Andrew2000 @ May 8 2006, 01:24) *
Да, в DOS есть, а в Win нет. И самое страшное это виртуальная память и отложенные прерывания.


Нет. И в Win нет, и в DOS нет wink.gif
А "страшных факторов" намного больше, чем вы назвали, и не эти самые страшные: виртуализации памяти, например, ни одна RTOS просто не используют, не имеют на это права.

Цитата(Andrew2000 @ May 8 2006, 01:24) *
А ошибки есть везде.


Конечно. Разница только в том, что в некоторых местах их - мало, в других - много, а в некоторых (DOS тот же) - валом.

Цитата(Andrew2000 @ May 8 2006, 01:24) *
Завалить с клавиатуры - и пытаться не буду, а ошибкой в программе (той самой - Soft PLC) не сомневаюсь, что можно, и даже QNX4.


Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а wink.gif.

Цитата(Andrew2000 @ May 8 2006, 01:24) *
Но не в этом дело. Заваливать систему и не надо, достаточно если ядро выгрузит зависшую задачу SoftPLC - внешне от DOS-системы это ничем не отличается.


Отличается. Принципиально.
Задача, аварийно завершившаяся по SIGSEGV - это совершенно другое, чем заваливание системы: задача в которой это произошло может быть снова поднята-запущена монитором HAM (посмотрите эту технику), а заваленная система уже ничем (даже сторожевой таймер здесь на 100% не помощник - падающая задача/система могли напакостить в аппаратных установках периферии, и восстановит только сброс питания).

Цитата(Andrew2000 @ May 8 2006, 01:24) *
Может я старомоден, но я себя чувствую комфортно, только если могу посчитать на калькуляторе поведение системы, т.е. время реакции.


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

Цитата(=AK= @ May 8 2006, 01:19) *
Как это ни смешно... Хороший брэнд означает школу, т.е. аккумулированный и систематизированный многолетний опыт в предметной области, базирующийся на результатах труда поколений (хорошо оплачиваемых) инженеров. Еще он означает ответственность, которая вытекает из стабильности фирмы.


=AK=, я же вас просил, а вы не уважили...
Назовите этого "хорошего" брэнда, вы же его знаете wink.gif - а нас держите в неведении.

Цитата(Andrew2000 @ May 8 2006, 01:24) *
Я думаю, что потребитель, покупающий что-то типа triconex, которому нужна электромагнитная совместимость, или/и защита от помех, или/и -40+85'C, корпус с каким-нить IP, и управлять ответственным производством, и т.д. - выложит $k и даже смотреть не будет на чем (каком ЦПУ) этот контроллер сделан.
А если пользователю достаточно надежности офисного ПК, то глупо платить за контроллер больше чем за офисный ПК + SoftPLC.


А я нигде и не говорил, что разумный пользователь не готов разумно платить за соответствующее устройство...
Вот тот же aXcontroller - стоит порядка 3900 евро, ... это то же самое, что процессорный модуль Schneider Electric, или чуть меньше, чем Siemens...
Только 1-й - хорош, и предоставляет большую гибкость, а 2-е и 3-е - в сравнении с ним - отстой... за те же деньги.
Вопрос то не в том, чтоб дёшево "из дерьма слепить конфетку", но и не в том, чтобы сорить деньгами на ветер, только потому, что этот ветер - брэндовый.
733259
Цитата
Вопрос немного другой: открытый/закрытый PLC?
Если он закрытый - то принцип один: "жри что дали", и если дали МЭК (или даже его подмножество, что бывает), то ни о чём "сверх" обсуждать не приходится - никакого Рефлекса туда затолкать нет возможности физически, значит не о чем говорить...
Вот-вот, интересно - есть какие-то резоны в пользу того же сименса со Step 7 против более открытых решений типа
http://www.nnz-ipc.ru/html.news/wincon_8x4x.html
http://www.nnz-ipc.ru/html.news/lincon.html
(в то, что процесс ISaGRAF почему-то не получит таймслайса из-за "плохой асинхронности" - "Не верю"(с))
Andrew2000
Цитата(Olej @ May 8 2006, 11:46) *

PC/104 + Windows XP Embedded ?
Ну, тогда это то же самое, что и
http://www.nnz-ipc.ru/html.news/lincon.html

Пардон, но расскажите, пожалуйста, что конкретно Вас здесь привлекло - я ничего интересного не обнаружил sad.gif

А то тоже получается, что старье "700MHz PIII CPU" пытаются впарить за $k smile.gif
Andrew2000
Цитата(Olej @ May 8 2006, 13:28) *
Здесь возникла путаница ... которую отчасти я и создал, потому как слишком поспешил вперёд, не объяснив о чём это я...

Да, замешали мы все и всё в одну кучу smile.gif
Есть предложение - может Владимир Зюбин создаст на форуме отдельную ветку для обсуждения Рефлекса? У меня есть желание задать вопросы по языку.

А к Вам просьба - расскажите (или ссылками) про QNet - как я понял протокол закрытый, но хоть что-то про него известно... а то как его обсуждать...

Цитата(Olej @ May 8 2006, 13:28) *
... выполнялась отделением Siemens, которое отказалось от использования Siemens продукции, и сделали под RealFlex...

еще одна "кучка"? вроде RealFlex это чистая СКАДА, или уже тоже + SoftPLC?

Цитата(Olej @ May 8 2006, 13:28) *
"Вниз" обмен, когда PLC использует для обмена с модулями DIO 16 или 32 точки: Modbus, Profibus, ... CAN, ... что хотите - здесь всё проще, и ... может быть.

Совершенно точно.

Цитата(Olej @ May 8 2006, 13:28) *
В отношении возможностей и протоколов обменов - я имел в виду обмен "вверх": между различными PLC, входящими в систему...
Вот здесь и выясняется, что, например, что "мировой бранд" Modicon/Schneider может предложить "вверх" только slave Modbus over TCP/IP...
И так будет в любой закрытой PLC архитектуре, потому как:
- не может такой производитель "допустить" какие-то специфичные и развитые протоколы в свою архитектуру извне...
- а если бы и мог ... то опять же не смог

Ну, Siemens тут Profinet (открытый) у B&R свой протокол (забыл как называется), кто-то использует TCP или UDP, многие ModbusTCP...
А чем тут Qnet лучше? (ну, этот вопрос я уже выше задал).

Цитата(Olej @ May 8 2006, 13:28) *
Цитата

А как у QNet-а с доступом к среде MAC уровня?

Не понял я здесь ни вопроса, ни утверждения... sad.gif
QNET - протокол уровня транспорта, который может работать (по желанию) хоть над MAC-уровнем, хоть над IP-уровнем.

"QNET - протокол уровня транспорта", может быть, но, ему необходим и какой-то низ (пусть из другого стандарта), но какой?
Т.е. интересует - что использует QNET для разрешения коллизий в сети; Profibus - логическое кольцо, CAN - случайный доступ с разрешением.
Поэтому Profibus и CAN называют промышленными, а Ethernet с TCP/IP - нет (про Ethernet можно вспомнить EtherCAT).

Цитата(Olej @ May 8 2006, 13:28) *
Цитата

Никто Вам это не мешает сделать ни в Profibus, ни в CanOPEN, например.

Мешает, потому как кроме возможности протокола асинхронно (т.е. со slave, если хотите) отправлять сообщения - нужна ещё программная реализация на стороне сервера...

Не мешает. Посмотрите протокол CanOPEN - там это все разрисовано.
Andrew2000
Цитата(Olej @ May 8 2006, 14:21) *
Нет. И в Win нет, и в DOS нет wink.gif
А "страшных факторов" намного больше, чем вы назвали, и не эти самые страшные: виртуализации памяти, например, ни одна RTOS просто не используют, не имеют на это права.

А я что писал? - "SoftPLC под Win не предлагать!"

Цитата(Olej @ May 8 2006, 14:21) *
Цитата

А ошибки есть везде.

Конечно. Разница только в том, что в некоторых местах их - мало, в других - много, а в некоторых (DOS тот же) - валом.

В DOS ошибки? ну это если только Вы сами их туда привнесете (создатель SostPLC т.е.).
Если я не ошибаюсь - DOS - это загрузчик + сервисы (через прерывания) для работы с диском. точка

Цитата(Olej @ May 8 2006, 14:21) *
Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а wink.gif .

Вызову какой-нить сервис ОС из обработчика сигнала (например ошибку в лог-файл записать) - ?

Цитата(Olej @ May 8 2006, 14:21) *
Цитата(Andrew2000 @ May 8 2006, 01:24) *

... внешне от DOS-системы это ничем не отличается.

Отличается. Принципиально.
Задача, аварийно завершившаяся по SIGSEGV - это совершенно другое, чем заваливание системы: задача в которой это произошло может быть снова поднята-запущена монитором HAM (посмотрите эту технику), а заваленная система уже ничем (даже сторожевой таймер здесь на 100% не помощник - падающая задача/система могли напакостить в аппаратных установках периферии, и восстановит только сброс питания).

HAM и WDT - это одно и то же (для системы) - пакость в аппаратуре HAM не восстановит.

Цитата(Olej @ May 8 2006, 14:21) *
Цитата(Andrew2000 @ May 8 2006, 01:24) *

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

Это было бы слишком просто... Беда в том, что это можно сделать только для относительно простых систем.

Хотя бы для простых, а в SoftPLC и для простых нельзя. (Не простых в смысле управления кофеваркой, а в смысле объема кода).



Цитата(733259 @ May 8 2006, 15:12) *
Вот-вот, интересно - есть какие-то резоны в пользу того же сименса со Step 7 против более открытых решений...
(в то, что процесс ISaGRAF почему-то не получит таймслайса из-за "плохой асинхронности" - "Не верю"(с))

Кому что нравиться.
Про "таймслайса", например в Siemens вообще вопроса не возникнет, т.к. IEC-программу отрабатывает отдельный CPU ничем более не нагруженный.
=AK=
Цитата(Olej @ May 8 2006, 18:58) *
потому что такие взаимодействия требуют очень развитой асинхронности (параллелизма задач)

Вот в этом и дело, а не в "мировом сговоре МЭК с мегакорпорациями". Чем выше эта асинхронность (на одном проце), тем ниже надежность. Поэтому PLC стараются ее вообще не допускать, насколько возможно. Синхронно они работают, или почти синхронно. Здесь напрашивается аналогия с синхронным/асинхронным стилями разработки для ПЛИС. Не то чтобы асинхронно нельзя было бы сделать в принципе, можно, однако настоятельно рекомендуется его всеми силами избегать и делать все синхронно.

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

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

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

Такие сравнительно простые псевдосинхронные системы, как PLC, могут быть протестированы досконально, и ведут себя предсказуемо. Потому что в синхронных системах "исчезает ось времени", все события происходят "одновременно". В отличие от softPLC и RTOS, что бы там маркетологи ни плели про их надежность.

Для верхнего уровня распределенных систем чаще всего не трeбуется та надежность, которaя необходима "внизу", где работают PLC. Xотя бы из-за низкой надежности связи, а также из-за меньшей требуемой реактивности. Однако для них и softPLC непонятно зачем был бы нужeн, там "PLC-шность" и языки МЭК неуместны, имхо.

Цитата(Olej @ May 8 2006, 19:51) *
Назовите этого "хорошего" брэнда

Я же явственно назвал Аллен-Брэдли, нарочито обозвав остальных "сбродом". smile.gif

PS: Вы так выдeляeтe QNX в плане надежности, объясните, почему это oна надежнее DOS или той же Выни? Или она с открытым кодом (пока что только это выдавалось за волшебную палочку), а я просто не в курсе? C учетом того, что Вынь в ~80% случаев падает за счет хреновых драйверов (написанных бог весть кем, не мелкомягкими), расскажите, как в QNX пишутся драйверы, и за счет чего они будут безошибoчными. Или почему ошибки в драйверах не будут ронять QNX, хотя Линукс от них не то что падает, а частенько даже и не встает smile.gif Может, в QNX все драйверы юзер мод, с кучей проверок? A как же с реактивностью быть? Чем для писателей кернел мод драйверов любая ось отличается от DOS-a (ведь правда не знаю, может, не догоняю чего-то)?
Владимир Е. Зюбин
Цитата(Andrew2000 @ May 6 2006, 20:00) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *

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

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

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


Я лично говорю о реализации функций автоматического управления и использовании при этом средств ООП, в данном случае java.

Цитата(Andrew2000 @ May 6 2006, 20:00) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *

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

А как же Speed7 у того же Siemens/Vipa ?
(=AK= еще больше примеров привел)


Примеры тут ни при чем, тут надо стандарт смотреть, и там отыскивать фразу типа "ассемблером ПЛК должен быть язык IL"... а такой фразы там нет. Так что, пожалуйста, не надо больше примеров.
Владимир Е. Зюбин
Цитата(Olej @ May 6 2006, 20:12) *
Цитата
...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:


Да, канешно wink.gif...
Это почти дословно из Ремарка:
- В том что мы проиграли войну - виноваты евреи!
- Да, конечно, ... и велосипедисты.
- ... а почему велосипедисты?
- А почему евреи? (с).

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


Разумеется, задачи автоматизации можно делить и дальше, но канализационный автоматчик гораздо лучше понимает железнодорожного, а вот у неавтоматчика с пониманием могут возникнуть проблемы... примеры неавтоматчиков - специалист по базам данных, обработке изображений, суперкомпьютерам и т.д. А вот хороший автоматчик должен и в этих темах разбираться, хотя бы поверхностно.
=AK=
Цитата(Olej @ May 8 2006, 18:58) *
в ... PLC реализации сделать нельзя.

Цитаты из NI,
чтобы яснее понимать области применимости:

Experts from ARC, Venture Development Corporation (VDC), and the online PLC training source PLCS.net estimate that:
* 77% of PLCs are used in small applications (less than 128 I/O)
* 72%of PLC I/O is digital
* 80%of PLC application challenges are solved with a set of 20 ladder-logic instructions

The PC presented three main challenges:
1. Stability: Often, the PC’s general-purpose operating system was not stable enough for control. PC-controlled installations were forced to handle system crashes and unplanned rebooting.
2. Reliability: With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure.
3. Unfamiliar Programming Environment: Plant operators need the ability to override a system for maintenance or troubleshooting. Using ladder logic, they can manually force a coil to a desired state, and quickly patch the affected code to quickly override a system. However, PC systems require operators learn new, more advanced tools.
Владимир Е. Зюбин
Цитата(Andrew2000 @ May 6 20060, 21:20) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *

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

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

Надеюсь, Вы не будете обижаться, если я только ключевые слова дам:
SNAP, AJILE, NET-MASTER, TINI.

"никто не слышал" я лично воспринимаю как признание, что просто Вы не слышали.
Страусиная позиция, пардон.

Цитата(Andrew2000 @ May 6 20060, 21:20) *
Цитата(Владимир Е. Зюбин @ May 6 2006, 16:17) *

Цитата(Andrew2000 @ May 6 2006, 17:04) *

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

один я уже привел: www.holobloc.com
хотите больше - поисследуйте здесь:
http://www.google.ru/search?hl=ru&q=Java+PLC
(есть ссылки не по теме, но есть и по теме)

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

Я неверно поставил вопрос - я попросил "Soft PLC под виндами не предлагать" но ниже, а сюда это тоже относиться. Так что повторю вопрос:
Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один (Soft PLC под виндами не предлагать).


holobloc.com - это сайт по МЭК61499, тут уже не о ПЛК речь идет, а о ГПС на основе ПЛК.
Вы меня простите великодушно, но Вашим образованием я заниматься не буду. Я привел ссылку, если Вы не верите, или там не можете чего-нибудь найти, не обращайтесь ко мне, пожалуйста.

А вообще, про ПЛК Вы плохо искали, ищите про МЭК 61131-3.
=AK=
Цитата(Владимир Е. Зюбин @ May 10 2006, 13:58) *
Примеры тут ни при чем, тут надо стандарт смотреть, и там отыскивать фразу типа "ассемблером ПЛК должен быть язык IL"

Отсутствие какой-то фразы не может служить оправданием ваших домыслов. Идите с такими аргументами, мелкомягким доказывайте, что MSIL не имеет права на существование, т.к. .NET исполняется на машинах, ассемблером которых MSIL не является.

Кстати, не надейтесь, что излишнее цитирование придаст веса вашим высказываниям. Оно лишь свидетельствует, что вы не способны отделить главное от второстепенного.
Olej
Цитата(Andrew2000 @ May 8 2006, 19:35) *
Цитата(Olej @ May 8 2006, 14:21) *

Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а wink.gif .

Вызову какой-нить сервис ОС из обработчика сигнала (например ошибку в лог-файл записать) - ?


Не поможет cheers.gif
Даже SIGSEGV не вызовет с завершением задачи, не то, чтоб ущерб системе нанести...
P.S. Кстати, в POSIX/UNIX давно уже сигналы используются не только как средства предсмертной экстремальной реакции, но как нормальное средство асинхронного взаимодействия задач, в котором можно очень многое делать, почти всё, особенно в QNX... Это только малых детей перед сном продолжают сигнальными обработчиками пугать по старой памяти...

Даже из обработчика IRQ если вызовете, то ... в зависимости как обработчик построен (там как минимум 2 принципиально раздичных пути) - и то, возможно, свой лог благополучно запишите...

А "сервисов ОС" в QNX - нет, там микроядерная архитектура: микроядро - критично, его объём что-то не более 64К, отработанных 25 лет, практически не меняется... всё остальное - в том числе и драйверы - это нечто сродни пользовательским задачам... здесь кто-то спрашивал с иронией - так это действительно так.

P.S. напомню, что в x86 protected mode есть 4 кольца защиты: 0 - 3, если вы помните, все распространённые ОС считают достаточным использовать из них только 2: 0 и 3 - супервизор и пользователь... В QNX отдельные компоненты и задачи могут использовать все 4 кольца, так что говорить здесь о пользовательском и превилегированном режиме ... это как-то сильно условно.
Но, более того - QNX многоплатформенная ОС, более 10 разных аппаратных архитектур, однотипно (один и тот же код портируется, за исключением микроядра) использующая (ОС) особенности архитектуры (например MMU) на каждой из платформ.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.