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

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

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


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Средство для программирования контроллера: Си или МЭК 61131?
    Опубликовано: 16 Сентябрь 2003 13:49
Небольшая ремарка ...

Сорокин:

>Прочтите внимательно, и осознайте, что никто не
>говорит, что переносимость - это плохо...

>>>>>>>>>>>>>>>>>>>

Вы так же читайте внимательно. Моя реплика относится
не к статье, а к Вашему предыдущему письму.


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


Присоединился: 07 Август 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 108
Свойства публикации Свойства публикации   Ответить, цитируя автора - bessonov Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 16 Сентябрь 2003 18:19
q
С уважением,
Бессонов Ян.
Наверх
Sergey Sorokin Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 27 Март 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 240
Свойства публикации Свойства публикации   Ответить, цитируя автора - Sergey Sorokin Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 17 Сентябрь 2003 02:20

Так я и в предыдущем своем письме не говорю, что
переносимость это плохо! 8-)

>>>>>>>>>>>>>>>>>

Просто я так понял из контекста Ваших высказываний. Например Вы говорили:

 

 

И, по моим ощущениям, "поумнение" PLC Open все-таки
ощущается, т.к., на мой взгляд, разговоров о
переносимости стало все-таки меньше, чем пять
лет назад... :-)

>>>>>>>>>>>>>>>>>

Из этого следует, что раз «поумнение» связано с уменьшением разговоров о переносимости, то «подурнение» (а дурное не может быть хорошим) – с увеличением разговоров о переносимости. Возможно я Вас просто неверно понял.

 

 

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

>>>>>>>>>>>>>>>>>>

Нужно наверное просто уточнить, что Вы говорите о двоичной переносимости. Такой задачи при создании МЭК 61131-3 и не ставилось. Однако стандарт позволяет обеспечить переносимость первого уровня (на основе единых синтаксиса и семантики языков), а так же переносимость второго уровня для текстовых языков (на основе общепринятых способов хранения текстовых данных).

 

С Уважением,

 

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

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


Присоединился: 27 Март 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 240
Свойства публикации Свойства публикации   Ответить, цитируя автора - Sergey Sorokin Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 17 Сентябрь 2003 03:00

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


Вот Вам приблизительный текст теста:

#include <stdio.h>
#include <MATH.h>


main () {
long i;
float data;

    data = 2.0;

printf("\n ============ START. ======");
    for (i = 0; i < 1000000000; i++) {
      sqrt(data);
    }

printf("\n ============ END OF PART 1 ======");

    for (i = 0; i < 1000000000; i++) {
    }
printf("\n ============ END OF PART 2 ======");


return(NULL);

}


..

Так вот. У меня получилось, что
за 100 сек с sqrt исполняется -
18929185 циклов, а без sqrt (тот же самый цикл)-
19103533...

среднее время вычисления sqrt -
50 нс (НОНОСЕКУНД с учетом накладных расходов), и
50 мс (МИКРОСЕКУНД!) (если без учета)...


 

Владимир, меня в этих цифрах кое что смущает (последние две цифры я вообще не понял). Если поделить 100 сек, на количество циклов, то получится:

 

длительность цикла с оператором SQRT состаляет             5282нс

длительность цикла без оператора SQRT составляет            5234нс.

Соответственно долительность SQRT составляет                  48нс

 

Получается, что простой инкремент 32 разрядного целого, его сравнение с 32 разрядной константой и короткий условный переход длятся около 5000нс, в то время как запись 32 разрядного числа с плавающей точкой в стек, вызов функции, запись IP в стек, вычисление квадратного корня (32 разряда мантисса+логарифм) разложением в ряд (эмуляция вычислений с плавающей точкой) 16 битными командами 8086/8088,  возврат из стека IP и модификация SP длятся только около 50нс (то есть всего 50 машинных тактов вашего Пентиума 1 Ггц).

 

Мне трудно поверить, что инкремент 32 разрядного целого числа делается в 100 раз дольше чем извлечение корня с плавающей точкой в режиме эмуляции. Может я неверно интерпретирую Ваши цифры?

 

С Уважением

 

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

 

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


Присоединился: 09 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 247
Свойства публикации Свойства публикации   Ответить, цитируя автора - Владимир Е. Зюбин Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 17 Сентябрь 2003 08:09
Сергей Сорокин:
Из этого следует, что раз «поумнение» связано с уменьшением разговоров о
переносимости, то «подурнение» (а дурное не может быть
хорошим) – с увеличением разговоров о переносимости.
Возможно я Вас просто неверно понял.


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

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

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

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


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


И правильно смущает, т.к. цифры приведены не для
варианта теста с измерением времени по заданному числу
операций (текст, который Вы привели), а для варианта
теста а la UL (с измерением количества операций за
заданное время)... текст этого теста приведен в том
же сообщении (он содержит функцию "time()" в цикле)

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


Присоединился: 17 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 2
Свойства публикации Свойства публикации   Ответить, цитируя автора - Сергей Мананников Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 17 Сентябрь 2003 13:23

По моему мнению спор о том что эффективнее C или МЭК, может продолжаться бесконечно. Особенно если его направлять в русло наносекунд.

Ответ же в споре очень прост. Надо просто разделять профессии программиста и инженеров-технологов и им подобных. Я сам обученный инженер по автоматизации, но урожденный программист :). Из своего нынешнего опыта, могу сказать следующее.

1. Средства разработки на языках МЭК (типа IsaGraf, UltraLogic и т.д.) для инженеров-технологов создаются ПРОГРАММИСТАМИ на языках Си++, Паскаль и т.д. (ну не на FBD же писали UltraLogic). Создаются они для того, чтобы инженеры могли реализовывать свои задачи (как правильно было сказано "на понятных инженерам языках") не привлекая квалифицированных программистов.

2. Далее, наличие в средстве разработки на языках МЭК возможности писать на Си и Асме, определяется только амбициями и опытом программистов, создавших это средство разработки:

    а) Умные и амбициозные - Мы создали блоки FBD на все случаи жизни. Пишите на МЭК. И нам проблем меньше. (Сименс, AllenBredley. Причем как правило у них действительно блоки ну почти на все случаи жизни).

    б) Умные - Мы конечно все учли, но вдруг людям захочется что-то очень гибкое и хитрое писать (а уж такие случаи встречаются). Оставим им еще и Си++ впридачу со всеми расширенными возможностями (память, прерывания и т.д.).

    в) Умные + проблем себе поменьше - Вариант б). Только ограничим ка мы им Си. Ну чтоб по памяти и прерываниям не лазили, а если вдруг какой-то блок не стандартный понадобится (тот же пример с корнем квадратным и других степеней), то пусть не бедняга инженер полиномы раскладывает и в FBD реализует, а попросит (наймет или сам вумный) знакомого программиста и он ему за -надцать минут напишет на Си блок под названием SQRT :-).

Вот и все. Надо просто знать свою специализацию и не лезть в области профессионализма других людей.

Да кстати, этот же спор можно переложить на Скада пакеты. Например, зачем нам ущербный VBA. Хотим писать на Си++. :-). А ответ все тот же.

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


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

По моему мнению спор о том что эффективнее C или МЭК, может продолжаться бесконечно. Особенно если его направлять в русло наносекунд.


Ответ же в споре очень прост. Надо просто разделять профессии программиста и инженеров-технологов и им подобных. Я сам обученный инженер по автоматизации, но урожденный программист :). Из своего нынешнего опыта, могу сказать следующее.


1. Средства разработки на языках МЭК (типа IsaGraf, UltraLogic и т.д.) для инженеров-технологов создаются ПРОГРАММИСТАМИ на языках Си++, Паскаль и т.д. (ну не на FBD же писали UltraLogic). Создаются они для того, чтобы инженеры могли реализовывать свои задачи (как правильно было сказано "на понятных инженерам языках") не привлекая квалифицированных программистов.


2. Далее, наличие в средстве разработки на языках МЭК возможности писать на Си и Асме, определяется только амбициями и опытом программистов, создавших это средство разработки:


    а) Умные и амбициозные - Мы создали блоки FBD на все случаи жизни. Пишите на МЭК. И нам проблем меньше. (Сименс, AllenBredley. Причем как правило у них действительно блоки ну почти на все случаи жизни).


    б) Умные - Мы конечно все учли, но вдруг людям захочется что-то очень гибкое и хитрое писать (а уж такие случаи встречаются). Оставим им еще и Си++ впридачу со всеми расширенными возможностями (память, прерывания и т.д.).


    в) Умные + проблем себе поменьше - Вариант б). Только ограничим ка мы им Си. Ну чтоб по памяти и прерываниям не лазили, а если вдруг какой-то блок не стандартный понадобится (тот же пример с корнем квадратным и других степеней), то пусть не бедняга инженер полиномы раскладывает и в FBD реализует, а попросит (наймет или сам вумный) знакомого программиста и он ему за -надцать минут напишет на Си блок под названием SQRT :-).


Вот и все. Надо просто знать свою специализацию и не лезть в области профессионализма других людей.


Да кстати, этот же спор можно переложить на Скада пакеты. Например, зачем нам ущербный VBA. Хотим писать на Си++. :-). А ответ все тот же.



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


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

если система простая, не требует эффективности
при организации исполнения, не предъявляет
особых требований к надежности, допускает зависимость
от третьесторонних производителей ПО, то ISaGRAF
может и подойти...

Кстати, чтобы расставить все точки над е...
лично я не призываю программировать на Си.
Есть много языков четвертого поколения,
ориентированных на описание алгоритмов работы
систем управления... другое дело они не попали
в МЭК 61131-3... а то были бы не менее известны, чем
ассемблер IL... ;-)

Что касается МЭК 61131-3... наиболее продвинутым
средством является SFC+ST... только вот ST уж
больно Паскаль напоминает... надо всегда об этом
помнить, когда МЭК и Си противопоставляется... ;-)

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


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

Совершенно верно... есть типовые решения
для разных случаев жизни...

если система простая, не требует эффективности
при организации исполнения, не предъявляет
особых требований к надежности, допускает зависимость
от третьесторонних производителей ПО, то ISaGRAF
может и подойти...


На что вы опираетесь?
Где ссылка на независимую оценку низкой надёжности ISaGRAF?

Дайте ссылку на организацию проводящую оценку надёжности ПО и открыто заявляющей о низкой надёжности ISaGRAF.
С уважением,
Бессонов Ян.
Наверх
 Ответить Ответить Страница  <1 56789 53>

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

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