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

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

 Ответить Ответить Страница  <1 2930313233 53>
Автор
Сообщение
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Средство для программирования контроллера: Си или МЭК 61131?
    Опубликовано: 19 Октябрь 2003 17:06
Первоначально опубликовано Владимир Е. Зюбин


1. Никто на Паскаль не нападал. Критиковался его выбор в
качестве базы для одного из языков МЭК-стандарта. Выбор
в качестве основы Си выглядит куда более
предпочтительным... и именно в силу специфики Си.

Я и не имел в виду "нападки", или не сумел сказать так как хотел: хотелось подчеркнуть различную целевую направленность этих языков.

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


Более того, не побоюсь высказать крайне
дискуссионную мысль: факт использования Си как языка
трансляции Паскаля говорит о том, что Паскаль это,
скорее, уже умирающий язык. :-(

А здесь нет ничего "дикуссионного", и тем более "крайне"...
Конечно, Pascal, в том виде, как он сформулирован Н.Виртом - это не только умирающий, а уже умерший язык... А в том виде, в какой он трансформировался в Delphi или Kylix (как он, в чертях, пишется... ;-)) - так это просто "одоробло" (Чтоб потом не отвечать на возмущённые реплики адептов, сразу объясняю, почему "одоробло": потому, что язык - это органичная конструкция, в него нельзя произвольно наталкивать то, что понравилось "в другом месте" - именно так всегда развивался BASIC. В противном случае - язык эклектичный, и содержит в себе внутренние противоречия, которые вылезают в конкретных применениях. Так именно и случилось в Borland - это не моё утверждение, а Н.Вирта).

Так вот далее. Pascal, конечно, мёртвый язык. Ктати, у нас (назовём это СНГ) - он задержался дольше, чем в других местах, более популярен. На то есть причины:

- косность высшей школы, которая как заладила как "попка дурак" преподавание на Pascal в поздние 70-е, так и долдонит это дальше... (ведь проще долдонить заученный курс, чем учить новое, да ещё в бедственных условиях, в которых находится высшая школа).

- традиционная приверженность наших программистов Borland. Это началось ещё со времён DOS Borland C 3.1 - я сам на это долго "подсел". За рубежом Borland во многих регионах был почти неизвестен, тем временем, как у нас - используем повсеместно. А потом ... Delphi - и, по традиции, - восхваление, что "Borland это cool"... А на то, что действительно блестящая школа компиляторщиков Borland к тому времени ушла и делала TopSpeed Modula-2 - внимание не обратили, а к тому времени в Borland работали уже подёнщики..., которые гораздо лучше понимали рынок, но гораздо хуже - компиляторы.

Но утверждение "Pascal мёртв" ни в коей мере нельзя относить к Pascal языковой линии! Хотя бы одно то, что существует и активно развивается язык ADA, в том числе и free в GNU проекте GNAT... есть мощное русскоязычное сообщество GNAT. Плюс "виртовская" линия Modula - Oberon...


Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


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

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


1. Никто на Паскаль не нападал. Критиковался его выбор в
качестве базы для одного из языков МЭК-стандарта. Выбор
в качестве основы Си выглядит куда более
предпочтительным... и именно в силу специфики Си.

Я и не имел в виду "нападки", или не сумел сказать так как хотел: хотелось подчеркнуть различную целевую направленность этих языков.


То, что Паскаль и Си имеют некоторую специфику -
несомненно. Тезис, который я отстаивал: в силу специфики
языка и предметной области для МЭК технически более
грамотным было бы выбрать в качестве основы для ST - Си.

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


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


Более того, не побоюсь высказать крайне
дискуссионную мысль: факт использования Си как языка
трансляции Паскаля говорит о том, что Паскаль это,
скорее, уже умирающий язык. :-(

А здесь нет ничего "дикуссионного", и тем более "крайне"...
Конечно, Pascal, в том виде, как он сформулирован Н.Виртом - это не только умирающий, а уже умерший язык...
[...]
Но утверждение "Pascal мёртв" ни в коей мере нельзя относить к Pascal языковой линии! Хотя бы одно то, что существует и активно развивается язык ADA, в том числе и free в GNU проекте GNAT... есть мощное русскоязычное сообщество GNAT. Плюс "виртовская" линия Modula - Oberon...


Есть по этому поводу такая забавная ссылка...

http://www.tiobe.com/tiobe_index/index.htm

Примечательно, что по моим собственным оценкам,
ситуация примерно схожая: "Паскаль-линия" более чем на
два порядка менее распространена по сравнению с "Си-
линией"... к коей я отношу и Си++, и Java, и С#...
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
bessonov Смотреть выпадающим
Действительный член
Действительный член


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

[QUOTE=Olej] [QUOTE=Владимир Е. Зюбин]

Тезис, который я отстаивал: в силу специфики
языка и предметной области для МЭК технически более
грамотным было бы выбрать в качестве основы для ST - Си.


Разработчики МЭК 61131 тоже знали о языке С и С++, но по каким-то причинам выбрали ST(аля Паскаль). Будем же относиться к ним с уважением и примем на веру, что для этого были веские причины. Возможно например:
1. Паскаль в изучении проще, чем С
2. от крутых программеров слышал, что Паскаль (Delphi) очень удобен для БОЛЬШИХ поектов, т.к. программа на Паскале, в силу специфики компиляторов компилируется гораздо быстрее, чем программа на С и С++.

Какова же цель стандарта МЭК 61131?
Рискну сказать:
автоматизация БОЛЬШИНСТВА (т.е. не ВСЕХ) АСУ ТП,
с минимальными издержками, в т.ч.
обучение персонала за минимальное время, разработка и отладка алгоритмов за минимальное время.

Именно по этой причине в МЭК 61131 есть НЕСКОЛЬКО ПРОСТЫХ в изучении языков. Разные производители реализуют МЭК 61131 по разному -- в соответствии со своей коммерческой стратегией.

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

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


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 19 Октябрь 2003 20:20
Первоначально опубликовано Владимир Е. Зюбин


Есть по этому поводу такая забавная ссылка...
http://www.tiobe.com/tiobe_index/index.htm

Примечательно, что по моим собственным оценкам,
ситуация примерно схожая: "Паскаль-линия" более чем на
два порядка менее распространена по сравнению с "Си-
линией"... к коей я отношу и Си++, и Java, и С#...


Интересная ссылка...
И вот в других аспектах тоже, см. "Delta 1 Year" - т.е. прирост использования (первая цифра - "Ratings" - абсолютный рейтинг, чтоб не заставлять всех лазить по таблице):

Perl - 17.8 - +15.9%
Python - 3.2 - +66.7% ... выше, чем у:
C# - 4.1 - +39.2%
- у которого и так необоснованно высокую динамику я бы объяснил только тем, что эта динамика исчисляется от крайне низкой абсолютной цифры 4.1...
Awk - 1.4 - +17.5%

А чем меня заинтересовали именно эти позиции таблицы? А тем, что они имеют непосредственное, хотя может и не так прямо выраженное отношение к основному предмету разговора:

- Perl - Python - Awk - это интерпретирующие языковые системы (хорошо известные и преимущественно используемые в мире UNIX);
- в синтаксическом смысле - это языки, которые абсолютно отрицают такие понятия, как контроль типов, структурность и т.д. (хотя в последнем Perl введена даже объектность, но это больше по содержанию, а синтаксически это достаточно притянутая объектность)...
- это языки - ориентированы именно на очень быстрое и продуктивное исполнение ПО в специализированных областях, для которых они предназначены (напр. Perl - основан как интерпретирующий! язык системного программирования UNIX, я сам его очень люблю в таком качестве, хотя в последние 5-7 лет он гораздо известнее широкой общественности как яык написания CGI скриптов для HTML).

Это в точности соответствует обсуждавшемуся выше - для быстрого и разового исполнения целевого ПО в каждой области (АСУТП в том числе не исключение) разумно иметь и специализированные, в чём то и упрощённые языки решения задач целевой сферы.
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


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

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

Тезис, который я отстаивал: в силу специфики
языка и предметной области для МЭК технически более
грамотным было бы выбрать в качестве основы для ST - Си.


Разработчики МЭК 61131 тоже знали о языке С и С++, но по каким-то причинам выбрали ST(аля Паскаль). Будем же относиться к ним с уважением и примем на веру, что для этого были веские причины. Возможно например:
1. Паскаль в изучении проще, чем С
2. от крутых программеров слышал, что Паскаль (Delphi) очень удобен для БОЛЬШИХ поектов, т.к. программа на Паскале, в силу специфики компиляторов компилируется гораздо быстрее, чем программа на С и С++.


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

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


Какова же цель стандарта МЭК 61131?
Рискну сказать:
автоматизация БОЛЬШИНСТВА (т.е. не ВСЕХ) АСУ ТП,
с минимальными издержками, в т.ч.
обучение персонала за минимальное время, разработка и отладка алгоритмов за минимальное время.

Именно по этой причине в МЭК 61131 есть НЕСКОЛЬКО ПРОСТЫХ в изучении языков. Разные производители реализуют МЭК 61131 по разному -- в соответствии со своей коммерческой стратегией.


Я совершенно с Вами согласен... и постоянно повторяю,
что МЭК-языки ориентированы на низкоквалифицированных
пользователей и крайне простые алгоритмы. Может таких
простых задач и большинство, но сложные задачи это тоже
реальность. МЭК 61131-3 создает искусственный барьер
между простыми и сложными задачами, а также между
узкоспециализированными задачами.

Если МЭК об этой проблеме молчит, то он не прав и его
нужно поправить... что и сделано в статье.

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


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

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


К сожалению, мы не занимаемся выращиванием лопаток для
реактивных двигателей. Мы занимаемся выращиванием
монокристаллов кремния методом Чохральского.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


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


[...]
Это в точности соответствует обсуждавшемуся выше - для быстрого и разового исполнения целевого ПО в каждой области (АСУТП в том числе не исключение) разумно иметь и специализированные, в чём то и упрощённые языки решения задач целевой сферы.


С тезисом о специализации - полностью согласен, а вот с
упрощением нужно быть очень осторожным...

Если, скажем, LD что-то и упрощает, то нужно понимать,
что он упрощает, и за счет чего, и где у этого подхода
ограничения наступают... да, LD достоточно просто
изучить, но запрограммировать на нем что-то серьезное -
практически невозможно... да и несерьезное невозможно
тоже: скажем, тот же ПИД-регулятор... или расчет
среднего... и т.п.
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
bessonov Смотреть выпадающим
Действительный член
Действительный член


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



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


Анализа не проводилось?
Ваш перл похож на чёрный юмор.

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


Я совершенно с Вами согласен... и постоянно повторяю,
что МЭК-языки ориентированы на низкоквалифицированных
пользователей и крайне простые алгоритмы. Может таких
простых задач и большинство, но сложные задачи это тоже
реальность. МЭК 61131-3 создает искусственный барьер
между простыми и сложными задачами, а также между
узкоспециализированными задачами.


Если вы не делали сложных проектов на МЭК 61131, то это не значит, что их ни кто не делает. Опрометчивое и не профессиональное утверждение.
С уважением,
Бессонов Ян.
Наверх
Владимир Е. Зюбин Смотреть выпадающим
Действительный член
Действительный член


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

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



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


Анализа не проводилось?
Ваш перл похож на чёрный юмор.


Пока на черный юмор похож только МЭК 61131-3... :-)

А если Вам известен такой анализ, то не переливайте из
пустого в порожнее, а просто дайте на этот анализ ссылку.
С интересом ознакомлюсь.

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


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


Я совершенно с Вами согласен... и постоянно повторяю,
что МЭК-языки ориентированы на низкоквалифицированных
пользователей и крайне простые алгоритмы. Может таких
простых задач и большинство, но сложные задачи это тоже
реальность. МЭК 61131-3 создает искусственный барьер
между простыми и сложными задачами, а также между
узкоспециализированными задачами.


Если вы не делали сложных проектов на МЭК 61131, то это не значит, что их ни кто не делает. Опрометчивое и не профессиональное утверждение.


Разумеется, я не работал со всеми языками МЭК 61131-3.
Но для того, чтобы прийти к выводу о
нецелесообразности "вкручивания" шурупов молотком,
совсем не обязательно проверять это практически... :-)))

Хотя, возможно Вы и правы, тема действительно
непростая... начиная с вопроса, что такое "сложность"...
:-)))

Давайте, начнем с простого и будем программировать на LD
включение клапана... а потом рассмотрим практические
проблемы LD c фиксацией отказов, с повторным
использованием, с модифицируемостью...
Владимир Е. Зюбин
Язык Рефлекс -- Си-подобный язык программирования ПЛК
http://reflex-language.narod.ru/
Наверх
bessonov Смотреть выпадающим
Действительный член
Действительный член


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



Пока на черный юмор похож только МЭК 61131-3... :-)

А если Вам известен такой анализ, то не переливайте из
пустого в порожнее, а просто дайте на этот анализ ссылку.
С интересом ознакомлюсь.


Разумеется я не знаком анализом.
Но если стандарт работает, то к чему голосовные утверждения?
ищите анализ на http://www.ieee.org

Если бы стандарт был не актуален, его ни кто бы не использовал :) и более того, ни кто бы не знал о существовании этого стандарта. Он был бы вытеснен другими реализациями.

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


Хотя, возможно Вы и правы, тема действительно
непростая... начиная с вопроса, что такое "сложность"...
:-)))

Давайте, начнем с простого и будем программировать на LD
включение клапана... а потом рассмотрим практические
проблемы LD c фиксацией отказов, с повторным
использованием, с модифицируемостью...


LD предназначен для замены уже реально работающих релейных схем на PLC контроллер.
Какие же тут проблемы?
С уважением,
Бессонов Ян.
Наверх
VSerg Смотреть выпадающим
Новичок
Новичок


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


Хотя, возможно Вы и правы, тема действительно
непростая... начиная с вопроса, что такое "сложность"...
:-)))

Давайте, начнем с простого и будем программировать на LD
включение клапана... а потом рассмотрим практические
проблемы LD c фиксацией отказов, с повторным
использованием, с модифицируемостью...


Что бы включить клапан? Управление клапаном идет вроде через дискретный канал В/В. Да в общем не важно через какой канал. Суть не меняется.

Всего 4 действия или 7 для управления с таймера (4-действие можно пропустить).
1) Заводим переменную
2) Заводим драйвер для устройства
3) Связываем переменную с драйвером
4) Собираем проект
Запускаем в отладке и смотрим меняются ли значения канала при изменении переменной. Естественно меняются. Даже LD не нужно. Значения можно вычислять, если правила простые (на уровне булевой логики)то и в LD, а если сложные то в ST и/или других МЭК языках. При наличии логики вычисления включения, то например по таймеру
5) заводим в FBD таймер
6) задаем значение времени и указываем какой сигнал пускает таймер.
7) привязываем переменную к выходу Q таймера. Все.

Я это сделал меньше чем за 5 минут. При этом пришлось заглянуть в документацию по LD. Я LD не пользуюсь, так как ST мне ближе.
Каждой вещи свое место.
С уважением, VSerg.
Наверх
 Ответить Ответить Страница  <1 2930313233 53>

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

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