Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Архив
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

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

 Ответить Ответить Страница  <1 3435363738 53>
Автор
Сообщение
Guests Смотреть выпадающим
Гость
Гость
Свойства публикации Свойства публикации   Ответить, цитируя автора - Guests Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Средство для программирования контроллера: Си или МЭК 61131?
    Опубликовано: 21 Октябрь 2003 15:44

Владимир, при чем тут диагностика, события и языки программирования? :) Каким боком это связано? Только тем, что ЭТО живет в контроллере?

А вообще конечно, если смотреть сверху, то снизу кажется, что сбоку гораздо виднее. ;)

 

Наверх
bessonov Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 07 Август 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 108
Свойства публикации Свойства публикации   Ответить, цитируя автора - bessonov Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 15:49
Первоначально опубликовано Владимир Е. Зюбин


А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.


Отличный перл.
:)
С уважением,
Бессонов Ян.
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 16:01
Первоначально опубликовано VSerg

Первоначально опубликовано Владимир Е. Зюбин


1. Мультиязыковое программирование - это минус.
В первую очередь это означает пониженные надежностные
характеристики (см. соответств. исследования) До
шиз. интерпретации МЭК 61131.3 в ИЗоГРАФе, такого в
области автоматизации не наблюдалось... если
программировали на релейных схемах, так это была
полностью программа на релейных схемах...

Если есть набор интструментов, то будет ли дом более надежен, если мы будем пользоваться только молотком?


Имеет смысл прочитать о мультиязыковом программировании
в профессиональных книгах по психологии
программирования, в исследованиях за которыми стоят
строгие научные эксперименты и статистика... Это же не я
придумал... и метафорами тут ничего не докажешь. Лично
для меня "молотками" и "отвертками" в языке являются его
выразительные средства...

Почитайте научные исследования. Убогость выразительных
средств это норма для ЛЮБОГО из т.н. графических языков.
В каких-то случаях это допустимо, например в UML, а в
каких-то случаях является ограничением на применение,
как в случае МЭКовских SFC, LD, FBD.

Не понимаю, какой смысл эти научные факты оспаривать...

Первоначально опубликовано VSerg


[...]
Первоначально опубликовано Владимир Е. Зюбин


2. И как это интересно на релюшках можно среднее считать?
Иначе, как вводя инородные сущности в язык, этого
делать нельзя... слишком опасно для мозга.


Считать на релюшках среднее, в наше время это шиз. конкретный. Причем шиз. на уровне постановки задачи. Это как спичкой шурупы закручивать. :)

Скорее всего последний сообщение, так как общение с некоторыми людьми не имеет конструктивной состовляющей.


Вот и я про это говорю. LD sucks... когда дело касается
регуляторов, средних, и пр. Также реле непригодны при
организации событийных алгоритмов... также "играя" с
реле можно заработать рак мозга, пытаясь какую-
нибудь самую захудалую блок-схему реализовать...

Это просто констатация, заметьте. Факт, который для меня
лично означает, что с LD лучше вообще не связываться...
кроме исключительных шиз.случаев особо оговоренных в
статье. :-)
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Guests Смотреть выпадающим
Гость
Гость
Свойства публикации Свойства публикации   Ответить, цитируя автора - Guests Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 16:17

Первоначально опубликовано bessonov

Первоначально опубликовано Владимир Е. Зюбин


А в общем случае мультиязыковое программирование - это
всегда снижение таких качеств программы как надежность и
сопровождаемость. Даже когда речь идет об использовании
ассемблера в Си.


Отличный перл.
:)

:)) Никогда не делайте ничего простого и практичного, если есть способ сделать это сложным и прекрасным.

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

 

  

Наверх
Sergey Sorokin Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 27 Март 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 240
Свойства публикации Свойства публикации   Ответить, цитируя автора - Sergey Sorokin Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 18:54
Первоначально опубликовано Владимир Е. Зюбин

Указатели великая вещь, только они никак не связаны с архитектурой целевой платформы.

Если хотите опровергнуть тезис, приведите операцию Си,
которая зависит от архитектуры выч.платформы. Скажем,
для 32-х разрядного Пентиум и 8-ми разрядного 8080.

Можно, конечно, ссылаться на различие длины int, но это
вопрос традиции, а не архитектуры.


Почему же они не начали традицию с 32 разрядных int? Такого рода неопределенности в спецификациях С вызывают проблемы переносимости ПО. При переходе на 64 разрядные платформы история начнется заново.

Что касается указателей, то far и near указатели классическая зависимость от x86 архитектуры. Это конечно не часть стандарта ANSI C, но часть любого компилятора для данной платформы. Когда в Small модели нужно использовать длинные указатели приходилось использовать far (и наоборот в large модели при необходимости использовать near). Библиотечные функции (скажем malloc) так же имели разные версии в зависимости от того аллокировался ближний или дальний блок. Ближний блок не мог быть по размеру больше сегмента x86 (64кбайта). MAKE_FP и т.п.

Здесь конечно виноват не С как таковой, но это показывает, что разработчиками компиляторов С позиционировался как язык системного программирования, который должен учитывать особенности конкретной архитектуры.

С Уважением,

Сергей Сорокин

 

Наверх
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 20:27
Первоначально опубликовано 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
Наверх
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 20:45
Первоначально опубликовано Владимир Е. Зюбин

Я про LD говорю, а не про FBD... чего все в
кучу-то мешать?
Уважаемый Владимир! Вы, видимо, не в курсе, что LD позволяет использовать функциональные блоки? Я могу понять, что у Вас не было под рукой документа, который Вы критиковали, но прочтите же наконец, хотя бы, руководство к тому же старому IsAGraf...
Инженер-системотехник
+7 (916) 477 3925
Наверх
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 20:53

Первоначально опубликовано Владимир Е. Зюбин

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

Указатели - великая вещь, а в сишной реализации - вдвойне. Не помню, как дело обстояло с 8080, давно это было... Пример навскидку:

int x = 0x0102;

printf ("%d", (int)*((char*)&x));

На интеловских процессорах это будет 2. А на Мотороле?

Инженер-системотехник
+7 (916) 477 3925
Наверх
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 21:00

Первоначально опубликовано Владимир Е. Зюбин


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

Не пойму тогда, ради чего весь сыр-бор? Чтобы пользователь мог писать { и } вместо BEGIN и END? Или ради вот такого:

#include <stdio.h>
main (int t, int _, char *a)
{
return!0<t?t<3?
main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):1,t<_?main(t+1,_,a)
:3,main(-94,-27+t,a)&&t==2?_<13?main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?
main(_,t,"@n'+,#'/*s{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/# ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/")
:t<-50?_==*a?putchar(31[a]):
main(-65,_,a+1):
main((*a=='/')+t,_,a+1):
0<t?main(2,2,"%s")
:*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"
),a+1);
}

Инженер-системотехник
+7 (916) 477 3925
Наверх
Максим Ананских Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 14 Май 2003
Online Status: Offline
Публикации: 770
Свойства публикации Свойства публикации   Ответить, цитируя автора - Максим Ананских Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 21 Октябрь 2003 21:06

Первоначально опубликовано Владимир Е. Зюбин


Кстати, про это тоже говорится: имеется непонимание
целей и области применимости стандарта МЭК 61131.3. Это
положение нужно исправлять, в частности, я попытался
сделать это через статью.

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

Инженер-системотехник
+7 (916) 477 3925
Наверх
 Ответить Ответить Страница  <1 3435363738 53>

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz