Средство для программирования контроллера: Си или МЭК 61131?
Первоначально опубликовано Владимир Е. Зюбин
1. Мультиязыковое программирование - это минус. В первую очередь это означает пониженные надежностные характеристики (см. соответств. исследования)
какие исследования? Мультиязыковое программирование позволяет выбирать инструменты, адекватные задаче, и описывать алгоритмы в наиболее удобном представлении. Что ведет к меньшему количеству ошибок, помогает при отладке и, в результате, ведет к более надежному коду. Если, разумеется, языки органично связаны между собой, как это сделано в МЭК.
Первоначально опубликовано Владимир Е. Зюбин
До шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в области автоматизации не наблюдалось... если программировали на релейных схемах, так это была полностью программа на релейных схемах...
Так вот кого нужно за все благодарить... :)))
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
[ Судя по всему, Вы полагаете, что для этого контроллер не нужен. И для диагностики, и для формирования исходных данных, и для фиксации событий в системе, и для упреждения аварийных ситуаций... без контроллера тут, увы не обойтись...
Просто нужно четко разделять, какие действия производятся на нижнем уровне, а какие на верхнем.
Первоначально опубликовано Владимир Е. Зюбин
Если вся логика - это пара релюшек, крайне глупо для этого ISaGRAF покупать, надо прямо релюшки и покупать. Дешево и сердито. :-)
Да и Си не нужен с Паскалем, кто ж спорит... :-)
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
Убогость выразительных средств это норма для ЛЮБОГО из т.н. графических языков. В каких-то случаях это допустимо, например в UML, а в каких-то случаях является ограничением на применение, как в случае МЭКовских SFC, LD, FBD. Не понимаю, какой смысл эти научные факты оспаривать...
Действительно, если лично для Вас "проблеммно-ориентированый" автоматически значит "убогий", какой смысл спорить - проще просто привыкнуть к жаргону :) И только лишь справедливости ради, хочу заметить, что существуют и графические языки общего назначения.
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Владимир Е. Зюбин
Вот и я про это говорю. LD sucks... когда дело касается регуляторов, средних, и пр. Также реле непригодны при организации событийных алгоритмов...
Так не стоит это делать, если не знаешь, кто "играл" с ним до этого... Иначе и не такое можно подхватить! :))
Инженер-системотехник
+7 (916) 477 3925
Первоначально опубликовано Максим Ананских
Указатели - великая вещь, а в сишной реализации - вдвойне. Не помню, как дело обстояло с 8080, давно это было... Пример навскидку:
int x = 0x0102;
printf ("%d", (int)*((char*)&x));
На интеловских процессорах это будет 2. А на Мотороле?
Пример, кстати - действующий, но "плохой": он ни на грамм не подтверждает (как и не опровергает) тезис об машинной приближённости C:
- это игрища с big/litle endian, которые давно известны, надоели, и разрешены в сетевом программировании...
- это - особенности машинного представления, не имеющие никакого отношения к языкам: нечто аналогичное можно написать на любом языке, поддерживающем указатели, том же Pascal..., более того - на языке, вообще не имеющего понятия "указатель", а только ссылки - Java, напр. ... но и этого мало ;-) - если уж очень хочется, то точно то же можно через COMMON выписать на дремучем FORTRAN, не знающем вообще понятий об указателях, ссылках, и являющимся "пользовательски" ориентированным на вычисления.
Так что - такой пример "в зачёт" принят быть не может... ;-).
P.S. Более того: если вы станете опираться на стандарт языков, а не особенности конкретных реализаций (DOS Borland C 3.1, как пример) - то не найдёте вы машиннозависимых особенностей в C...
Хотя, мне так и не понятно... - это же не имеет ровно никакого значения в контексте разговора, который вы ведёте!
Диагностика, события и языки программирования при том,
что разговор идет о проблемах создания ПО для
сложных промышленных объектов, которые имеют свойство ломаться.
Первоначально опубликовано Дмитрий Милосер
Владимир, при чем тут диагностика, события и языки программирования? :) Каким боком это связано? Только тем, что ЭТО живет в контроллере?
А вообще конечно, если смотреть сверху, то снизу кажется, что сбоку гораздо виднее. ;)
А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.
Отличный перл.
:)
:)) Никогда не делайте ничего простого и практичного, если есть способ сделать это сложным и прекрасным.
Владимир, Вам хорошо, у Вас есть установка выращивания кристаллов и Вы ее поддерживаете что есть мочи. А как быть с парнями, у которых в ТЗ прописано- реализовать в течение 2-х месяцев установку например гидрокрекинга? Сидеть в старом-добром привычном Си? Ага, с такими сроками Заказчик пошлет этих парней подальше и обратится к тем, кто на мэковских языках сделает то же самое, только быстрее. Ему, Заказчику, ждать пока сильно "вумный" и продвинутый сишный программер наколотит код код некогда- заказчики умеют считать деньги и чем быстрее они пустят установку, тем быстрее она будет давать прибыль и тем выгоднее это ВСЕМ (тем быстрее исполнитель денег получит и возьмется за другой проект и тем меньше задействует в проекте своих программистов и т.п.). А Заказчику тем быстрее потечет прибыль и быстрее окупится установка (а в сутки ее прибыль допустим N сотен тысяч долларов). Итак, в какую сторону экономический вопрос решится скорее- в комбинацию языков МЭК или в Си с Паскалем?. Теперь понятно в какую сторону и почему пошел прогресс и почему Си в АСУТП так живо отодвинулся в сторону от разработки алгоритмов управления ТП?
Поскольку мы с Вами согласны, что описываемые Вами
клоны Си, в частности понятие моделей памяти, не
являются стандартными в Си, то мое исходное утверждение
остается в силе... Лично я far и near не использую,
впрочем, не вижу ничего зазорного использовать эти
возможности в заведомо аппаратно-зависимых приложениях...
Если уж пошла такая пьянка, мы же не анализируем клоны
релейно-контактных схем... в которых проблемы с
переносимостью решаются только ручным переписыванием
текста программы...
Первоначально опубликовано Sergey Sorokin
Первоначально опубликовано Владимир Е. Зюбин
Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы.
Если хотите опровергнуть тезис, приведите операцию Си,
которая зависит от архитектуры выч.платформы. Скажем,
для 32-х разрядного Пентиум и 8-ми разрядного 8080.
Можно, конечно, ссылаться на различие длины int, но это
вопрос традиции, а не архитектуры.
Почему же они не начали традицию с 32 разрядных int? Такого рода неопределенности в спецификациях С вызывают проблемы переносимости ПО. При переходе на 64 разрядные платформы история начнется заново.
Что касается указателей, то far и near указатели классическая зависимость от x86 архитектуры. Это конечно не часть стандарта ANSI C, но часть любого компилятора для данной платформы. Когда в Small модели нужно использовать длинные указатели приходилось использовать far (и наоборот в large модели при необходимости использовать near). Библиотечные функции (скажем malloc) так же имели разные версии в зависимости от того аллокировался ближний или дальний блок. Ближний блок не мог быть по размеру больше сегмента x86 (64кбайта). MAKE_FP и т.п.
Здесь конечно виноват не С как таковой, но это показывает, что разработчиками компиляторов С позиционировался как язык системного программирования, который должен учитывать особенности конкретной архитектуры.
Поскольку мы с Вами согласны, что описываемые Вами клоны Си, в частности понятие моделей памяти, не являются стандартными в Си, то мое исходное утверждение остается в силе... Лично я far и near не использую, впрочем, не вижу ничего зазорного использовать эти возможности в заведомо аппаратно-зависимых приложениях...
Да не зацикливайтесь вы на этих платформенно зависимых дополнениях языковых средств, в частности far & near - ну нет их, нет! в стандарте языков - это только чисто реализационные добавки (всё тот же DOS Borland C 3.1), навязанные ограничениями конкретной платформы x86 real mode!
Первоначально опубликовано Владимир Е. Зюбин
Диагностика, события и языки программирования при том, что разговор идет о проблемах создания ПО для сложных промышленных объектов, которые имеют свойство ломаться.
Но я никак не пойму - как связано ПО вообще и языки МЭК (если говорить об алгоритмах управления процессом)? Для диагностики - свое ПО, через контроллер грубо (или через датчик в случае если он интеллектуален) на сигнал об отказе накладывается метка времени и код ошибки- это вообще вопрос реализации протокола, драйвера...но никак тут МЭК не завязан. Вот я с спрашиваю- с какого бока диагностика пристегнута к МЭК? В стандарте про диагностику вообще ни слова не сказано. Сложная это система или нет- не важно, важен вопрос реализованы в системе эти функции или нет. Но как правило- реализовано другими (отличными от МЭКа ) средствами. Для пользователя это- готовый софт уже встроенный или же опция. Для разработчика систем - задача, которая реализуется как правило на Си (или ассембле, как Вам больше нравится).
Т.е. еще раз - FBD, LD и пр. и диагностика, алармы и пр. "навороты" - не одно и то же.
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме
