Средство для программирования контроллера: Си или МЭК 61131?
Владимир, при чем тут диагностика, события и языки программирования? :) Каким боком это связано? Только тем, что ЭТО живет в контроллере?
А вообще конечно, если смотреть сверху, то снизу кажется, что сбоку гораздо виднее. ;)
Первоначально опубликовано Владимир Е. Зюбин
А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.
Отличный перл.
:)
С уважением,
Бессонов Ян.
Первоначально опубликовано VSerg
Первоначально опубликовано Владимир Е. Зюбин
1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...
Если есть набор интструментов, то будет ли дом более надежен, если мы будем пользоваться только молотком?
Имеет смысл прочитать о мультиязыковом программировании
в профессиональных книгах по психологии
программирования, в исследованиях за которыми стоят
строгие научные эксперименты и статистика... Это же не я
придумал... и метафорами тут ничего не докажешь. Лично
для меня "молотками" и "отвертками" в языке являются его
выразительные средства...
Почитайте научные исследования. Убогость выразительных
средств это норма для ЛЮБОГО из т.н. графических языков.
В каких-то случаях это допустимо, например в UML, а в
каких-то случаях является ограничением на применение,
как в случае МЭКовских SFC, LD, FBD.
Не понимаю, какой смысл эти научные факты оспаривать...
Первоначально опубликовано VSerg
[...]
Первоначально опубликовано Владимир Е. Зюбин
2. И как это интересно на релюшках можно среднее считать?
Иначе, как вводя инородные сущности в язык, этого
делать нельзя... слишком опасно для мозга.
Считать на релюшках среднее, в наше время это шиз. конкретный. Причем шиз. на уровне постановки задачи. Это как спичкой шурупы закручивать. :)
Скорее всего последний сообщение, так как общение с некоторыми людьми не имеет конструктивной состовляющей.
Вот и я про это говорю. LD sucks... когда дело касается
регуляторов, средних, и пр. Также реле непригодны при
организации событийных алгоритмов... также "играя" с
реле можно заработать рак мозга, пытаясь какую-
нибудь самую захудалую блок-схему реализовать...
Это просто констатация, заметьте. Факт, который для меня
лично означает, что с LD лучше вообще не связываться...
кроме исключительных шиз.случаев особо оговоренных в
статье. :-)
А в общем случае мультиязыковое программирование - это всегда снижение таких качеств программы как надежность и сопровождаемость. Даже когда речь идет об использовании ассемблера в Си.
Отличный перл. :)
:)) Никогда не делайте ничего простого и практичного, если есть способ сделать это сложным и прекрасным.
Владимир, Вам хорошо, у Вас есть установка выращивания кристаллов и Вы ее поддерживаете что есть мочи. А как быть с парнями, у которых в ТЗ прописано- реализовать в течение 2-х месяцев установку например гидрокрекинга? Сидеть в старом-добром привычном Си? Ага, с такими сроками Заказчик пошлет этих парней подальше и обратится к тем, кто на мэковских языках сделает то же самое, только быстрее. Ему, Заказчику, ждать пока сильно "вумный" и продвинутый сишный программер наколотит код код некогда- заказчики умеют считать деньги и чем быстрее они пустят установку, тем быстрее она будет давать прибыль и тем выгоднее это ВСЕМ (тем быстрее исполнитель денег получит и возьмется за другой проект и тем меньше задействует в проекте своих программистов и т.п.). А Заказчику тем быстрее потечет прибыль и быстрее окупится установка (а в сутки ее прибыль допустим N сотен тысяч долларов). Итак, в какую сторону экономический вопрос решится скорее- в комбинацию языков МЭК или в Си с Паскалем?. Теперь понятно в какую сторону и почему пошел прогресс и почему Си в АСУТП так живо отодвинулся в сторону от разработки алгоритмов управления ТП?
Первоначально опубликовано Владимир Е. Зюбин
Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы.
Если хотите опровергнуть тезис, приведите операцию Си, которая зависит от архитектуры выч.платформы. Скажем, для 32-х разрядного Пентиум и 8-ми разрядного 8080.
Можно, конечно, ссылаться на различие длины int, но это вопрос традиции, а не архитектуры.
Почему же они не начали традицию с 32 разрядных int? Такого рода неопределенности в спецификациях С вызывают проблемы переносимости ПО. При переходе на 64 разрядные платформы история начнется заново.
Что касается указателей, то far и near указатели классическая зависимость от x86 архитектуры. Это конечно не часть стандарта ANSI C, но часть любого компилятора для данной платформы. Когда в Small модели нужно использовать длинные указатели приходилось использовать far (и наоборот в large модели при необходимости использовать near). Библиотечные функции (скажем malloc) так же имели разные версии в зависимости от того аллокировался ближний или дальний блок. Ближний блок не мог быть по размеру больше сегмента x86 (64кбайта). MAKE_FP и т.п.
Здесь конечно виноват не С как таковой, но это показывает, что разработчиками компиляторов С позиционировался как язык системного программирования, который должен учитывать особенности конкретной архитектуры.
С Уважением,
Сергей Сорокин
Первоначально опубликовано Mike_K
На уровне контроллеров решаются многие задачи не только AND, OR, IF, несмотрите на мир со своей "колокольни".
Здесь возразить нечего. Действительно, многие :) Но если, как я понял из Вашего письма, Вы пытаетесь засунуть операторский интерфейс, архивы, диагностику и прочее в один несчастный контроллер, когда в цивилизованном мире давно известны средства для решения этих задач - то не удивительно, что Вам тесновато в рамках МЭК и необходимы мощные средства разработки общего назначения. Да и ОСРВ не помешала бы. Зато в качестве бонуса можно зайти в конференцию и похвастаться малиновыми штанами. :) Повторюсь, я сам этим занимался когда-то, в полной мере оценив все прелести экономии на софте и железе.
Первоначально опубликовано Mike_K
Мы выяснили в этой конфе, что вы решаете примитивные задачки достойные, и не кто в этом не спорит, МЭКам.
Ну конечно, куда уж мне до Вас... Зато МЫ тут в форуме выяснили, что один из почтенных его участников сильно разочаровался в МЭКовском стандарте за то, что тот не позволил ему реализовать управление установкой Чохральского. И всердцах решил раскритиковать данный документ, забыв предварительно прочесть его дальше первой страницы. Что ж, у него это неплохо получилось :) Ну а Вы, видимо, тоже желаете получить здесь статус Действительного члена :)
Первоначально опубликовано Mike_K
Я же говорил уже тут, как вы для достижения быстродействия динамически будете менять приоритеты в МЭК.
Я, конечно же, совсем не разбираюсь в Си, но догадываюсь, что в нем есть волшебный оператор change_priority_dynamic_for_maximum_performance(), который сразу решил бы все мои проблемы, не будь я таким невежей :)
Первоначально опубликовано Mike_K
Опросить кучу датчиков с временем реакции 1сек. построить кривую это МЭК в лучшем случаи управлять не очень критичными процесами.
Как Вы узнали, что в МЭКовских языках жестко прописано минимальное время цикла в 1 секунду? До сих пор разработчики PLC надежно хранили это в тайне от пользователей!
Первоначально опубликовано Mike_K
Если вы не знаете других языков не говорите что требуется несколько месяцев кропотливой работы для выхода проекта. Нельзя быть таким ограниченным и судить о других языках о которых вы имеете поверхностное представления, судя по вашим словам.
Да, признаю: мое невежество не знает границ. Иначе бы я давно уже на надоедливый вопрос заказчика, когда же будет готов проект, отвечал бы: "Зато я знаю C, а вы - нет!" :)
Первоначально опубликовано Mike_K
Еще раз хочу сказать я не отрицаю МЭК, там где он действительно выгоден для программиста, но у нас основные задачи на Си и не куда от этого не деться.
Еще одно доказательство того, что весь спор ведется на пустом месте. Раз у Вас основные задачи на C, от этого никуда не деться. Пишите на нем и не пытайтесь обвинять оппонентов в невежестве, особенно если они с Вами согласны.
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
Я про LD говорю, а не про FBD... чего все в кучу-то мешать?
Уважаемый Владимир! Вы, видимо, не в курсе, что LD позволяет использовать функциональные блоки? Я могу понять, что у Вас не было под рукой документа, который Вы критиковали, но прочтите же наконец, хотя бы, руководство к тому же старому IsAGraf...
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы. Если хотите опровергнуть тезис, приведите операцию Си, которая зависит от архитектуры выч.платформы. Скажем, для 32-х разрядного Пентиум и 8-ми разрядного 8080.
Указатели - великая вещь, а в сишной реализации - вдвойне. Не помню, как дело обстояло с 8080, давно это было... Пример навскидку:
int x = 0x0102;
printf ("%d", (int)*((char*)&x));
На интеловских процессорах это будет 2. А на Мотороле?
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
Вы прежде чем не соглашаться, читали бы лучше внимательно. Разговор идет не о Си, а о языке на базе Си. Прочувствуйте разницу.
Не пойму тогда, ради чего весь сыр-бор? Чтобы пользователь мог писать { и } вместо BEGIN и END? Или ради вот такого:
Кстати, про это тоже говорится: имеется непонимание целей и области применимости стандарта МЭК 61131.3. Это положение нужно исправлять, в частности, я попытался сделать это через статью.
Хочу в таком случае заметить, это Вам не очень-то удалось. На мой взгляд, Вы внесли большую путаницу, что доказывается размерами получившегося флейма на пустом месте. Придется писать еще одну статью. Только, прошу Вас, прочтите сначала стандарт :)
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме