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

Первоначально опубликовано Доктор Q <SPAN class=bold>Владимир Е. Зюбин </SPAN>В данном случае, я просто произнес очевидные вещи, которые много раз видел в той же самой конференции Чем повторять свои и чужие бредни, ознакомьтесь с авторитетными материалами. Для начала прочтите http://www.searcheng.co.uk/selection/control/Articles/IEC61131/main.htm, которая освещает затронутые в Вашей статье вопросы, но, в отличие от Вас, со знанием дела, правдиво и без паранойи: The main reasons for developing the IEC 61131-3 standard were... The major new features offered by IEC 61131-3 are... На этом обсуждение темы треда считаю законченным. От сторонников С (то бишь, противников МЭК) никаких серьезных доводов услышать не довелось, вместо аргументов ими приводилось личное, зачастую невежественное,  мнение.

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

Разные языки ориентированы на решение разных типов задач.
Не рискну сказать, что фильтр Калмана оптимально делать на МЭК-61131.

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

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

evgen Покажите мне реализацию на том, чего вы так агрументированно обосновываете... Ну например:
Zlib,
JpegLib,
lpng,
tcpip стека,
IFS,
разнообразных серверов (прокси, почтовых и т.п.),
Круговую, линейную интерполяцию, реализацию алгоритма брозенхейма и ему подобные, статистические функции, БФП.

Мне очень странно видеть такой вопрос при обсуждении темы

Средство для программирования контроллера

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

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

В этом примечательном документе обратите внимание на цели, которые ставили перед собой создатели первых ПЛК. Надежность была ключевым фактором, в этом было главное отличие ПЛК от прочей выч. техники. MTBF в 50 тыс часов не так уж просто получить даже сейчас.

Со временем к ПЛК стали относить разные устройства, вплоть до промышленных РС. К сожалению, не все устройства, называемые ныне "ПЛК" достойны этого имени, среди них много "примазавшихся", "маскирующихся" под ПЛК, пытающихся (в корыстных целях) воспользоваться доброй репутацией, заработанной ПЛК.

Если скомбинировать одноплатную РС с УСО, то можно сделать устройство, внешне похожее на ПЛК. Его тоже можно назвать контроллером, однако про надежность такого устройства ничего заранее сказать почти невозможно, оно может быть надежным, а может быть и нет. Это зависит от многих причин.

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

И опять - бабушка надвое сказала.  

Если на этом устройстве поставлен, например, ISaGRAF, и пользователь запрограммировал свою задачу на МЭКовских языках - то, скорее всего, управление объектом будет так же надежно, как если бы им управлял настоящий ПЛК.

Если же Вы заставили пользователя писать на С - то Вы, наверное, знаете, что будет в типичном случае: очень долгая отладка, огромное количество багов, которые потом годами будут вылезать из разных щелей, и т.д.

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

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

Возвращаясь к Вапшему вопросу. Если Вам в контроллере почему-то надо Zlib, JpegLib, lpng, tcpip стека, IFS и пр., а при этом Вы (пользователь) купили контроллер, в котором этого нет - то Вы выбросили деньги на ветер.

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

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

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

 

Первоначально опубликовано Доктор Q Мне очень странно видеть такой вопрос при обсуждении темы <FONT face=Arial color=green size=3>Средство для программирования контроллера Я не знаю что Вы подразумеваете под контроллером, с моей точки зрения, в контексте тематики конференции под контроллером надо понимать ПЛК.

Это ваши личные трудности. Берите словари и ищите там слово
Контроллер/controller

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

Большая часть того, что я навскидку перечислил - относится к прикладному программированию.

Первоначально опубликовано Доктор Q Чтобы лучше представлять, что такое ПЛК, целесообразно обратиться к истории их создания http://www.barn.org/FILES/historyofplc.html В этом примечательном документе обратите внимание на цели, которые ставили перед собой создатели первых ПЛК. Надежность была ключевым фактором, в этом было главное отличие ПЛК от прочей выч. техники. MTBF в 50 тыс часов не так уж просто получить даже сейчас.

ну и что из этого следует ? У простого кирпича MTBF может быть и больше и то, при условии, что поблизости нет дяди с ломом.

Первоначально опубликовано Доктор Q Со временем к ПЛК стали относить разные устройства, вплоть до промышленных РС. К сожалению, не все устройства, называемые ныне "ПЛК" достойны этого имени, среди них много "примазавшихся", "маскирующихся" под ПЛК, пытающихся (в корыстных целях) воспользоваться доброй репутацией, заработанной ПЛК. Если скомбинировать одноплатную РС с УСО, то можно сделать устройство, внешне похожее на ПЛК. Его тоже можно назвать контроллером, однако про надежность такого устройства ничего заранее сказать почти невозможно, оно может быть надежным, а может быть и нет. Это зависит от многих причин. Предположим, железо этого "внешне похожего на ПЛК" устройства оказалось достаточно надежным, таким же надежным как железо настоящего ПЛК. Поставим его управлять объектом и сравним с ПЛК, будет ли оно так же надежно, как ПЛК? И опять - бабушка надвое сказала. Если на этом устройстве поставлен, например, ISaGRAF, и пользователь запрограммировал свою задачу на МЭКовских языках - то, скорее всего, управление объектом будет так же надежно, как если бы им управлял настоящий ПЛК. Если же Вы заставили пользователя писать на С - то Вы, наверное, знаете, что будет в типичном случае: очень долгая отладка, огромное количество багов, которые потом годами будут вылезать из разных щелей, и т.д.

У меня пользователи только нажимают на кнопки. И программировать они никогда ничего не будут.

Первоначально опубликовано Доктор Q Только не надо мне рассказывать сказок про "надежное ПО на С". Какие-то программы получаются надежно, какие-то так всю жизнь и работают с багами. Сравните хотя бы Вынь и Линукс - оба написаны на С.

Во-первых, не только на С, во-вторых, виндуз частично написан на бейсике, в-третьих, сказочки про что-то там высоконадежное оставьте маркетологам. Отдельный высоконадежный ПЛК или ПС или кирпич или болт никому не нужен.Нужна система. (а) Работающая и (б) надежная. Надежная но неработающая также даром никому не нужна.

Первоначально опубликовано Доктор Q Системное ПО приходится писать на С, чаще всего другого выбора нет. Соответственно, системное ПО пишется мучительно долго, с багами и кровью. Заставлять пользователя ходить по этим же граблям при написании прикладного ПО - вот это и будет тот самый ИДИОТИЗМ, о котором долго вопил Зюбин.

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

Первоначально опубликовано Доктор Q Возвращаясь к Вапшему вопросу. Если Вам в контроллере почему-то надо <FONT color=#0000ff>Zlib, JpegLib, lpng, tcpip стека, IFS и пр., а при этом Вы (пользователь) купили контроллер, в котором этого нет - то Вы выбросили деньги на ветер.

Я просто буду покупать контроллер, к которому есть компилятор Си. Если через некоторое время скажем, встанет задача, поддерживать вавы или мпеги, то я просто найду соответвующую библиотеку и портирую ее на/под свой конкретный контроллер (скорей всего это будет 32битный ДСП)

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

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

Первоначально опубликовано Доктор Q Лучше купите контроллер, в системное ПО которого уже входят все нужные Вам программные элементы, который уже может работать с Ethernet, и т.д. В конце концов, tcpip стек, почтовый сервер, и пр. - это "внутренняя кухня" системного ПО, не тратьте время на то чтобы изобрести велосипед и кое-как сделать заново то, что давно сделано хорошо.

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

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

Такого Брозенхейма, которого нужно мне - однозначно нет. Конкретно - Брозенхейм с фиксированной скоростью ортисовки

SY,
EK

Владимир Е. Зюбин Писал человек, который не знает, что такое структурное программирование

Чья бы корова мычала...

http://www.searcheng.co.uk/selection/control/Articles/IEC61131/page2.htm

About the author:

Robert Lewis is the UK expert on two IEC working groups defining the PLC programming language standard (IEC 61131-3) and developing a new standard for Function Blocks for modelling distributed control systems. He is a Fellow of the Institute of Electrical Engineers and has been concerned with the development of control systems for a wide range of industrial applications for over 15 years.

Вот посмотрел опять эту конференцию и АХнул, ну ни как Доктор Q : не хочет понимать ни какие доводы. Тяжелый случай. Обычно человек так яростно отстаивая одну точку зрения (свою) имеет ограниченный кругозор. Как правило это поправимо если еще пацан, ну а если вырос это надолго. Не втом не вдругом случае, нестоит писать много букв остальные все поняли, как видно. Владимир Е. Зюбин дай бог вам терпения, ну ни счем не соглашается Доктор Q . Я же говорил похоже на юнешеский максимолизм, возможно пройдет. Предагаю закрыть тему. Все равно ушли от темы конференции.

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

В дальнейшем можно обсудить и FAQ.

И просьба не обижайте вы С++ и ТСР/IP  работаем мы с ними не жалуемся в частности на I-8000 под ДОСом контроллеры крутятся, ну МЭК для простых задач на других контроллерах, то же не брезгуем.

Давайте жить дружно!!!