Средство для программирования контроллера: Си или МЭК 61131?
Что Вы мне толкуете про функциональные блоки, написанные на том же Си? Давайте говорить про LD.
А то ахинея какая-то получается, понаписали блоков на
Си, вставили в LD возможность их использовать и теперь
утверждаете, что LD это "крутой" язык... Вызвать функцию на Си я и на Си могу... гораздо проще и никакой ISaGRAF
покупать не надо... 8-)
Давате уж отделять, как тут постоянно повторяется, мух
от котлет.
Моя-то позиция простая: LD - это отдельный и
самостоятельный язык стандарта МЭК 61131.3, концепция
заложенная в LD - крайне примитивна, на LD невозможно
написать практической программы без использования
инородных элементов, а эти инородные элементы на LD
создать практически невозможно. С чем Вы тут не
согласны? 8-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Я про LD говорю, а не про FBD... чего все в
кучу-то мешать?
Уважаемый Владимир! Вы, видимо, не в курсе, что LD позволяет использовать функциональные блоки? Я могу понять, что у Вас не было под рукой документа, который Вы критиковали, но прочтите же наконец, хотя бы, руководство к тому же старому IsAGraf...
Не скажу что будет Ваша конструкция печатать не только на Мотороле, но и на Интеле. Скажу только, что архитектуры 8086 и Пентиум-4 имеют значительные отличия,
и набор команд у них отличаются.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы. Если хотите опровергнуть тезис, приведите операцию Си, которая зависит от архитектуры выч.платформы. Скажем,
для 32-х разрядного Пентиум и 8-ми разрядного 8080.
Указатели - великая вещь, а в сишной реализации - вдвойне. Не помню, как дело обстояло с 8080, давно это было... Пример навскидку:
int x = 0x0102;
printf ("%d", (int)*((char*)&x));
На интеловских процессорах это будет 2. А на Мотороле?
А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.
Художника каждый может обидеть... :-)
Вы берете программу (как я догадываюсь, что-то типа уже
мелькавшего тут интерпретатора с Бэйсик), в которой
ставились цель не достичь читаемости, а достичь
компактности (а может еще и нечитаемости)... программу,
может еще и специально искаженную другим горе-критиком,
который уничтожил комментарии и исходное
форматирование... и критикуете ее, как нечитаемую. Это
некорректно. Ничего, кроме своей предвзятости, Вы этим
примером продемонстрировать не сможете.
Кстати, использование { и } вместо BEGIN и END
действительно облегчает жизнь... в четыре раза, если подсчитать число символов...
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Вы прежде чем не соглашаться, читали бы лучше внимательно. Разговор идет не о Си, а о языке на базе Си. Прочувствуйте разницу.
Не пойму тогда, ради чего весь сыр-бор? Чтобы пользователь мог писать { и } вместо BEGIN и END? Или ради вот такого:
Действительно, я просто отшучиваюсь, т.к. серьезных
возражений касательно положений и выводов статьи со
стороны оппонентов так и не прозвучало. :-)
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Кстати, про это тоже говорится: имеется непонимание
целей и области применимости стандарта МЭК 61131.3. Это
положение нужно исправлять, в частности, я попытался
сделать это через статью.
Хочу в таком случае заметить, это Вам не очень-то удалось. На мой взгляд, Вы внесли большую путаницу, что доказывается размерами получившегося флейма на пустом месте. Придется писать еще одну статью. Только, прошу Вас, прочтите сначала стандарт :)
1. Мультиязыковое программирование - это минус. В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования)
какие исследования? Мультиязыковое программирование позволяет выбирать инструменты, адекватные задаче, и описывать алгоритмы в наиболее удобном представлении. Что ведет к меньшему количеству ошибок, помогает при отладке и, в результате, ведет к более надежному коду. Если, разумеется, языки органично связаны между собой, как это сделано в МЭК.
Вы несете отсебятину. Ссылка на цитируемое исследование
мной уже приводилась... если просмотрели - ищите в этой
ветке по ключевому слову "Safety".
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
До шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была полностью программа на релейных схемах...
Так вот кого нужно за все благодарить... :)))
А я допускаю, что не в одном ISaGRAFe такая ахинея.
Т.ч. благодарить надо МЭК.
[
Судя по всему, Вы полагаете, что для этого контроллер не нужен. И для диагностики, и для формирования исходных данных, и для фиксации событий в системе, и для упреждения аварийных ситуаций... без контроллера тут, увы не обойтись...
Просто нужно четко разделять, какие действия производятся на нижнем уровне, а какие на верхнем.
Я Вам говорю про стандартное требование к надежным системам - ЛОКАЛИЗАЦИЯ ДИАГНОСТИКИ И ФИКСАЦИИ НЕИСПРАВНОСТИ.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Если вся логика - это пара релюшек, крайне глупо для этого ISaGRAF покупать, надо прямо релюшки и покупать. Дешево и сердито. :-)
Да и Си не нужен с Паскалем, кто ж спорит... :-)
Совершенно верно. И ничего смешного в законах экономики
нет.
Убогость выразительных
средств это норма для ЛЮБОГО из т.н. графических языков.
В каких-то случаях это допустимо, например в UML, а в
каких-то случаях является ограничением на применение,
как в случае МЭКовских SFC, LD, FBD. Не понимаю, какой смысл эти научные факты оспаривать...
Действительно, если лично для Вас "проблеммно-ориентированый" автоматически значит "убогий", какой смысл спорить - проще просто привыкнуть к жаргону :) И только лишь справедливости ради, хочу заметить, что существуют и графические языки общего назначения.
"Автоматически убогий" следует не из проблемной
ориентированности языкового средства, а из
метафорической основы языка LD.
Даже лень отвечать на всю всю вашу ересь, опять запахло юнешеским максимализмом. Если вы чегото незнаете лучше спросите для этого и есть конференция, а не проводите рекламную компанию. А может вы и действительно кроме МЭК ничего незнаете тогда это простительно, все приходит со временем.
На Си я напишу и пишим те программы которые нельзя написать ни на каком МЭК. Проекты на Си, выходят без всякой задержки и доводы многих что на Си писать долго и не выгодно заказчику не убедительны. Как правило проект выходит раз в месяц, что на Си что на МЭК. Выгодней пользоваться одним универсальным инструментом чем изучать кучу глупостей и терять на этом время, но это я так всеравно следишь за последними разработками а вдруг что то хорошое появится.
Ни как не пойму приверженцев узкой направленности, МЭК и все, зачем ограничивать себя одним направлением это ущербная политика. И почему не согласится, что МЭК для простых задач. Ведь все что я могу написать на Си, на МЭК повторить или даже приблизится невозможно, а необходимость программ есть и большая покрайне мере для нас.
www.sinat.ru
Если хотите поговорить о LD и событийных алгоритмах, предлагаю вернуться к рассмотрению закрытия клапана...
и без функциональных блоков, написанных на Си.
Или, просто, возьмите более-менее реальных алгоритм на
SFC+ST и попытайтесь написать его на LD.
Первоначально опубликовано Максим Ананских
Первоначально опубликовано Владимир Е. Зюбин
Вот и я про это говорю. LD sucks... когда дело касается регуляторов, средних, и пр. Также реле непригодны при
организации событийных алгоритмов...
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме