форум асутп
 На главную                       Здесь может быть Ваша реклама, подробнее...

здесь может быть ваша реклама

 Наверх  |  Перейти к теме  |  Поиск  |  Вход  |  Дерево    
 PC-совместимый контроллер vs PLC.
Автор: Андрей 
Дата:   07.05.07 17:45

Задался вопросом. Чем координально отличаются РС-соместимые
контроллеры от обычных. Если с физическими отличиями все более менее
понятно, то вот с точки зрения полезности РС-совместимых "наворотов",
честно говоря, никак не могу определиться.

Может кто подскажет. Какие основные преимущества РС-современных
контроллеров над обычными? Чем они лучше? Есть какая-нить литература
прочитать про это?

Заранее спасибо!



--
С уважением,
 Андрей                          mailto:dron@xxxxxxx.xxx

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   07.05.07 18:03

Старая тема :)
Смотря что с чем сравнивать. Хороший РС-совсместимый по сравнению с отсталым классическим завсегда выгоднее смотрится.
А по сути - долго мы здесь спорили и многие так и остались при своем мнении. Мое ИМХО -РС для частных относительно небольших задач не требующих в дальнейшем частых изменений и иногда (в случае совсем уж простой классики)- помощь с интеграцией совсем уж замысловатых устройств с частнофирменными протоколами от которых народ итак уже шарахается как от сотоны :)
Все остальное- лучше всего хорошая классика жанра.
И особенно - для непрерывных процессов.
По цене - тоже весьма спорно. Выиграв на капах в РС проигрываете в стоимости владения..

>
> Задался вопросом. Чем координально отличаются РС-соместимые
> контроллеры от обычных. Если с физическими отличиями все
> более менее понятно, то вот с точки зрения полезности
> РС-совместимых "наворотов", честно говоря, никак не могу определиться.
>
> Может кто подскажет. Какие основные преимущества
> РС-современных контроллеров над обычными? Чем они лучше? Есть
> какая-нить литература прочитать про это?

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   07.05.07 19:02

Добрый день!

Плюсы - открытость, расширяемость, выбор средств программирования.
Если комплект от одного производителя, а не сборная солянка, то
диагностические средства, сервис и т.п. могут быть не хуже, чем у
классики.

Минусы - та же открытость, но главное - время перезагрузки. Оно обычно
гораздо хуже PLC.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Лапченков Константин 
Дата:   08.05.07 06:57

Добрый день!

Илья, а приведите пример производителя РС-совместимых контроллеров,  у
которого диагностические средства и сервис не хуже, а открытость,
расширяемость, выбор средств не потеряны?
А то выходит, что производителей плат ввода-вывода много, а с комлексным
решением туговато, и/или в результате получается вариант PLC.
С уважением,
Лапченков Константин,
ОАО ЧЭМК

>Плюсы - открытость, расширяемость, выбор средств программирования.
>Если комплект от одного производителя, а не сборная солянка, то
>диагностические средства, сервис и т.п. могут быть не хуже, чем у
>классики.
>С уважением, Илья Аблин

Адрес этого сообщения    Ответить на это сообщение
 
 PC-совместимый контроллер vs PLC.
Автор: Кедык Олег Васильевич 
Дата:   08.05.07 09:14

Товарисчи! Это провокация! Не поддавайтесь! :)




С уважением,
Руководитель проекта,
ЗАО "Компания СЗМА",
Кедык Олег Васильевич,
тел.  8(812)431-98-83,
факс  8(812)232-07-75

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Yury S. Kokin 
Дата:   08.05.07 09:27

РС или PLC - все зависит от разработчика и заказчика<неиЕсли задача частная
(маленькая линия или установка) и решает задачу сам заказчик (своими
подразделениями), то PC или PLC на выбор разработчика<неиЕсли задача -
глобальная автоматизация Цеха или Завода - то PLC, т к ее будут решать
сторонние разработчики и Заказчику может потребоваться модернизация
системы.<неиЕсли задача уникальная - требует уникальных ресурсов и
алгоритмов, что встречается давольно редко (если не считать решение задачи
совместимости зоопарка средств автоматизации на предприятии, но это уже на
совести системотехника), то конечно же PC<неи<неиС уважением, Кокин Юрий
Сергеевич, Руководитель проектов, ЗАО <СИС Инкорпорэйтед>
Y.Kokin@xxx-xxx.xx, ICQ:119-978-020<неи<неи-----Original
Message-----<неи>Задался вопросом. Чем координально отличаются
РС-соместимые<неи>контроллеры от обычных. Если с физическими отличиями все
более менее<неи>понятно, то вот с точки зрения полезности РС-совместимых
"наворотов",<неи>честно говоря, никак не могу определиться.<неи<неи>Может
кто подскажет. Какие основные преимущества РС-современных<неи>контроллеров
над обычными? Чем они лучше? Есть какая-нить литература<неи>прочитать про
это?<неи<неи>Заранее спасибо!<неи

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   08.05.07 09:44

Ну не всегда так :) интеграцию зоопарка вполне реально выполнить и средствами PLC (правда не всех производителей).
Проблема в стоимости: чаще дешевле выбрать другой КИП чуть более дорогой но со стандартными протоколами чем платить интегратору подчас по 1000 у.е. за разработку уникального драйвера под какой-то немыслимый протокол + тратить тонну времени на то чтобы хоть как-то криво интегрировать весь этот хлам зачастую теряя при это массу полезны фич типа диагностики и прочее. А уж про обслуживание всего этого "добра" я вообще молчу.
Поэтому я всегда очень-очень сильно нервничаю вплоть до ненормативной лексики когда вопрос касается заблаговременного создания зоопарка (да простят меня кой-какие производители технологии на последнем совещании, которые хотят решить только свою частную проблему не принимая во внимание проект в целом) :)

> уникальных ресурсов и алгоритмов, что встречается давольно
> редко (если не считать решение задачи совместимости зоопарка
> средств автоматизации на предприятии, но это уже на совести
> системотехника), то конечно же PC

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Yury S. Kokin 
Дата:   08.05.07 10:45

Я про это и говорю, что зоопарк создавать не надо. А если он создан, то это
на совести системотехника.<неиВообще, таких системотехников надо гнать
взашей.<неи<неиС уважением, Кокин Юрий Сергеевич, Руководитель проектов, ЗАО
<СИС Инкорпорэйтед> Y.Kokin@xxx-xxx.xx, ICQ:119-978-020<неи<неи> Ну не
всегда так :) интеграцию зоопарка вполне реально выполнить и средствами PLC
(правда не всех производителей).<неи>Проблема в стоимости: чаще дешевле
выбрать другой КИП чуть более дорогой но со стандартными протоколами чем
платить интегратору подчас по 1000 у.е. за >разработку уникального драйвера
под какой-то немыслимый протокол + тратить тонну времени на то чтобы хоть
как-то криво интегрировать весь этот хлам >зачастую теряя при это массу
полезны фич типа диагностики и прочее. А уж про обслуживание всего этого
"добра" я вообще молчу.<неи>Поэтому я всегда очень-очень сильно нервничаю
вплоть до ненормативной лексики когда вопрос касается заблаговременного
создания зоопарка (да простят меня >кой-какие производители технологии на
последнем совещании, которые хотят решить только свою частную проблему не
принимая во внимание проект в целом) :)<неи<неи> уникальных ресурсов и
алгоритмов, что встречается давольно <неи> редко (если не считать решение
задачи совместимости зоопарка <неи> средств автоматизации на предприятии, но
это уже на совести <неи> системотехника), то конечно же PC<неи<неи<неи <неи

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   08.05.07 11:02

На очень больших проектах без зоопарка не обойтись все равно. Особенно с КИП часто проблемы- с нужными протоколами не всегда удается подобрать в связи с очень жесткими ТУ. Но с набором типовых протоколов все равно можно все найти.
С производителями блочного оборудования весьма тяжело приходится, особенно как ни странно- с российскими.
Пугают отказом в гарантии и прочее, многим наверняка знакомое.
К тому же, эти парни только и норовят как маржу себе урвать побольше. Глаз да глаз за ними.
Пару случаев было вообще возмутительнейших - накручивали ни за что аж до 60% за КИП, на который у нас уже получены свои прямые скидки.
А минимизировать зоопарк по-максимуму - прямая задача ген. проектировщика.


> Я про это и говорю, что зоопарк создавать не надо. А если он
> создан, то это на совести системотехника.<неиВообще, таких
> системотехников надо гнать взашей.

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: Alexander Burmistrov 
Дата:   08.05.07 10:16

Здравствуйте, Лапченков Константин!

ЛК> а приведите пример производителя РС-совместимых контроллеров,  у
ЛК> которого диагностические средства и сервис не хуже, а открытость,
ЛК> расширяемость, выбор средств не потеряны?
ЛК> А то выходит, что производителей плат ввода-вывода много, а с комлексным
ЛК> решением туговато, и/или в результате получается вариант PLC.

РС-совместимые контроллеры - это один из видов свободнопрограммируемых
контроллеров. К "свободным" можно отнести много чего, очень даже не
РС-совместимое. Например то, с чем работаем мы - ТКМ-410 и Теконик P06
от ТЕКОНа. У одного внутри ARM7, у другого - XScale, вроде так.
Никаким PC и не пахнет, но программируется все свободно, на
компиляторе GCC. Мы программируем эти контроллеры сами, чтобы они
органично существовали в нашей системе. Кто не имеет такой
возможности, или нет желания - пожалуйста, разработчик предоставляет
все что нужно, все инструментальные средства, чтобы вы думали что это
PLC.

А всякие PC-платы, I7188, Бэкофский чип и так далее - это не
контроллеры, это конструкторы, с разным набором библиотек, чтобы
кто-то умный (или бедный) мог собрать очень специфическую (или
"дешевую") систему под себя.

Так что нет никакого противостояния PC vs PLC, надумано все это.

С уважением,
Александр Бурмистров,
ООО "ЭНТЕЛС", начальник отдела автоматизации.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   08.05.07 13:43

Добрый день!

>РС-совместимые контроллеры - это один из видов
>свободнопрограммируемых контроллеров. К "свободным" можно
>отнести много чего, очень даже не РС-совместимое.

Согласен абсолютно.

>А всякие PC-платы, I7188, Бэкофский чип и так далее - это не
>контроллеры, это конструкторы, с разным набором библиотек,
>чтобы кто-то умный (или бедный) мог собрать очень специфическую (или
>"дешевую") систему под себя.

Да.

>Так что нет никакого противостояния PC vs PLC, надумано все это.

Точно. Границы весьма размыты.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   08.05.07 13:41

Добрый день!

>Илья, а приведите пример производителя РС-совместимых
>контроллеров,  у которого диагностические средства и сервис не
>хуже, а открытость, расширяемость, выбор средств не потеряны?

Для больших централизованных систем мы используем контроллер МФК3000
от Текона, поскольку он аппаратно рассчитан на построение систем
повышенной надежности. Внутри обычный (с некоторыми сокращениями)
Линукс с комплектом  диагностических и сервисных программ, поверх мы
грузим нашу систему MasterSCADA. Она вертикально-интегрированная, что
очень удобно при разработке проектов. Доступ ко всему сервису через
Веб-интерфейс. Все драйвера, в том числе с выдачей диагностической
информации, поддержкой резервированных и троированных модулей, есть в
готовом виде, поэтому мы работаем с железом через них, и вообще не
задумываемся о системных вопросах. А для покупателей такого комплекта
(их железо и наш софт) вообще нет разницы, как это называть,
функционально это уже полный аналог PLC, даже более того, поскольку
нет задачи стыковки с верхним уровнем.

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

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   08.05.07 15:01

Добрый день!

>чем платить
>интегратору подчас по 1000 у.е. за разработку уникального
>драйвера под какой-то немыслимый протокол

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

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   08.05.07 15:45

Наверное это мое счастье что я владею только такими старыми ценами :) Иначе волосы на голове еще раньше бы начали шевелиться :)
Ну тем более тогда- разработать минмум за 1500-2000-3000 драйвер получается дольше и дороже чем купить датчик самый продвинутый от мирового производителя со всеми вытекающими прелестями :) Зачем мучать себя и людей никому не нужным частнофирменным хламом с которым еще и по надежности наверняка проблемы сравнительно с "дорогим" интеллектуальным КИП ... :) в общем - любое частнофирменное ф топку. Именно такую политику мы сейчас и проводим в Компании.
Это же касается и софта.

> Вы не подскажите адресок этого интегратора. Я бы его с такими
> ценами с удовольствием на субподряд взял. Драйвер - это по
> минимуму от недели до четырех для программиста, что при
> нынешних ценах....

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: aysanov-r 
Дата:   08.05.07 15:01

Добрый день!

Полностью согласен.


   1 . Следует уточнить, что разница между PC и PLC  появилась
на определенном этапе развития из-за технологических ограничений.
Было очень дорого строить системы автоматизации на той же
 элементной базе, на которой создавались РС.
В конце концов, из-за развития технологии производства электронных
компонентов
разница в цене и тем более функциональности практически исчезла.
   Доля PC совместимых контроллеров на рынке   постоянно растет и думаю, что
они будут доминировать
на рынке (естественно это те же PLC реализованные как РС совместимые и все).
Противостояние на данном этапе создано искусственно. И понятно почему.
Фирмы производители вложили громадные средства на создание и разработку
PLC контроллеров и эти средства надо окупить.
 2. На счет языков программирования FBD, LD или других языков для
программирования PLC, PC.
 Тут однозначно нельзя говорить что лучше и что хуже, все зависит от задачи,
которую вы решаете. Например, кто программировал
 в среде Codesys прекрасно это поймет (в среде Codesys реализованы все 6
языков стандарта МЭК).
Часто возникают ситуации, когда при решении задачи  приходится комбинировать
почти все языки.
Разработчику  все равно, в  каком контроллере стоит среда Codesys PLC или PC
(например, мне до лампочки лишь можно было реализовать свою задачу).

С уважением Руслан Айсанов
Группа компаний "Формула безопасности"

совместимый контроллер vs PLC.

Добрый день!

>РС-совместимые контроллеры - это один из видов
>свободнопрограммируемых контроллеров. К "свободным" можно
>отнести много чего, очень даже не РС-совместимое.

Согласен абсолютно.

>А всякие PC-платы, I7188, Бэкофский чип и так далее - это не
>контроллеры, это конструкторы, с разным набором библиотек,
>чтобы кто-то умный (или бедный) мог собрать очень специфическую (или
>"дешевую") систему под себя.

Да.

>Так что нет никакого противостояния PC vs PLC, надумано все это.

Точно. Границы весьма размыты.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   08.05.07 16:02

Разработчику  может и все равно, а вот Заказчику совсем не все равно. У него есть ряд требований касаемых дальнейшей жизни решений и ему важно их выполнить.
Кто-то выбирает решения отталкиваясь от дальнейшей эксплуатации и считает все затрачиваемые деньги за срок жизни проекта, а кто-то тупо только от капзатрат.
Я лично предпочитаю первый вариант :)


> Разработчику  все равно, в  каком контроллере стоит среда
> Codesys PLC или PC (например, мне до лампочки лишь можно было
> реализовать свою задачу).

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   10.05.07 00:46

> Доля PC совместимых контроллеров на рынке   постоянно растет и думаю, что
> они будут доминировать на рынке

Имею строго противоположное мнение :) Собственно, российский рынок автоматизации является зеркальным отражением мирового - у нас высока доля PC-совместимых контроллеров (она постоянно падает в связи с тем, что государство становится более состоятельным, и предприятия могут позволить себе более дорогие и качественные решения), а у них традиционно высока доля PLC (встречал оценку до 98% мирового рынка автоматизации).

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   10.05.07 01:02

Уважаемые коллеги!
Сердечно поздравляю всех с возобновлением горячо любимой темы :-)

Однако, судя по всему, вопрос был задан человеком, который:
1) недавно присоединился к Конференции, поэтому
2) не знаком с историей баталий,
3) не представляет себе количества переломанных копий и,
следовательно,
4) вполне ИСКРЕННЕ интересуется указанной темой.

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

Я полностью согласен с Александром Бурмистровым, что нет никакого
противостояния PC vs PLC. Но я бы уточнил, что нет ФОРМАЛЬНОГО
противостояния, как нет, например, противостояния между "Жигули"-
совместимыми машинами и самосвалами марки БелАЗ.

Но, IMHO, ФАКТИЧЕСКИ существует в некотором смысле "противостояние"
между следующими (примерно) категориями контроллеров:

- по типу прикладной программы: "интерпретируемая"
vs "компилированная" (в виде машинного кода центрального процессора)

- по используемым языкам разработки прикладной
программы: "универсальные" (Си(++), Ассемблер и т.п.) vs "проблемно-
ориентированные" (типа МЭК 61131)

- по "месту жительства" и "происхождению" операционной системы
контроллера: жестко прошитая ФИРМЕННАЯ (от производителя "железа") vs
загружаемая ОС или runtime-библиотека НЕЗАВИСИМОГО производителя

- и, наконец, действительно по степени совместимости с "писюком":
полностью или частично совместимые (по машинному коду ЦП, организации
памяти, системной шины, BIOS) vs АБСОЛЮТНО несовместимые

Так уж получилось, что исторически сложилась устойчивое
понятие "PLC", которое в большинстве случаев означает следующее:
- контроллер АБСОЛЮТНО  не-PC-совместимый (а также не совместимый и с
другими PLC на уровне исполняемого кода)
- с жестко прошитой фирменной ОС
- программируемый только с помощью ФИРМЕННОЙ среди разработки,
которая реализует подмножество СТАНДАРТНЫХ языков МЭК 61131
(возможно, с фирменными расширениями)
- с ИНТЕРПРЕТИРУЕМОЙ прикладной программой
- с ФИРМЕННЫМИ, но в то же время ТИПИЧНЫМИ для большинства PLC
возможностями отладки прикладной программы "на ходу" (без остановки
процесса)

Очевидно, что существует множество контроллеров, которые НЕ являются
PLC (в вышеуказанном смысле), но НЕ являются и PC-совместимыми.
Так что, возможно, вопрос "PC vs PLC" следует сформулировать как-то
по-другому ;-).

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: aysanov-r 
Дата:   08.05.07 18:26

По моему вы уже не  в тему.


 -----Original Message-----
From: d_miloserdov

Разработчику  может и все равно, а вот Заказчику совсем не все равно. У него

=======================================================
Уважаемый aysanov-r, во-первых Правилами предписано
подписыватся своим именем-фамилией, во-вторых кодировка для
писем - KOI, в-третьих ограничивайтесь в цитировании.
Короче предупреждение за нарушение Правил.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   14.05.07 09:22

Сергей Щекин указал "пограничные столбы" противостояния. Я бы добавил, PC ассоциируется с самопальным ПО, никем не поддерживаемым, PLC с фирменным со всеми вытекающими.
Однако РС совместимое ПО проходит намного более жесткую проверку и конкуренцию на рынке, по той причине, что количество его продаж на несколько порядков превышает продажи фирменного для PLC.
То же самое и с "железом". Унификация, модернизация и тестирование материнских плат идет намного жесче контроллерной вычислительной электроники. По той же причиние - большая разница в продажах и конкуренция.

Гайдаш Д.М.> ... у нас высока доля PC-совместимых контроллеров (она постоянно падает в связи с тем, что государство становится более состоятельным, и предприятия могут позволить себе более дорогие и качественные решения

Отсюда и высокая стоимость PLC - для обеспечения такой же надежности как PC, но на "фирменном" железе и ПО, требуется намного больше трудозатрат. А "варка в собственном соку" никогда не была эффективной.

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

Это не противостоние, а некоторые упреки фирмам. Лично я выбираю PC или PLC в зависимости от решаемой задачи.

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   14.05.07 09:49

> количество его продаж на несколько порядков превышает продажи фирменного для PLC

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

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   14.05.07 17:25

Интересно, что Вы отстаивая свою мысль сами себя опровергли :) Но это не важно. Расширяйте кругозор, и будете в выигрыше!

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   15.05.07 09:04

Раскройте мысль, Виктор :)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   15.05.07 09:32

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

... все, умолкаю, а то по шее получу ... (С) "В бой идут одни старики"

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   15.05.07 11:42

> жизненный цикл, а поэтому имеет существенно меньшие возможности по доводке и
> отладке. Грубо говоря, пока один производитель будет отлаживать и вылизывать
> свой чип, другие уйдут от него далеко вперед. В случае с PLC можно годами
> доводить до совершенства архитектуру и софт - никто не торопит особенно.

Как же, доводят они годами. Пока какой-нибудь клиент не пожалуется, они и не почешутся.
У нас были случаи, когда дефектный CPU брали на ремонт, втыкали на пару недель
на тестовый прогон, а потом отдавали обратно, срубив бабло за ремонт. Ну это так, к слову.
Доводка продукта денег стоит, а сам продукт в принципе не должен быть безупречен,
иначе будет over-engineering, т.е. обойдётся слишком дорого. Так что на практике
в процессе разработки вылавливаются не все баги. Выловить остальные перекладывается
на плечи клиента. И чем больше число поставленных контроллеров, тем больше багов можно
выловить.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   15.05.07 14:13

> И чем больше число поставленных контроллеров, тем больше багов можно
выловить

И как это противоречит моим словам? Продавать и доводить - это взаимосвязанные вещи. Кстати, у производителей PC-шного железа нет такой обратной связи с клиентами, как у производителей PLC.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   15.05.07 18:21

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

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   15.05.07 21:20

> А к чему были рассуждения про жизненный цикл?

К тому, что в совокупности (!!!) с большими объемами продаж это обеспечивает естественное преимущество промышленной автоматике перед PC.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   16.05.07 11:41

По сравнению с объемами продаж влияние жизненного цикла пренебрежимо мало, полагаю. А во-вторых, тезис про "гораздо меньший" ж.ц. у ПК-систем я бы тоже оспорил. У одного и того же производителя каждые пару лет выходит новая версия. Все они говорят, что если у кого есть старая, можно и дальше сколько угодно на ней работать, но на практике приходится обновлять по той или иной причине.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   16.05.07 13:28

2Гайдаш Д.М.: Вы в каком мире живете? Где это промышленных контроллеров продается больше чем компьютеров. Вот у Вас дома сколько промышленных контроллеров стоит?

А у меня дома на три компа нет ни одного контроллера. И во всем подъезде нет...

В заводоуправлении, на 60 компов только автоматика кондиционирования, и пожарка с охраной. Даже в производственном цехе на 5 контроллеров приходится 6 компов.

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   16.05.07 13:30

Я живу на планете Земля, а Вы живете в России, похоже :) Я к тому, что на мировом рынке ситуация с автоматизацией диаметрально противоположна российской.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   16.05.07 15:43

> мировом рынке ситуация с автоматизацией диаметрально противоположна российской.

Вы, очевидно, считаете число проданных ПК, исходя из их назначения. То есть все офисные компьютеры для Вас в расчёт не идут. Что в общем-то не совсем верно. Ибо в промышленном компьютере те же процессоры, память, винда и т.п.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   16.05.07 15:57

Во-первых, каюсь - да, так оно и есть :) Во-вторых, посмотрите все-таки на PC-совместимые железки - в массе своей это в лучшем случае что-нибудь вроде Intel Pentium 166MMX. Как думаете, когда на Core2Duo промышленные платы клепать начнут?

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   16.05.07 17:51

Гайдаш Д.М. писал(а):

> Intel Pentium 166MMX. Как думаете, когда на Core2Duo промышленные платы клепать
> начнут?

Когда железо пройдёт обкатку на обычных юзерах, не раньше. Как и было в случае с 166ММХ

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   17.05.07 09:35

>PC-совместимые железки - в массе своей это в лучшем случае что-нибудь вроде Intel Pentium 166MMX

Думаю, такие остались только в прайсах. Мы меньше чем PIV-2ГГерц не ставим (это если софт под винду). Я же вам советовал посмотреть серверные платформы, зачем передергивать?

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Илья Астафьев 
Дата:   17.05.07 10:12

У IEI с 2007 года заявлены платы, поддерживающие Core2Duo. Правда чипсет там по-прежнему 845, а не 965. Видимо просто BIOS переделали.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   17.05.07 10:46

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

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   17.05.07 10:48

> ГДМ> Как думаете, когда на Core2Duo промышленные
> ГДМ> платы клепать начнут?

>Когда железо пройдёт обкатку на обычных юзерах, не раньше. Как и было в
> случае с 166ММХ

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

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   17.05.07 13:52

> Мы про разные вещи говорим - вы о компах, я о контроллерах. А серверные
> платформы не рулят техпроцессом - это просто вспомогательное оборудование
> (низкой надежности и стоимости), техпроцесс может работать без него.

Ещё как рулят. Там, где отказ недорого стоит.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   17.05.07 15:39

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

А зачем их искать, они существуют. Внутренностей не знаю (медный, что-то на базе капилярных трубок). Стоит на порядок дороже вентилятора.

>> ... А серверные платформы не рулят техпроцессом ...
>Ещё как рулят. Там, где отказ недорого стоит.

И где дорого стОит, тоже рулят. И сами они надежнее чем некоторые контроллеры, и горячее резервирование в них часто легче делается, чем на контроллерах. Особенно с распределенной периферией на базе промышленного Эзернета.

Короче, спор глухого со слепым, как и всегда ...

На чем и расстаюсь, с уважением, Бардичев Виктор.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   17.05.07 15:47

> И где дорого стОит, тоже рулят. И сами они надежнее чем некоторые контроллеры

Ну-ну... Так и представляю себе серверную стойку, руляющую процессом с требованиями по безопасности категории SIL3.

А способ диалога интересный - написать ерунду, а в конце "На чем и расстаюсь". Взять что ли на вооружение?

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   18.05.07 08:44

Здравствуйте, Бардичев Виктор.

Вы писали 17 мая 2007 г., 15:39:45:

>>И еще когда найдут нормальный (т.е. безвентиляторный) способ охлаждать эти
БВ> "гигагерцовые печки".

БВ> А зачем их искать, они существуют. Внутренностей не знаю (медный, что-то
БВ> на базе капилярных трубок). Стоит на порядок дороже вентилятора.

Знаете, я очень живо себе представляю процессорный модуль с
форм-фактором PC/104, на котором стоит "во-о-т такенный" медный
радиатор. Скорее всего, это будет нечто кубической формы и
крайне внушительных размеров.

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re[3]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   18.05.07 09:08

Привет всем!

Friday, May 18, 2007, 11:43:06 AM, you wrote:

AY> Здравствуйте, Бардичев Виктор.

AY> Вы писали 17 мая 2007 г., 15:39:45:

>>>И еще когда найдут нормальный (т.е. безвентиляторный) способ охлаждать эти
БВ>> "гигагерцовые печки".

БВ>> А зачем их искать, они существуют. Внутренностей не знаю (медный, что-то
БВ>> на базе капилярных трубок). Стоит на порядок дороже вентилятора.

AY> Знаете, я очень живо себе представляю процессорный модуль с
AY> форм-фактором PC/104, на котором стоит "во-о-т такенный" медный
AY> радиатор. Скорее всего, это будет нечто кубической формы и
AY> крайне внушительных размеров.

Тут в общем-то вопрос в другом. Радиатор ставить ни к чему.. Достаточно
тактовую частоту понизить.

А радиаторы ставят там, где выч.мощности не хватает. В задачах
управоения проблема выч. мощности - проблема третьестепенная. Нет
такой проблемы в принципе. Разве что, в разгоряченных головах
маркетологов от QNX.

Вопрос между ПС и ПЛК в других вещах: 1) в надежности. У
ПС-совместимых контроллеров надежность очень высокая, а если не
хватает - то проблема решается дублированием, 2) в зависимости от
производителя. ПС тут даст фору любому ПЛК. 3) в доступности
программных средств. Опять же ПК тут имеет значительный приоритет.

Ethernet, com-порт вот и все, что по сути от ПС-контроллера надо в 99%
случаев.

А коробочек с лейблом МЭК 61131-3 боюсь как огня. Купишь у
какого-нибудь Сименса, на всю жизнь подсядешь на 286 проц.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[3]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   18.05.07 09:47

> А коробочек с лейблом МЭК 61131-3 боюсь как огня

Не нужно их бояться, надо уметь с ними работать :)

P.S. Про надежность повеселили, спасибо.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[4]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   18.05.07 11:03

Здравствуйте, Владимир.

Вы писали 18 мая 2007 г., 9:08:07:

> А радиаторы ставят там, где выч.мощности не хватает. В задачах
> управоения проблема выч. мощности - проблема третьестепенная. Нет
> такой проблемы в принципе. Разве что, в разгоряченных головах
> маркетологов от QNX.
Насчет "разгоряченных голов маркетологов от QNX" это Вы хорошо
подметили, мне понравилось. На своей шкуре почувствовал. Ну да ладно,
это совсем не по этой теме.
А что касается проблемы нехватки вычислительной мощности, тут я с Вами
почти согласен. Типовые задачи управления, в общем-то, действительно,
не нуждаются в особо мощных процессорах. Но есть ведь и нетиповые,
именно на которые, по мнению многих наших коллег-участников форума,
и нацелены PC-совместимые контроллеры. Далеко ходить не надо, мы в
2003 году сделали систему умерения качки (а по факту - систему
стабилизации) для высокоскоростного катера "Гарпун" с системным циклом
10 мс на фаствеловском СPU686E. Для этого пришлось из процессора
"выжать максимум".

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   18.05.07 12:16

> Ну-ну... Так и представляю себе серверную стойку, руляющую процессом с
> требованиями по безопасности категории SIL3.

Ну зачем сразу в крайности. Вот, скажем, на производстве печатных плат фирмы IBM
стоят линии, управляемые обыкновенным писюком с гигагерцовыми AMD внутри, исходник
ПИД-регулятора внутри которого писан Вашим покорным слугой. Не сказать, чтобы там
всё там было безупречно, но клиент доволен. ;)

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re[5]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   18.05.07 12:44

Hello Alexey,

Friday, May 18, 2007, 2:02:42 PM, you wrote:

AY> Здравствуйте, Владимир.

AY> Вы писали 18 мая 2007 г., 9:08:07:

>> А радиаторы ставят там, где выч.мощности не хватает. В задачах
>> управоения проблема выч. мощности - проблема третьестепенная. Нет
>> такой проблемы в принципе. Разве что, в разгоряченных головах
>> маркетологов от QNX.
AY> Насчет "разгоряченных голов маркетологов от QNX" это Вы хорошо
AY> подметили, мне понравилось. На своей шкуре почувствовал. Ну да ладно,
AY> это совсем не по этой теме.
AY> А что касается проблемы нехватки вычислительной мощности, тут я с Вами
AY> почти согласен. Типовые задачи управления, в общем-то, действительно,
AY> не нуждаются в особо мощных процессорах. Но есть ведь и нетиповые,
AY> именно на которые, по мнению многих наших коллег-участников форума,
AY> и нацелены PC-совместимые контроллеры. Далеко ходить не надо, мы в
AY> 2003 году сделали систему умерения качки (а по факту - систему
AY> стабилизации) для высокоскоростного катера "Гарпун" с системным циклом
AY> 10 мс на фаствеловском СPU686E. Для этого пришлось из процессора
AY> "выжать максимум".

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

А суть задачи можно описать? По моим ощущениям, в МикроПиСи бОльшие
проблемы не с временем обработки, а с временем ввода/вывода.


--
Best regards,
 zyubin                            mailto:zyubin@xxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   18.05.07 13:47

> Здравствуйте, Владимир.
>
> Вы писали 18 мая 2007 г., 9:08:07:
>
> систему умерения качки (а по факту - систему стабилизации) для высокоскоростного
> катера "Гарпун" с системным циклом 10 мс на фаствеловском СPU686E. Для этого
> пришлось из процессора "выжать максимум".

Что-то мне подсказывает, что в случае с PLC ну скажем фирмы Siemens :) ничего "выжимать" не пришлось бы.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[6]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   18.05.07 14:15

> По моим ощущениям, в МикроПиСи бОльшие
> проблемы не с временем обработки, а с временем ввода/вывода.

А я и не говорю о проблемах. Нам и вычислительной мощности CPU686E
пока хватает, и с быстродействием ввода/вывода проблем не испытываем.
Наш типичный контроллер имеет на борту один модуль АЦП (AI16-5A) и
пару-тройку модулей дискретного ввода/вывода (UNIO96-1). Требуется
несколько последовательных портов - используем октагоновские 5554/8.
Требуется полевая шина - ставим FBC c хильшеровским навесным модулем
(COM-PB, например). Производительности шины ISA-8 для такого набора
модулей хватает без проблем.

> А суть задачи можно описать?

"Рекламное" описание системы умерения качки лежит у нас на сайте:
http://www.lenprom.spb.ru/documents_pdf/suk_a77.pdf

А про матобеспечение я попросил рассказать Ярослава Евдокимова:

Во-первых, 4 следящих привода с управлением гидроцилиндрами (гидроцилиндры
имеют датчики положения, а обратная связь замкнута программно). Частота
среза у следящих приводов около 4 Гц. Соответственно, еще ограничения
скорости при подходе к краям, чтобы интерцепторы не хлопали по днищу, и т.д.
Над этим - система регуляторов параметров движения, получающих положение
корпуса катера и выдающих задания на регуляторы интерцепторов: по крену -
дифференциальное отклонение, по дифференту и вертикальному ускорению центра
масс - синхронное, и программное задание положения интерцепторов от
скорости - перебалансировка катера при изменении скорости хода. Еще был
регулятор курса с воздействием на вертикальный руль и соответственно пятым
следящим регулятором привода.
Еще был испытан на контроллере дополнительно к перечисленному программный
блок статистической обработки, регистрирующий вертикальные ускорения
корпуса, распознающий по этим ускорениям балльность волнения и выдающий
предупреждения при превышении скорости, допустимой при данном волнении. По
не зависящим от нас причинам (не техническим) на катер это ПО установлено не
было, хотя по технике все работало.

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Ярослав Евдокимов 
Дата:   18.05.07 16:24

Гайдаш Д.М. писал(а):

> Что-то мне подсказывает, что в случае с PLC ну скажем фирмы Siemens :) ничего
> "выжимать" не пришлось бы.

Провоцируешь ;)??? А если серьезно, то учти, что контроллер на катере еще и выдавал аналоговые данные на АРМ с тем же шагом 10 мс по Ethernet. Что-то я не припомню, чтобы на Симатике без проблем удавалось так сделать. Я не говорю, что это невозможно в принципе, но "быстрые архивы", которые отображаются на графиках в WinCC далеко не в реальном времени - это не решение.
А померяться известными органами в данном случае довольно просто: какой процессор стоит внутри Simatic S7-400 в самом мощном варианте? Берем и сравниваем с тем, что стоит в CPU686. Далее накручиваем "накладные расходы" от операционной системы и ядра системы исполнения. Явно эти расходы будут больше на PLC. Вот оценка и получится.

С уважением,
Ярослав Евдокимов,
ООО "НПК "ЛЕНПРОМАВТОМАТИКА"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[5]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   21.05.07 09:20

Hello Гайдаш,

Friday, May 18, 2007, 12:47:24 PM, you wrote:

>> А коробочек с лейблом МЭК 61131-3 боюсь как огня

ГДМ> Не нужно их бояться, надо уметь с ними работать :)

Умею. И иногда даже работаю.
Более того, прекрасно знаю недостатки и ограничения МЭК 61131-3,
таящие в себе кучу неприятностей. Поэтому и боюсь.

ГДМ> P.S. Про надежность повеселили, спасибо.

На здоровье. Только тут не веселиться надо, а думать.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[5]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   21.05.07 09:32

> недостатки и ограничения МЭК 61131-3, таящие в себе кучу неприятностей

Где можно про эти "недостатки и ограничения" _почитать_? Сделал бы это с удовольствием, ибо за 5 лет работы с МЭК-контроллерами найти таких "неприятностей" не удалось, причем далеко не только мне одному. Зато в PC-совместимых контроллерах этого добра навалом - ну там испорченные кучи, указатели в никуда, выход за границы массива и т.д. и т.п.

> На здоровье. Только тут не веселиться надо, а думать

Опять же, такие заявления неплохо было бы подкреплять конкретными примерами из жизни. Как это делают специалиств ООО "НПК "ЛЕНПРОМАВТОМАТИКА", например. Или как это сделал я, приведя вполне конкретный критерий - категория SIL3 по IEC 61508. Не расскажете, как на базе PC-совместимого контроллера (ну, скажем, Octagon/Fastwell или что-нибудь подобное) сделать систему, которую можно будет сертифицировать по SIL3? Вот Вам и безопасность.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   21.05.07 09:35

> выдавал аналоговые данные на АРМ с тем же шагом 10 мс по Ethernet

В WinCC можно без проблем 100 мс сделать - я экспериментировал (до 200 тегов на экране - легко) :) Меньше - уже проблемно (я не знаю, как это сделать в WinCC, но зато знаю, как это сделать без WinCC), но скажи мне, пожалуйста, зачем нужно меньше, если на это добро будет смотреть человек?

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[6]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   21.05.07 09:57

ГДМ> Что-то мне подсказывает, что в случае с PLC ну скажем фирмы Siemens :)
ГДМ> ничего "выжимать" не пришлось бы.

Видимо, я не очень удачно использовал слово "выжимать".
Дело в том, что системный цикл в нашем контроллере организован так,
что во время простоя управляющая программа проводит дополнительные
измерения аналоговых параметров, фильтруя затем результаты этих
измерений. Обычно, в типовом нашем проекте, она в основном этим и
занимается, поскольку "полезную" часть системного цикла она исполняет
всего за несколько (порядка 8) миллисекунд. Число замеров для
фильтрации поэтому обычно равно нескольким десяткам (40-50).
В проекте СУК из-за короткого цикла число таких замеров получилось,
естественно, меньше (3-4).

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   21.05.07 10:12

> какой процессор стоит внутри Simatic S7-400 в самом мощном варианте?

А вот это тайна за семью печатами, но новые версии (4.1, 5.0) очень быстрые - примерно в 3 раза быстрее чем то, с чем ты в свое время имел дело.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Ярослав Евдокимов 
Дата:   21.05.07 10:48

Гайдаш Д.М. писал(а):

> скажи мне, пожалуйста, зачем нужно меньше, если на это добро будет смотреть человек?
Тут есть разные задачи:
1. Контроль текущего состояния - понятно, что чаще, чем раз в полсекунды человек все равно не воспримет.
2. Архивирование для последующего анализа - вот тут уже нужна дискретизация, адекватная динамике объекта управления, но на первый взгляд, графики по таким архивам не нужно быстро отображать - их все равно просматривают потом. Но есть еще одна штука:
3. Графики для наладки системы регулирования. Зачастую их нужно просматривать в реальном времени, а частота дискретизации у них должна быть достаточно высокой. Ты при настройке регулятора можешь не воспринимать каждый появляющийся срез аналогового параметра, но должен правильно видеть появляющийся график (отличить синусоиду от прямой или от случайной помехи :)), а появляться он должен быстро, поскольку за несколько секунд быстрый объект может улететь уже довольно далеко.

Поэтому считаю, что в некоторых случаях быстрая передача большого количества аналоговых данных на АРМ оператора - не чья-то прихоть, а вполне осмысленная задача.

С уважением,
Ярослав Евдокимов,
ООО "НПК "ЛЕНПРОМАВТОМАТИКА"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   21.05.07 11:07

П. 1 - вот и я о том же :)
П. 2 - архивы 10 мс без проблем сделать.
П. 3 - запаздывание в отображении графиков на полсекунды при настройке некритично - это те же полсекунды, которые нужны человеку для восприятия ;)

> быстрая передача большого количества аналоговых данных на АРМ оператора

Разумеется :) Только при чем тут PC vs. PLC? На PLC это все тоже можно сделать.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   21.05.07 13:42


> > какой процессор стоит внутри Simatic S7-400 в самом мощном варианте?
>
> А вот это тайна за семью печатами, но новые версии (4.1, 5.0) очень быстрые -
> примерно в 3 раза быстрее чем то, с чем ты в свое время имел дело.

До недавних пор был Intel 486, не помню какой уже. Самый последний перед Пентиумом, что ли... С пассивным охлаждением - это точно.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   21.05.07 14:22

В АСУ ТП идет миграция в строну распределенных систем. Постепенно переносится интеллектуальная нагрузка с контроллеров на датчики,  исполнительные механизмы и приборы контроля с взаимодействием по полевым сетям.
 Но к самим крнтроллерам выставляются новые требованияния, которых раньше не было. Например а АСУ ТП АЭС контроллеры не должны иметь никаких компонетов с принудительным охлаждением. Это означает что в контроллерный шкаф нельзя ставить РС. Да и выбор PLC достаточно ограничен.
Еще один фактор - показатель надежности. Для PLC цифры MTBF в 150 000 - 300 000 часов сейчас не редкость. Для РС - это пока недостижимая величина. Производительность PLC конечно меньше чем PC, но эта разница в подавляющем большинстве приложений не играет роли. Там же, где это существенно, применяются специализированные PLC, например, в АСУ ТП электрической части ТЭЦ и АЭС (электронное осциллографирование переходных процессов).

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Ярослав Евдокимов 
Дата:   21.05.07 17:57

Eugeen писал(а):

> Например а АСУ ТП АЭС контроллеры не должны иметь никаких компонетов с
> принудительным охлаждением. Это означает что в контроллерный шкаф нельзя ставить
> РС. Да и выбор PLC достаточно ограничен.
РС-совместимый - не означает тот же конструктив, что у РС. Например, у применяемых нами Octagon и Fastwel нет ни одного компонента с принудительным охлаждением. А вот у любимого здесь многими Simatic - есть.

> Еще один фактор - показатель надежности. Для PLC цифры MTBF в 150 000 - 300 000
> часов сейчас не редкость. Для РС - это пока недостижимая величина.
У Octagon - 200000 ч.: http://www.rts.ua/catalog/octagon/index.htm
Кстати, надеюсь, понятно, в чем состоит определенный обман, заключающийся в цифре MTBF?

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

С уважением,
Ярослав Евдокимов,
ООО "НПК "ЛЕНПРОМАВТОМАТИКА"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[4]: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   21.05.07 18:12


> > > какой процессор стоит внутри Simatic S7-400 в самом мощном варианте?
> >
> > А вот это тайна за семью печатами, но новые версии (4.1, 5.0) очень быстрые -
> > примерно в 3 раза быстрее чем то, с чем ты в свое время имел дело.
>
> До недавних пор был Intel 486, не помню какой уже. Самый последний перед
> Пентиумом, что ли... С пассивным охлаждением - это точно.

А сейчас там Motorola стоит, кстати.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   21.05.07 20:27

>У Octagon - 200000 ч.: http://www.rts.ua/catalog/octagon/index.htm
>Кстати, надеюсь, понятно, в чем состоит определенный обман, заключающийся в цифре >MTBF?

Хорошо бы такие данные получить от производителя, а не от безответственного украинского РТС. Случись что, они сразу "сольют воду", мол "за что купили" и т.д.
Интересно, что при 200000 ч.   на той же странице мы читаем: "Изделия фирмы Octagon Systems имеют ограниченную гарантию 3 года". Да и называть Octagon универсальным PC контроллером как то язык не поворачивается. Нет поддержки ни одной полевой шины. Полез, напр., на сайте Octagon искать Profibus устройства - получаю:
Your search - Profibus - did not match any documents.
Слишком (выражаясь Вашим языком)  уж узкоспециальное устройство этот Octagon.

Кстати, в АСУ ТП блоков ТЭЦ и ГРЭС с регулированием частоты и мощности, требуется точность поддержания частоты по нормам UCTE, а это значит что на 3000 об/мин точность - полоборота турбины. И такую точность надо выдерживать при переходах на разные уровни мощности от 70 до 100%! Да еще и не нарушить синхронизацию с сетью по частоте! А вы говорите "Это - слишком уж узкоспециальное приложение". Да по нормам UCTE почти вся Европа работает, да и у нас идет переоснащение блоков 200-800 Мвт по этим же нормам (Приказ РАО ЕЭС №524).



Желательно, чтобы фирмы-производители показывали не только расчетный MTBF, но и реальную статистику отказов по заявленному оборудованию. Тогда можно судить о реальной надежности и проводить сравнение.
 Посмотрев такую статистику одной фирмы, мы, например, предлагаем заказчику вообще не покупать ЗИП в течении 15-ти лет. Мы гарантируем, что при соблюдении инструкции по эксплуатации, оборудование этой фирмы будет работать безотказно весь плановый срок. Другое дело сам Заказчик часто не готов к такому уровню поддержания эксплуатации.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   21.05.07 21:29

> А вот у любимого здесь многими Simatic - есть

Твои данные устарели примерно на 3 года :) Уже давно (начиная с версии 4.0, кажется) даже самые мощные процессоры идут БЕЗ принудительного охлаждения ;)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[7]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 10:23

Hello Гайдаш,

Monday, May 21, 2007, 12:32:54 PM, you wrote:

>> недостатки и ограничения МЭК 61131-3, таящие в себе кучу неприятностей

ГДМ> Где можно про эти "недостатки и ограничения" _почитать_? Сделал бы это с
ГДМ> удовольствием, ибо за 5 лет работы с МЭК-контроллерами найти таких
ГДМ> "неприятностей" не удалось, причем далеко не только мне одному. Зато в
ГДМ> PC-совместимых контроллерах этого добра навалом - ну там испорченные кучи,
ГДМ> указатели в никуда, выход за границы массива и т.д. и т..п.

Про недостатки как стандарта, так и самих языков можно почитать тут:
reflex-language.narod.ru в разделе Публикации, в статьях также есть
ссылки и на другие ресурсы.

На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
задачи управления они в принципе не позволяют решать. Почитайте,
например статью из "Пром АСУ и контроллеров"  11, 2005. "Языки МЭК
61131-3 и возможные альтернативы".

И не надо стравнивать языки МЭК 61131-3 с Си, или Ассемблером, это
языки разных классов. Сравните с каким-нибудь QuickStep или Рефлексом.
Нет там никаких "куч" и "указателей в никуда".

>> На здоровье. Только тут не веселиться надо, а думать

ГДМ> Опять же, такие заявления неплохо было бы подкреплять конкретными
ГДМ> примерами из жизни. Как это делают специалиств ООО "НПК
ГДМ> "ЛЕНПРОМАВТОМАТИКА", например. Или как это сделал я, приведя вполне
ГДМ> конкретный критерий - категория SIL3 по IEC 61508. Не расскажете, как на
ГДМ> базе PC-совместимого контроллера (ну, скажем, Octagon/Fastwell или
ГДМ> что-нибудь подобное) сделать систему, которую можно будет сертифицировать
ГДМ> по SIL3? Вот Вам и безопасность.

Ну и начали бы с объяснения своего безудержного смеха. Про SIL3,
например, рассказали бы, где его от Вас требуют и зачем (специфика Ваших задач).
Почему не SIL1, или SIL0. И почему на Fastwel-е требования этого SIL не обеспечить.
Или просто бумажки не хватает?

Безопасность разная бывает. Или Вы считаете, что Ленпромавтоматика,
применив МикроПиСи, пошла на нарушение каких-то ГОСТов/РД? Каких?

А главное, при чем тут SIL и языки МЭК 61131-3? Что в них такого, чего нет  в
других языках?

Прошу прощения, но мне с трудом верится, что МЭК 61131-3 на 286
процессоре удовлетворяет SIL, а у МЭК на Пентиуме 300 МГц на SIL не хватит
сил. :-)

Короче, давайте веселиться вместе.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[6]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 10:25

Hello Гайдаш,

Monday, May 21, 2007, 1:12:36 PM, you wrote:

>> какой процессор стоит внутри Simatic S7-400 в самом мощном варианте?

ГДМ> А вот это тайна за семью печатами, но новые версии (4.1, 5..0) очень
ГДМ> быстрые - примерно в 3 раза быстрее чем то, с чем ты в свое время имел
ГДМ> дело.

 Ну, значит, Сименс наконец-то 286-е процессоры на 386-е поменяла.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 10:51

> Про недостатки как стандарта, так и самих языков можно почитать тут

А вот не поверите - читал :) Разбирать по полочкам никакого желания нет, но со многими "тезисами" я просто не согласен, т.к. имею опыт, их опровергающий.

> На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
> задачи управления они в принципе не позволяют решать

Откровенная ерунда. Как Вы считаете, управление газотурбинным двигателем, газотурбинным энергоблоком, электростанцией (многоагрегатной) или перегрузочной машиной для АЭС - это сложные задачи или "простенькие"?

> например, рассказали бы, где его от Вас требуют

Обычно требуют иностранные заказчики для весьма невинных задач вроде управления газоперекачивающим агрегатом или газотурбинным энергоблоком.

> И почему на Fastwel-е требования этого SIL не обеспечить

Потому что никто никогда это не сертифицирует.

> Короче, давайте веселиться вместе

Давайте :) Я всегла за позитив!!!

> Ну, значит, Сименс наконец-то 286-е процессоры на 386-е поменяла

Знаете как это называется? Ложь, клевета, передергивания... Чем Вас так лично зацепил Siemens? Отличное же железо - тут и спорить нечего.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[7]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 10:47

учим матчасть: http://www.iec.ch/zone/fsafety/pdf_safe/hld.pdf

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 10:52

Hello Eugeen,

Monday, May 21, 2007, 11:27:09 PM, you wrote:

>>У Octagon - 200000 ч.: http://www.rts.ua/catalog/octagon/index.htm
>>Кстати, надеюсь, понятно, в чем состоит определенный обман, заключающийся
в цифре >>MTBF?

E> Хорошо бы такие данные получить от производителя, а не от
E> безответственного украинского РТС. Случись что, они сразу "сольют воду",
E> мол "за что купили" и т.д.
E> Интересно, что при 200000 ч.   на той же странице мы читаем: "Изделия
E> фирмы Octagon Systems имеют ограниченную гарантию 3 года".

Гарантия  - это не срок службы. Вообще, гарантия три года - это
слишком много, подозреваю, сделано это для неспециалистов в теории
надежности.

E>  Да и называть
E> Octagon универсальным PC контроллером как то язык не поворачивается. Нет
E> поддержки ни одной полевой шины. Полез, напр., на сайте Octagon искать
E> Profibus устройства - получаю:
E> Your search - Profibus - did not match any documents.
E> Слишком (выражаясь Вашим языком)  уж узкоспециальное устройство этот
E> Octagon.

Профибаса, возможно, и нет, а может и есть.

E> Кстати, в АСУ ТП блоков ТЭЦ и ГРЭС с регулированием частоты и мощности,
E> требуется точность поддержания частоты по нормам UCTE, а это значит что на
E> 3000 об/мин точность - полоборота турбины. И такую точность надо
E> выдерживать при переходах на разные уровни мощности от 70 до 100%! Да еще
E> и не нарушить синхронизацию с сетью по частоте! А вы говорите "Это -
E> слишком уж узкоспециальное приложение". Да по нормам UCTE почти вся Европа
E> работает, да и у нас идет переоснащение блоков 200-800 Мвт по этим же
E> нормам (Приказ РАО ЕЭС  524).

Это делают, наверняка, узкоспециализированные устройства. И уж точно,
коль речь заходит о производительности, то ПЛК существенно уступают по
выч. мощности тому же Микро ПиСи.

E> Желательно, чтобы фирмы-производители показывали не только расчетный MTBF,
E> но и реальную статистику отказов по заявленному оборудованию. Тогда можно
E> судить о реальной надежности и проводить сравнение.
E>  Посмотрев такую статистику одной фирмы, мы, например, предлагаем
E> заказчику вообще не покупать ЗИП в течении 15-ти лет. Мы гарантируем, что
E> при соблюдении инструкции по эксплуатации, оборудование этой фирмы будет
E> работать безотказно весь плановый срок. Другое дело сам Заказчик часто не
E> готов к такому уровню поддержания эксплуатации.

Есть такое дело. Интересное и важное предложение. Касается любого
производителя. Вопрос только, как обеспечить достоверность цифр. У
меня лично к Сименсу очень настороженное отношение. Да и вообще,
производитель наверняка будет скрывать отказы.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[7]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 10:43

Владимир ,

А зачем путать в кучу SIL, IEC 61508 и  МЭК 61131-3?  Еще 61511 забыли кстати.

С уважением,
Милосердов Дмитрий Николаевич

> Прошу прощения, но мне с трудом верится, что МЭК 61131-3 на
> 286 процессоре удовлетворяет SIL, а у МЭК на Пентиуме 300 МГц
> на SIL не хватит сил. :-)
>
> Короче, давайте веселиться вместе.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[2]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 11:09

> И уж точно, коль речь заходит о производительности, то ПЛК существенно уступают по
> выч. мощности тому же Микро ПиСи.

Меня всегда очень умиляют такие безосновательные утверждения :) А ничего, что переход от MicroPC на S7-400 целых 5 лет назад позволил отказаться от использования двух корзинок с процессорами, которые были необходимы из-за того, что одна корзинка банально не тянула по производительности на наши задачи? И ничего, что за эти 5 лет производительность процессоров и объемы памяти в S7-400 возросли МНОГОКРАТНО? Прежде чем оперировать данными 10-тилетней давности неплохо все-таки ознакомиться с современными реалиями :)

> Да и вообще, производитель наверняка будет скрывать отказы

А вот с такими сентенциями лучше, наверное, не на техническую конференцию.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 11:14

> учим матчасть: http://www.iec.ch/zone/fsafety/pdf_safe/hld.pdf

Это не матчасть, а маленький кусочек верхушки айсберга под названием Safety Related Programmable Electronic Systems.

Кстати, заодно хотелось бы взглянуть на соответствующие сертификаты PC-совместимых контроллеров. Что будет делать адепт MicroPC, например, если заказчик выставит требование соответствия САУ категории SIL3? А иностранные заказчики ой как любят это требовать, причем не только западные, но и вполне себе наши, традиционно считающиеся "дикими" - Иран, например.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Ярослав Евдокимов 
Дата:   22.05.07 11:35

> Да и называть Octagon универсальным PC контроллером как то язык не поворачивается. > Нет поддержки ни
> одной полевой шины.
У нас есть архитетура, в которой MicroPC работает с распределенным УСО (в качестве УСО используются модули WAGO) именно по Profibus DP. Причем в системе не использовано ничего "самопального", плата COM-PB в формате MicroPC - серийное изделие фирмы Fastwel, а установленный на него коммуникационный процессор FBC выпускается Hilsher. Надо заметить, что при этом можно подключить любые Profibus-устройства, а при использовании совместно с COM-PB других коммуникационников (есть для разных шин) - получить поддержку соответствующей шины.
Такая система работает, и кстати, мы не единственные, кто так делает. Так что вполне отработанное и понятное решение.

С уважением,
Ярослав Евдокимов,
ООО "НПК "ЛЕНПРОМАВТОМАТИКА"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[2]: PC-совместимый контроллер vs PLC.
Автор: Ярослав Евдокимов 
Дата:   22.05.07 11:44

Гайдаш Д.М. писал(а):

> А ничего, что
> переход от MicroPC на S7-400 целых 5 лет назад позволил отказаться от
> использования двух корзинок с процессорами, которые были необходимы из-за того,
> что одна корзинка банально не тянула по производительности на наши задачи?
Извини, но вот тут уж ты передергиваешь. Или по твоему мнению две корзины в МСКУ-4510 были действительно _технически_ необходимы? Согласен, 5025 не потянул бы, но эта плата устарела уже тогда. А производительности 5066 вполне хватало - контроллер устройства управления всегда был загружен на исчезающе малую величину (2-3 мс из 250), а контроллер устройства регулирования тоже имел изрядный запас (насколько я помню, программа антипомпажного+топливного регулирования занимала около 5-7 мс из 20). Практически те же характеристики быстродействия выдавал и Simatic S7-400, который дороже в разы. Не знаю, какое быстродействие имеет нынешняя версия Симатика, но не забывай, что РС-совместимые тоже не стоят на месте.

С уважением,
Ярослав Евдокимов,
ООО "НПК "ЛЕНПРОМАВТОМАТИКА"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 10:57

Hello d,

Tuesday, May 22, 2007, 1:47:30 PM, you wrote:

drr>  учим матчасть: http://www.iec.ch/zone/fsafety/pdf_safe/hld.pdf

Спасибо!

Сразу же наткнулся на фразу:
Neither safety nor functional safety can be determined without
considering the systems as a whole and the environment with which they
interact.

Ну и об чем спичь?

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   22.05.07 11:50

Здравствуйте, Eugeen.

Вы писали 21 мая 2007 г., 20:27:09:

E> Да и называть Octagon универсальным PC контроллером как то язык
E> не поворачивается.
E> Нет поддержки ни одной полевой шины. Полез, напр., на сайте Octagon искать
E> Profibus устройства - получаю:
E> Your search - Profibus - did not match any documents.
E> Слишком (выражаясь Вашим языком)  уж узкоспециальное устройство этот
E> Octagon.

Вообще-то, Octagon - это не устройство. Octagon Systems - американская
фирма, производящая, в частности, модули в формате MicroPC и средства
их соединения. Да, действительно, модулей с поддержкой полевых шин
в гамме Октагона нет. Но у Фаствела есть MicroPC-шный модуль FBC, на
который устанавливается мезонинный модуль производства Synergetic,
поддерживающий одну из полевых шин (DeviceNet, Profibus DP/FMS, CANOpen,
InterBus, ASi, ControlNet или SDS). Именно модули Profibus мы как раз и
используем в наших проектах.

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   22.05.07 12:04

Eugeen писал(а):

> вообще не покупать ЗИП в течении 15-ти лет. Мы гарантируем, что при соблюдении
> инструкции по эксплуатации, оборудование этой фирмы будет работать безотказно
> весь плановый срок. Другое дело сам Заказчик часто не готов к такому уровню
> поддержания эксплуатации.

Интересно, входит ли в Ваши гарантии возмещение убытков в случае отказа? Если нет,
то вряд ли кто поведётся на это.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 11:23

Дмитрий,

а чего-то у нас так разговор пошел, про все вместе... говорили вроде
про ПК-совместимый и ПЛК (ПК-несовместимый) контроллер, а тут какой-то
SIL выполз, да 61508... Вы вот еще про 61511 предлагаете тему.

Я и сам в растерянности.

Смысл, наверное, есть, кругозор расширить, что тоже немаловажно, ну а
так с СИЛом, по-моему, чистый офф-топ.

Tuesday, May 22, 2007, 1:43:34 PM, you wrote:

drr> Владимир ,

drr> А зачем путать в кучу SIL, IEC 61508 и  МЭК 61131-3?  Еще 61511 забыли кстати.

drr> С уважением,
drr> Милосердов Дмитрий Николаевич

>> Прошу прощения, но мне с трудом верится, что МЭК 61131-3 на
>> 286 процессоре удовлетворяет SIL, а у МЭК на Пентиуме 300 МГц
>> на SIL не хватит сил. :-)
>>
>> Короче, давайте веселиться вместе.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 12:15

Привет!

Tuesday, May 22, 2007, 1:47:30 PM, you wrote:

drr>  учим матчасть: http://www.iec.ch/zone/fsafety/pdf_safe/hld.pdf

вот хороший обзор по SIL-ам http://www.exida.com/articles/prove.pdf
обзора такого качества от самого МЭКа никогда не дождешься. ;-)

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 13:42

> Neither safety nor functional safety can be determined without
> considering the systems as a whole and the environment with which they
> interact.

Все верно написано, но Вы когда-нибудь проходили процедуру валидации? Без сертифицированных железок в 99.99% случаев бессмысленно вообще начинать разработку. А так - да, рассматривается не только само железо в виде контроллеров, но и другие части системы вплоть до функционально-логических схем программного обеспечения.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 15:14

Стоп-стоп...дык я вообще молчал! :)))
Это у вас (не у Вас а у вас с Алексеем) речь про эту гремучую смесь стандартов речь зашла :)
Можете сам переписку поднять чтобы я не искал цитаты..

> Дмитрий,
>
> а чего-то у нас так разговор пошел, про все вместе...
> говорили вроде про ПК-совместимый и ПЛК (ПК-несовместимый)
> контроллер, а тут какой-то SIL выполз, да 61508... Вы вот еще
> про 61511 предлагаете тему.
>
> Я и сам в растерянности.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 15:12

Ну и я не пойму- при чем тут помесь 2-х разных стандартов не имеющих друг-к другу никакого отношения? :)

Алексей в принципе говорил про железо, на сколько я понял.. и применимости его по SIL3 (т.е. СПАЗ).
Ну и хренли..я еще сотню классических ПЛК вам найду НЕ сертифицированных по SIL3.
Вообще не пойму о чем спич у вас :) Намешали в кучу всего...

> drr>  учим матчасть: http://www.iec.ch/zone/fsafety/pdf_safe/hld.pdf
>
> Спасибо!
>
> Сразу же наткнулся на фразу:
> Neither safety nor functional safety can be determined
> without considering the systems as a whole and the
> environment with which they interact.
>
> Ну и об чем спичь?

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 15:17

Ну да, только номер SIL определяет Проектировщик совместно с Заказчиком при проведении HZOP.
Мы, автоматизаторы, вопринимаем это как свершившийся факт и берем под козырек исполнять :)
Искать оборудование, решения под нужный уровень.. И т.п.

> вот хороший обзор по SIL-ам http://www.exida.com/articles/prove.pdf
> обзора такого качества от самого МЭКа никогда не дождешься. ;-)

Адрес этого сообщения    Ответить на это сообщение
 
 Re[11]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   22.05.07 16:33

Вот и я пытаюсь разобраться, зачем Алексей к ночи SIL этот помянул...
если вопрос с бумажкой, так и надо про бумажку говорить, ну или если сложно
достать/сделать бумажку, действительно, надо искать железку с уже
готовым сертификатом.

Только техника (само железо) тут ни при чем, да и SILn на контроллер не
гарантирует SILn на СПАЗ. Так в стандарте написано. Ну и смысл?

Tuesday, May 22, 2007, 6:12:02 PM, you wrote:

drr> Ну и я не пойму- при чем тут помесь 2-х разных стандартов не имеющих друг-к другу никакого отношения? :)

drr> Алексей в принципе говорил про железо, на сколько я понял.. и применимости его по SIL3 (т.е. СПАЗ).
drr> Ну и хренли..я еще сотню классических ПЛК вам найду НЕ сертифицированных по SIL3.
drr> Вообще не пойму о чем спич у вас :) Намешали в кучу всего....



--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[11]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 16:53

> да и SILn на контроллер не гарантирует SILn на СПАЗ

Все верно - SILn на контроллер является НЕОБХОДИМЫМ условием, но никак не ДОСТАТОЧНЫМ. Но если на контроллер и среду разработки ПО нет сертификата SILn, то и система валидацию не пройдет.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   22.05.07 16:57

> я еще сотню классических ПЛК вам найду НЕ сертифицированных по SIL3

Найдите лучше PC-совместимый контроллер, сертифицированный по SIL3 :))

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[11]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   22.05.07 16:56

Реализация по SIL определяется на весь контур. Включая КИП.
Сертификат TUV по уровню SIL получают на систему. Без КИП.
Языки здесь вообще не при чем.

> Только техника (само железо) тут ни при чем, да и SILn на
> контроллер не гарантирует SILn на СПАЗ. Так в стандарте
> написано. Ну и смысл?

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   22.05.07 18:03

> Найдите лучше PC-совместимый контроллер, сертифицированный по SIL3 :))

Думаете, их не существует? Соответственный софт под Пентиум я нашел:

http://www.kw-software.com/com/index1024.html

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   22.05.07 20:13

Входит.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   23.05.07 09:01

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

Уважаемый Владимир,

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

Если мне не изменяет память, два года назад Вы уже писали в Конференции
про "недостатки и ограничения МЭК 61131-3". Но тогда оказалось, что у
Вас нет ни одного примера ПРАКТИЧЕСКОЙ задачи управления, которая не
решается на языках МЭК 61131 из-за их "ограниченности". Если у Вас за
два года появился хотя бы один такой пример (из вашей ПРАКТИКИ, а не
ТЕОРИИ), пожалуйста, расскажите.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[11]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   23.05.07 09:26

Думаю, что он к тому упомянул (и я с ним согласный здесь), что нет ни одного ПиСи-бэйсд ПЛК сертифицированного на SIL выше 1 как максимум :)
По крайней мере я не знаю таких.

>
> Вот и я пытаюсь разобраться, зачем Алексей к ночи SIL этот помянул...
> если вопрос с бумажкой, так и надо про бумажку говорить, ну
> или если сложно достать/сделать бумажку, действительно, надо
> искать железку с уже готовым сертификатом.
>

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[7]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   23.05.07 09:33

> Это не матчасть, а маленький кусочек верхушки айсберга под
> названием Safety Related Programmable Electronic Systems.

 Я для примера привел :)

> Кстати, заодно хотелось бы взглянуть на соответствующие
> сертификаты PC-совместимых контроллеров. Что будет делать
> адепт MicroPC, например, если заказчик выставит требование
> соответствия САУ категории SIL3? А иностранные заказчики ой
> как любят это требовать, причем не только западные, но и
> вполне себе наши, традиционно считающиеся "дикими" - Иран, например.

Да ничего не будут делать :) Не видел я таких сертификатов..
Мы сейчас их тоже требуем.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[9]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   23.05.07 09:37

Так это только софт...а железо?
Сертификат SIL на Систему! А не на ее составные части ИМХО.
Нафик он тогда кому нужен такой сертификат тогда..

> Думаете, их не существует? Соответственный софт под Пентиум я нашел:
>
> http://www.kw-software.com/com/index1024.html
>

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   23.05.07 10:11

А автор так ни разу больше в теме и не появился...

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 10:11

Tuesday, May 22, 2007, 1:51:54 PM, you wrote:

>> Про недостатки как стандарта, так и самих языков можно почитать тут

ГДМ> А вот не поверите - читал :) Разбирать по полочкам никакого желания нет,
ГДМ> но со многими "тезисами" я просто не согласен, т.к. имею опыт, их
ГДМ> опровергающий.

Ну и зря не делитесь своим опытом. В результате получается, что-то
типа: "знаю, что неправильно, но доказательств не приведу".

>> На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
>> задачи управления они в принципе не позволяют решать

ГДМ> Откровенная ерунда. Как Вы считаете, управление газотурбинным двигателем,
ГДМ> газотурбинным энергоблоком, электростанцией (многоагрегатной) или
ГДМ> перегрузочной машиной для АЭС - это сложные задачи или "простенькие"?

Все зависит от алгоритма. Само по себе слово "АЭС", которым Вы,
пардон, козыряете, о сложности алгоритма ничего не говорит.
С алгоритмами гидроэлектростанций знаком, ничего сложного там нет.
С алгоритмами ТЭЦ на FBD имел дело, тут чуть посложнее, но: либо все
примитивно, либо начинается неперевариваемая каша... названная
разработчиком как-то, типа, "группа функционального управления", или
"функции группового управления", уже не упомню... суть не в названии,
а в том, что внутри... а внутри - низкоуровневое программирование
машины состояний средствами FBD... Вот где откровенная ерунда, когда
весьма средненькие алгоритмы превращаются в спагетти-код.

>> например, рассказали бы, где его от Вас требуют

ГДМ> Обычно требуют иностранные заказчики для весьма невинных задач вроде
ГДМ> управления газоперекачивающим агрегатом или газотурбинным энергоблоком.

>> И почему на Fastwel-е требования этого SIL не обеспечить

ГДМ> Потому что никто никогда это не сертифицирует.

Чего-то я не разглядел тут ответа на исходный вопрос. Что мешает
сертифицировать системы на Фаствеле под SILn?

>> Короче, давайте веселиться вместе

ГДМ> Давайте :) Я всегла за позитив!!!

>> Ну, значит, Сименс наконец-то 286-е процессоры на 386-е поменяла

ГДМ> Знаете как это называется? Ложь, клевета, передергивания... Чем Вас так
ГДМ> лично зацепил Siemens? Отличное же железо - тут и спорить нечего.

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

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[13]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 10:14

А Вы процитировать пункт стандарта, из которого это следует?

Tuesday, May 22, 2007, 7:53:15 PM, you wrote:

>> да и SILn на контроллер не гарантирует SILn на СПАЗ

ГДМ> Все верно - SILn на контроллер является НЕОБХОДИМЫМ условием, но никак не
ГДМ> ДОСТАТОЧНЫМ. Но если на контроллер и среду разработки ПО нет сертификата
ГДМ> SILn, то и система валидацию не пройдет.



--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: *SPAM* Score: 6.4/5.0 - Re: Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 10:26

Tuesday, May 22, 2007, 2:09:54 PM, you wrote:

>> И уж точно, коль речь заходит о производительности, то ПЛК существенно уступают по
>> выч. мощности тому же Микро ПиСи.

ГДМ> Меня всегда очень умиляют такие безосновательные утверждения :) А ничего,
ГДМ> что переход от MicroPC на S7-400 целых 5 лет назад позволил отказаться от
ГДМ> использования двух корзинок с процессорами, которые были необходимы из-за
ГДМ> того, что одна корзинка банально не тянула по производительности на наши
ГДМ> задачи? И ничего, что за эти 5 лет производительность процессоров и объемы
ГДМ> памяти в S7-400 возросли МНОГОКРАТНО? Прежде чем оперировать данными
ГДМ> 10-тилетней давности неплохо все-таки ознакомиться с современными реалиями
ГДМ> :)

"Не верю". Я бы предпочел менее эмоциональное и более строгие
доказательства. Что за проц стоял в "МикроПиСи", что за задача, что
там не хватало, на чем программировали, и т.д.

Ну либо по-простому, можно ограничиться сравнительными
характеристиками процессоров.

>> Да и вообще, производитель наверняка будет скрывать отказы

ГДМ> А вот с такими сентенциями лучше, наверное, не на техническую конференцию.

Возможно, но тогда мы не будем иметь правильной картинки
происходящего. Это же человеческий фактор. Даже в SIL-е человеческий
фактор учитывается. И это правильно.

Производитель заинтересован скрывать отказы и аварии, что он и делает.
Не только в области автоматизации. В области автомобилестроения это
стандартная практика.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[11]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 10:29

Hello Гайдаш,

Tuesday, May 22, 2007, 4:42:02 PM, you wrote:

>> Neither safety nor functional safety can be determined without
>> considering the systems as a whole and the environment with which they
>> interact.

ГДМ> Все верно написано, но Вы когда-нибудь проходили процедуру валидации? Без
ГДМ> сертифицированных железок в 99.99% случаев бессмысленно вообще начинать
ГДМ> разработку. А так - да, рассматривается не только само железо в виде
ГДМ> контроллеров, но и другие части системы вплоть до функционально-логических
ГДМ> схем программного обеспечения.

Нет, Дмитрий Михайлович, не проходоил. Поэтому и прошу, пояснить и
рассказать. То, с чем я поверхностно ознакомился, пока не говорит о
невозможности использовать МикроПиСи в системах, сертифицируемых на
SILn.

Какой пункт стандарта запрещает это делать?

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 10:36

Hello Sergey,

Wednesday, May 23, 2007, 12:01:03 PM, you wrote:


>> >> недостатки и ограничения МЭК 61131-3, таящие в себе кучу
SS> неприятностей
SS> ...
>> На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
>> задачи управления они в принципе не позволяют решать...

SS> Уважаемый Владимир,

SS> позвольте напомнить Вам, что многократное повторение одного и того же
SS> спорного утверждения не делает это утверждение истинным.

SS> Если мне не изменяет память, два года назад Вы уже писали в Конференции
SS> про "недостатки и ограничения МЭК 61131-3". Но тогда оказалось, что у
SS> Вас нет ни одного примера ПРАКТИЧЕСКОЙ задачи управления, которая не
SS> решается на языках МЭК 61131 из-за их "ограниченности". Если у Вас за
SS> два года появился хотя бы один такой пример (из вашей ПРАКТИКИ, а не
SS> ТЕОРИИ), пожалуйста, расскажите.

Сергей, Вы просто запамятовали... Я предлагал всем адептам МЭК 61131-3
решить простенькую задачку: http://reflex-language.narod.ru/bottle/spec_bottle.htm
Жду решений до сих пор.

Может я что-то пропустил, тогда продублируйте, пожалуйста, решение.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   23.05.07 11:22

> >> На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
> >> задачи управления они в принципе не позволяют решать
>
> ГДМ> Откровенная ерунда. Как Вы считаете, управление газотурбинным двигателем,
> ГДМ> газотурбинным энергоблоком, электростанцией (многоагрегатной) или
> ГДМ> перегрузочной машиной для АЭС - это сложные задачи или "простенькие"?
>
> Все зависит от алгоритма. Само по себе слово "АЭС", которым Вы,
> пардон, козыряете, о сложности алгоритма ничего не говорит.

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

> С алгоритмами гидроэлектростанций знаком, ничего сложного там нет.

А я вот не знаком, причем не только с алгоритмами гидроэлектростанций (к чему это приплетено было - совершенно неясно), но и еще много с чем, однако не беру на себя смелость утверждать, что все задачи, кроме тех, которыми занимаюсь я, простые ;)

> С алгоритмами ТЭЦ на FBD имел дело

Ну и что это доказывает? То, что разработчик выбрал неправильный инструмент? На FBD удобно "рисовать крупными мазками", а для низкоуровневых вещей есть более удобные средства, которыми все получается красиво. Поставить себе задачу реализовать алгоритм управления сложным технологическим объектом полностью на FBD можно, но вот нужно ли? Некоторые делают - получается тихий ужас. Но языки МЭК не ограничиваются FBD.

> Чего-то я не разглядел тут ответа на исходный вопрос. Что мешает
> сертифицировать системы на Фаствеле под SILn?

Отсутствие соответствующей сертификации у Фаствела.

> Только дорого у них все

Есть и дороже :)

> закрыто

Опять фантазии в ход пошли :) Что там закрыто-то? Profibus может быть или Profinet? Или Modbus закрылся вдруг? Или RS-232/422/485 и ASCII-протоколы вдруг тоже закрытыми стали?

> и однажды связавшись с Сименсом, поменять его в
> случае необходимости будет очень и очень накладно. Вот собственно и все.

Аналогично можно сказать про любого другого производителя. Вопрос в том, что понимать под "накладно". Поменять легко можно только "АСУТП" на базе обычного "писюка", на котором под виндой крутится написанная студентом Васей Пупкиным супер-программа.

> А Вы процитировать пункт стандарта, из которого это следует?

У меня под рукой нет первичного документа IEC 61508, но есть EN 954-1 :) Там написано буквально следующее:

Safety-related part of control systems and/or their safety devices and their components must be designed, constructed, selected, assembled and combined in accordance with the relevant standards such that they can withstand the expected influence

> Какой пункт стандарта запрещает это делать?

Вы хотите поставить перед собой задачу сертифицировать на соответствие требованиям безопасности железку стороннего производителя? :))))))))) Ну что же, это даже достойнее, чем писать программу управления турбиной на FBD :)))

> Что за проц стоял в "МикроПиСи", что за задача, что
> там не хватало, на чем программировали, и т.д.

Модуль центрального процессора 5066 (5x68 133 МГц)
Задача - управление газоперекачивающим агрегатом (управление газотурбинным двигателем, антипомпажное регулирование компрессором, управление обвязкой)
Программировали на Borland C++ 3.1 :)

В один контроллер все не влезло, причем не только у нас, но и у других фирм, которые пытались решить ту же задачу, тоже :) И даже сейчас не у всех получается - на Rockwell не получилось в один контроллер все впихнуть, например.

> Производитель заинтересован скрывать отказы и аварии

Скрыть отказы он может только в одном случае - если он никому не будет продавать свою продукцию :)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   23.05.07 11:23

> > Найдите лучше PC-совместимый контроллер, сертифицированный по
SIL3 :))

> Думаете, их не существует? Соответственный софт под Пентиум я нашел:
> http://www.kw-software.com/com/index1024.html

Уважаемый Валерий,

Информация на указанном Вами сайте наводит на некоторые размышления.

1. Продукт KW-Software, который громко называется SAFEPROG
programming platform, обеспечивает безопасные программные решения
ИСКЛЮЧИТЕЛЬНО при использовании языков программирования IEC 61131.
Т.е. другие языки (Си, Ассемблер и т.д.), которые обеспечивают
(теоретически) преимущества PC-совместимого контроллера
(универсальность, высокая производительность) не упоминаются.

2. В сертификате TUV, который выложен у на сайте KW-Software,
говорится что он касается только ПРОЦЕССА разработки софта в ДАННОЙ
компании и НЕ касается САМОГО программного продукта. Чувствуете
разницу?

3. На сайте KW-Software выложен также сертификат соответствия PLCopen
safety specification. На сайте PLCopen в разделе "Compliance of
Suppliers of Safety Certified Products", упомянуты только 2 фирмы: KW-
Software и Phoenix Contact. Причем в качестве примера применения
своего продукта KW-Software указывает Phoenix safety PLC. Что бы это
значило?

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   23.05.07 12:32

> SS> ... Если у Вас за
> SS> два года появился хотя бы один такой пример (из вашей ПРАКТИКИ,
а не
> SS> ТЕОРИИ), пожалуйста, расскажите.
>
> Сергей, Вы просто запамятовали... Я предлагал всем адептам МЭК
61131-3
> решить простенькую задачку: http://reflex-
language.narod.ru/bottle/spec_bottle.htm
> Жду решений до сих пор.


Владимир, не хочется повторяться, но мне кажется, что Вы по-прежнему
(как и 2 года назад) своеобразно понимаете слово "ПРАКТИКА" и не
отличаете его от слова "ТЕОРИЯ".
Ваш пример с линией розлива мне кажется придуманным. Безусловно, это
годится в качестве задачки для студентов-"автоматизаторов", но к
реальной жизни это не имеет никакого отношения.
Если я ошибаюсь, и эта задача ПРАКТИЧЕСКИ решалась (и решена) Вами НА
ПРОИЗВОДСТВЕ, прошу меня извинить. В таком случае укажите,
пожалуйста: где (на каком предприятии), когда (год), на каком
контроллере (производитель, марка), с каким софтом.

А также хочу заметить, что у меня есть некоторый ПРАКТИЧЕСКИЙ опыт
работы на таком производстве. В 1997-98 годах я был начальником
отдела автоматизации завода группы компаний "КС". У нас было 3 линии
розлива газированных напитков: бутылки 1,5 и 0,5 л, банки 0,33 л.
Линии импортные, вся автоматизация сделана на контроллерах SIMATIC
S5. Язык программирования, как Вы, наверное, догадались,
не "Рефлекс", а KOP-FUP-AWL (из 61131-3). Как ни странно,
работает ! :-))
(К слову, реальные задачи там, мягко говоря, немного сложнее, чем
описанные на Вашем сайте).

Так что слухи про "недостатки и ограничения МЭК 61131-3, таящие в
себе кучу неприятностей", сильно преувеличены :-).
Если у Вас есть другие (ПРАКТИЧЕСКИЕ) аргументы, "благоволите
предъявить", как говорил проф. Преображенский.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 PC-совместимый контроллер vs PLC.
Автор: Кедык Олег Васильевич 
Дата:   23.05.07 12:30

>> Сергей, Вы просто запамятовали... Я предлагал всем адептам МЭК
61131-3
>> решить простенькую задачку:
http://reflex-language.narod.ru/bottle/spec_bottle.htm
>> Жду решений до сих пор.

>> Может я что-то пропустил, тогда продублируйте, пожалуйста, решение.

Так как ни одна личность не прислала Владимиру решения этой простенькой
задачи на языке МЭК 61131-3, делаем соответствующие выводы и обсуждение
темы закрываем! :-)))





С уважением,
Руководитель проекта,
ЗАО "Компания СЗМА",
Кедык Олег Васильевич,
тел.  8(812)431-98-83,
факс  8(812)232-07-75

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   23.05.07 13:36

> Входит.
>
> С уважением, Катковский Е.А.

Если это ещё дополняется солидными активами типа недвижимости и пр., тогда это круто.

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: *SPAM* Score: 5.1/5.0 - *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   23.05.07 15:22

Wednesday, May 23, 2007, 3:32:12 PM, you wrote:


>> SS> ... Если у Вас за
>> SS> два года появился хотя бы один такой пример (из вашей ПРАКТИКИ, а не
>> SS> ТЕОРИИ), пожалуйста, расскажите.
>>
>> Сергей, Вы просто запамятовали... Я предлагал всем адептам МЭК 61131-3
>> решить простенькую задачку: http://reflex-language.narod.ru/bottle/spec_bottle.htm
>> Жду решений до сих пор.


SS> Владимир, не хочется повторяться, но мне кажется, что Вы по-прежнему
SS> (как и 2 года назад) своеобразно понимаете слово "ПРАКТИКА" и не
SS> отличаете его от слова "ТЕОРИЯ".
SS> Ваш пример с линией розлива мне кажется придуманным. Безусловно, это
SS> годится в качестве задачки для студентов-"автоматизаторов", но к
SS> реальной жизни это не имеет никакого отношения.

В реальной жизни будет то же самое, но с кучей дополнительных условий
по интерфейсу пользователя. Оно Вам нужно?

SS> Если я ошибаюсь, и эта задача ПРАКТИЧЕСКИ решалась (и решена) Вами НА
SS> ПРОИЗВОДСТВЕ, прошу меня извинить. В таком случае укажите,
SS> пожалуйста: где (на каком предприятии), когда (год), на каком
SS> контроллере (производитель, марка), с каким софтом.

Эта конкретно задача мною практически не решалась, но это, уверяю Вас,
практическая задача. И это простая задача. Я мог бы Вам подкинуть
посложнее задачу, которая мной ПРАКТИЧЕСКИ решалась, например, задачу
по автоматизации разнообразных установок для выращивания
монокристаллов кремния методом Чохральского, но, во-первых,
документация закрыта, а, во-вторых, это 200+ листов формата А3 одних
блок-схем на каждый вариант. ПРАКТИЧЕСКОГО смысла в этом нет, т.к.
только поверхностное осознание задачи у Вас займет месяц.

SS> А также хочу заметить, что у меня есть некоторый ПРАКТИЧЕСКИЙ опыт
SS> работы на таком производстве. В 1997-98 годах я был начальником
SS> отдела автоматизации завода группы компаний "КС". У нас было 3 линии
SS> розлива газированных напитков: бутылки 1,5 и 0,5 л, банки 0,33 л.
SS> Линии импортные, вся автоматизация сделана на контроллерах SIMATIC
SS> S5. Язык программирования, как Вы, наверное, догадались,
SS> не "Рефлекс", а KOP-FUP-AWL (из 61131-3). Как ни странно,
SS> работает ! :-))

Ну и здорово, что работает! Только вопрос не в этом, а в том, сколько
сил потрачено на это "работает", и сколько понадобиться сил, чтобы
модифицировать это "работает" в случае необходимости.

SS> (К слову, реальные задачи там, мягко говоря, немного сложнее, чем
SS> описанные на Вашем сайте).

Я к исходной постановке задачи тоже имею претензии.
Ну, давайте решать задачу в Вашей постановке. Я даже на это согласен.
Хотя это нежелательно, т.к. приведенная задача - это стандартная
ПРАКТИЧЕСКАЯ задача, используемая для сравнения методик
программирования алгоритмов управления.

SS> Так что слухи про "недостатки и ограничения МЭК 61131-3, таящие в
SS> себе кучу неприятностей", сильно преувеличены :-).
SS> Если у Вас есть другие (ПРАКТИЧЕСКИЕ) аргументы, "благоволите
SS> предъявить", как говорил проф. Преображенский.

У меня есть и другие практические аргументы, только предъявлять я их
не буду. Т.к., во-первых, это связано с конкретными потерями ресурсов
конкретными компаниями, а, во-вторых, хватит и уже озвученных.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   23.05.07 15:42

> 1. Продукт KW-Software, который громко называется SAFEPROG
> programming platform, обеспечивает безопасные программные решения
> ИСКЛЮЧИТЕЛЬНО при использовании языков программирования IEC 61131.
> Т.е. другие языки (Си, Ассемблер и т.д.), которые обеспечивают
> (теоретически) преимущества PC-совместимого контроллера
> (универсальность, высокая производительность) не упоминаются.

Не принципиально. Спрашивали, способен ли вообще.

> 2. В сертификате TUV, который выложен у на сайте KW-Software,
> говорится что он касается только ПРОЦЕССА разработки софта в ДАННОЙ
> компании и НЕ касается САМОГО программного продукта. Чувствуете
> разницу?

Читайте внимательнее. Например:
"SAFEGRID is the safe device parameterization tool on the PC for safe switching
devices and safe small controls, certified according to IEC 61508 SIL3."

SafeOS также сертифицирован под SIL3, ссылку я нашёл только на немецком.


> 3. На сайте KW-Software выложен также сертификат соответствия PLCopen
> safety specification. На сайте PLCopen в разделе "Compliance of
> Suppliers of Safety Certified Products", упомянуты только 2 фирмы: KW-
> Software и Phoenix Contact. Причем в качестве примера применения
> своего продукта KW-Software указывает Phoenix safety PLC. Что бы это
> значило?

Это значит, что в эту область начали влезать не так давно, а также,
что об этом не обязательно трубят на весь мир.

Люди, ну что вы такие недоверчивые? Есть такие системы, есть. Например, вот статья на
немецком, как сертифицировали под SIL4 троированную систему на Pentium MMX с ChorusOS
для управления поездами в европейских сетях. Нашли в системе пару недостатков, после
доработки тестировали снова. Дело было три года назад, так что сейчас  система уже
вполне может быть готова и даже работать. Так что системы высшей степени безопасности на
основе Pentium MMX разрабатывались по крайней мере ещё три года назад.

http://rt.cs.tu-berlin.de/forschung/paper/maerz_2004_Dresden.pdf

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 *SPAM* Score: 5.1/5.0 - *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   24.05.07 09:35

Практических ЗАДАЧ много. А вот практических РЕШЕНИЙ - гораздо
меньше. Я имею в виду решения, которые РЕАЛИЗОВАНЫ и РАБОТАЮТ на
производстве.
Если Вы вместо обсуждения именно таких ПРАКТИЧЕСКИХ РЕШЕНИЙ опять
предлагаете пообсуждать свои ТЕОРЕТИЧЕСКИЕ ЗАДАЧИ, пардон - не
интересно, поскольку пользы никому (кроме Вас, возможно) это не
принесет.


> документация закрыта, а, во-вторых, это 200+ листов формата А3 одних
> блок-схем на каждый вариант. ПРАКТИЧЕСКОГО смысла в этом нет, т.к.
> только поверхностное осознание задачи у Вас займет месяц.

Я не сомневаюсь, что "ПРАКТИЧЕСКОГО смысла в ЭТОМ нет" :-))). Оценить
красоту аргумента в "200+ листов формата А3" никто, кроме автора, не
сможет.


> Ну и здорово, что работает! Только вопрос не в этом, а в том,
сколько
> сил потрачено на это "работает", и сколько понадобиться сил, чтобы
> модифицировать это "работает" в случае необходимости.

В случае необходимости сил и времени потребуется очень немного. Как
минимум, не больше, чем для изменений на языке "Рефлекс".

Впрочем, давайте сравним. Строка из Вашей программы:
ЕСЛИ (К_БАК_ПУСТ) В СЛЕДУЮЩЕЕ;

Что нужно сделать, чтобы инвертировать условие? Думаю, что-то типа:
ЕСЛИ (НЕ(К_БАК_ПУСТ)) В СЛЕДУЮЩЕЕ; (Если по другому, исправьте,
пожалуйста.)

А потом нужно еще:
- заново скомпилировать программу
- остановить процесс
- остановить контроллер
- залить новую программу
- стартовать контроллер
- собрать условия готовности технологии
- стартовать процесс

Я думаю, вышеописанные действия с PC-совместимым контроллером и
языком Рефлекс займут минут 20-30 (20-30 минут - примерное время
останова/пуска РЕАЛЬНОЙ линии розлива). Не считая времени ожидания,
когда технологи позволят остановить процесс (а это может быть и до
конца смены, например, если только начали розлив партии).


При работе с SIMATIC или Allen-Bradley на языке FBD такое изменение
потребует примерно следующего:
- 2 клика мышкой, чтобы изменить "прямой" вход на инверсный (кликом
выделить вход, кликнуть иконку инверсного)
- еще несколько кликов мышкой (примерно 10-15 секунд), чтобы залить
изменения
Причем изменения вносятся БЕЗ ОСТАНОВА ПРОЦЕССА.

Все вместе - менее 1 минуты.

Ну, и в каком месте искать "ограничения" языков МЭК и связанные с
ними неприятности?



> У меня есть и другие практические аргументы, только предъявлять я их
> не буду...

Прошу прощения, ПРАКТИЧЕСКИХ аргументов с Вашей стороны пока еще НЕ
БЫЛО! Были только ТЕОРЕТИЧЕСКИЕ !!!

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   24.05.07 09:49

Скорее всего автор темы нашел ответ на:
http://www.lleo.aha.ru/na/.Там конкретная ссылка!

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: *SPAM* Score: 5.1/5.0 - *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   24.05.07 10:27

> еще несколько кликов мышкой (примерно 10-15 секунд), чтобы залить изменения

В своей личной практике подгружал изменения в контроллер в процессе запуска газотурбинного двигателя - под таким грузом ответственности это делается за 3-5 секунд :))))) А 10-50 секунд нужны на то, чтобы найти ошибку в программе и исправить ее :) А вот 20-30 минут - это чтобы пульс в норму пришел после этого и помолиться :)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[11]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   24.05.07 13:49

Hello Гайдаш,

Wednesday, May 23, 2007, 2:22:30 PM, you wrote:

>> >> На простеньких задачах, языки МЭК ведут себя неплохо, а вот сложные
>> >> задачи управления они в принципе не позволяют решать
>>
>> ГДМ> Откровенная ерунда. Как Вы считаете, управление газотурбинным
ГДМ> двигателем,
>> ГДМ> газотурбинным энергоблоком, электростанцией (многоагрегатной) или
>> ГДМ> перегрузочной машиной для АЭС - это сложные задачи или
ГДМ> "простенькие"?
>>
>> Все зависит от алгоритма. Само по себе слово "АЭС", которым Вы,
>> пардон, козыряете, о сложности алгоритма ничего не говорит.

ГДМ> Вы читаете только то, что хотите прочитать. Не нужно вырывать буквы из
ГДМ> контекста - не АЭС, а _перегрузочная машина_ для АЭС.

Ну не знаком я со спецификой АЭС, и не знаю, как работает перегрузочная
машина для АЭС.

>> С алгоритмами гидроэлектростанций знаком, ничего сложного там нет.

ГДМ> А я вот не знаком, причем не только с алгоритмами гидроэлектростанций (к
ГДМ> чему это приплетено было - совершенно неясно), но и еще много с чем,
ГДМ> однако не беру на себя смелость утверждать, что все задачи, кроме тех,
ГДМ> которыми занимаюсь я, простые ;)

А я с АЭС не знаком. А про гидроэлектространцию упомянул, т.к. это как
и АЭС - энергетика, электростанция.

А попутно замечу, что глупые слова, которые Вы мне пытаетесь приписать, про
исключительность моих задач я никогда не произносил.

>> С алгоритмами ТЭЦ на FBD имел дело

ГДМ> Ну и что это доказывает? То, что разработчик выбрал неправильный
ГДМ> инструмент? На FBD удобно "рисовать крупными мазками", а для
ГДМ> низкоуровневых вещей есть более удобные средства, которыми все получается
ГДМ> красиво. Поставить себе задачу реализовать алгоритм управления сложным
ГДМ> технологическим объектом полностью на FBD можно, но вот нужно ли?
ГДМ> Некоторые делают - получается тихий ужас. Но языки МЭК не ограничиваются
ГДМ> FBD.

То есть Вы сомневаетесь в квалификации исполнителей?
Уверяю Вас, зря. Это _очень_ квалифицированные люди.

>> Чего-то я не разглядел тут ответа на исходный вопрос. Что мешает
>> сертифицировать системы на Фаствеле под SILn?

ГДМ> Отсутствие соответствующей сертификации у Фаствела.

Это какой пункт стандарта?

>> Только дорого у них все

ГДМ> Есть и дороже :)

возможно

>> закрыто

ГДМ> Опять фантазии в ход пошли :) Что там закрыто-то? Profibus может быть или
ГДМ> Profinet? Или Modbus закрылся вдруг? Или RS-232/422/485 и ASCII-протоколы
ГДМ> вдруг тоже закрытыми стали?

да все закрыто, даже какой процессор стоит - секрет.

>> и однажды связавшись с Сименсом, поменять его в
>> случае необходимости будет очень и очень накладно. Вот собственно и все.

ГДМ> Аналогично можно сказать про любого другого производителя. Вопрос в том,
ГДМ> что понимать под "накладно". Поменять легко можно только "АСУТП" на базе
ГДМ> обычного "писюка", на котором под виндой крутится написанная студентом
ГДМ> Васей Пупкиным супер-программа.

Да, примерно то же самое можно сказать и про других производителей,
поддерживающих МЭК 61131-3. Я об этом и говорю.

>> А Вы процитировать пункт стандарта, из которого это следует?

ГДМ> У меня под рукой нет первичного документа IEC 61508, но есть EN 954-1 :)
ГДМ> Там написано буквально следующее:

ГДМ> Safety-related part of control systems and/or their safety devices and
ГДМ> their components must be designed, constructed, selected, assembled and
ГДМ> combined in accordance with the relevant standards such that they can
ГДМ> withstand the expected influence

Ну и? Должны быть. Это очевидное требование. Если у Вас, например,
рабочий диапазон температур для системы от -40 С, то и компоненты
должны держать эту температуру. Или Вы "expected influence" переводите
как "desired SIL"? Это весьма дискуссионный перевод.

>> Какой пункт стандарта запрещает это делать?

ГДМ> Вы хотите поставить перед собой задачу сертифицировать на соответствие
ГДМ> требованиям безопасности железку стороннего производителя? :))))))))) Ну
ГДМ> что же, это даже достойнее, чем писать программу управления турбиной на
ГДМ> FBD :)))

Нет. Пока я хочу увидеть пункт стандарта, запрещающий использовать
компоненты, не сертифицированные на требуемый SIL. А потом, в случае
чудесного обнаружения такого пункта, у меня в планах поинтересоваться,
где же Вы берете сертифицированные шурупы, болты, кнопки, провода, и
прочую мелюзгу... или, скажем, где же Сименс берет сертифицированные
по SIL процессоры.

>> Что за проц стоял в "МикроПиСи", что за задача, что
>> там не хватало, на чем программировали, и т.д.

ГДМ> Модуль центрального процессора 5066 (5x68 133 МГц)
ГДМ> Задача - управление газоперекачивающим агрегатом (управление газотурбинным
ГДМ> двигателем, антипомпажное регулирование компрессором, управление обвязкой)
ГДМ> Программировали на Borland C++ 3.1 :)

ГДМ> В один контроллер все не влезло, причем не только у нас, но и у других
ГДМ> фирм, которые пытались решить ту же задачу, тоже :) И даже сейчас не у
ГДМ> всех получается - на Rockwell не получилось в один контроллер все
ГДМ> впихнуть, например.

К сожалению, этой информации мало. Единственно можно сказать - процессор - вполне.
Может, ЕЕПРОМ медленная, или ОЗУ... по объему - тоже вопросов нет.
А так, только на программистов можно грешить. Было бы интересно на
алгоритм посмотреть.

>> Производитель заинтересован скрывать отказы и аварии

ГДМ> Скрыть отказы он может только в одном случае - если он никому не будет
ГДМ> продавать свою продукцию :)

Имеется ввиду истинная статистика, разумеется. А отказы есть у всех.
Тут что-то скрывать глупо.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   24.05.07 14:09

Thursday, May 24, 2007, 12:35:56 PM, you wrote:
Ваш пример с линией розлива мне кажется придуманным. Безусловно, это
>> SS> годится в качестве задачки для студентов-"автоматизаторов", но к
>> SS> реальной жизни это не имеет никакого отношения. ...
>> Эта конкретно задача мною практически не решалась, но это, уверяю Вас,
>> практическая задача. И это простая задача. Я мог бы Вам подкинуть
>> посложнее задачу, которая мной ПРАКТИЧЕСКИ решалась,

SS> Практических ЗАДАЧ много. А вот практических РЕШЕНИЙ - гораздо
SS> меньше. Я имею в виду решения, которые РЕАЛИЗОВАНЫ и РАБОТАЮТ на
SS> производстве.
SS> Если Вы вместо обсуждения именно таких ПРАКТИЧЕСКИХ РЕШЕНИЙ опять
SS> предлагаете пообсуждать свои ТЕОРЕТИЧЕСКИЕ ЗАДАЧИ, пардон - не
SS> интересно, поскольку пользы никому (кроме Вас, возможно) это не
SS> принесет.

Ну, не хотите, как хотите, дело хозяйское. Мое дело было предложить,
Вы опять отказались.

>> документация закрыта, а, во-вторых, это 200+ листов формата А3 одних
>> блок-схем на каждый вариант. ПРАКТИЧЕСКОГО смысла в этом нет, т.к.
>> только поверхностное осознание задачи у Вас займет месяц.

SS> Я не сомневаюсь, что "ПРАКТИЧЕСКОГО смысла в ЭТОМ нет" :-))). Оценить
SS> красоту аргумента в "200+ листов формата А3" никто, кроме автора, не
SS> сможет.

Вот в том-то и дело. Для этого и нужны тестовые практические примеры.

>> Ну и здорово, что работает! Только вопрос не в этом, а в том, сколько
>> сил потрачено на это "работает", и сколько понадобиться сил, чтобы
>> модифицировать это "работает" в случае необходимости.

SS> В случае необходимости сил и времени потребуется очень немного. Как
SS> минимум, не больше, чем для изменений на языке "Рефлекс".

SS> Впрочем, давайте сравним. Строка из Вашей программы:
SS> ЕСЛИ (К_БАК_ПУСТ) В СЛЕДУЮЩЕЕ;

SS> Что нужно сделать, чтобы инвертировать условие? Думаю, что-то типа:
SS> ЕСЛИ (НЕ(К_БАК_ПУСТ)) В СЛЕДУЮЩЕЕ; (Если по другому, исправьте,
SS> пожалуйста.)

В Си-подобной нотации так:
ЕСЛИ (!К_БАК_ПУСТ) В СЛЕДУЮЩЕЕ;

SS> А потом нужно еще:
SS> - заново скомпилировать программу
SS> - остановить процесс
SS> - остановить контроллер
SS> - залить новую программу
SS> - стартовать контроллер
SS> - собрать условия готовности технологии
SS> - стартовать процесс

SS> Я думаю, вышеописанные действия с PC-совместимым контроллером и
SS> языком Рефлекс займут минут 20-30 (20-30 минут - примерное время
SS> останова/пуска РЕАЛЬНОЙ линии розлива). Не считая времени ожидания,
SS> когда технологи позволят остановить процесс (а это может быть и до
SS> конца смены, например, если только начали розлив партии).

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

SS> При работе с SIMATIC или Allen-Bradley на языке FBD такое изменение
SS> потребует примерно следующего:
SS> - 2 клика мышкой, чтобы изменить "прямой" вход на инверсный (кликом
SS> выделить вход, кликнуть иконку инверсного)
SS> - еще несколько кликов мышкой (примерно 10-15 секунд), чтобы залить
SS> изменения
SS> Причем изменения вносятся БЕЗ ОСТАНОВА ПРОЦЕССА.

SS> Все вместе - менее 1 минуты.

Ну и будет неправильно работать программа. :-) (см. замечание о
необходимости различения языка и его реализации).

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

SS> Ну, и в каком месте искать "ограничения" языков МЭК и связанные с
SS> ними неприятности?

В реальных практических задачах. Мы вроде с Вами договорились об этом.

>> У меня есть и другие практические аргументы, только предъявлять я их
>> не буду...

SS> Прошу прощения, ПРАКТИЧЕСКИХ аргументов с Вашей стороны пока еще НЕ
SS> БЫЛО! Были только ТЕОРЕТИЧЕСКИЕ !!!

Ну так давайте перейдем к практике!

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   24.05.07 17:41

> после этого и сравнивать как будут вести себя решения. ;-)))
> SS> Ну, и в каком месте искать "ограничения" языков МЭК и связанные с
> SS> ними неприятности?
> В реальных практических задачах. Мы вроде с Вами договорились об этом.
> >> У меня есть и другие практические аргументы, только предъявлять я их
> >> не буду...
> SS> Прошу прощения, ПРАКТИЧЕСКИХ аргументов с Вашей стороны пока еще НЕ
> SS> БЫЛО! Были только ТЕОРЕТИЧЕСКИЕ !!!
> Ну так давайте перейдем к практике!


Так будут МЭК разносить, поудобнее устраиваться ?:))

Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[11]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   24.05.07 20:37

Длинные простыни получаются, ну да ладно...

> Ну не знаком я со спецификой АЭС, и не знаю, как работает перегрузочная
> машина для АЭС.

Ну если для Вас это что-то значит, то описание матмодели, которая крутится в контроллерах в реальном времени, - это полпачки бумаги формата А4.

> А я с АЭС не знаком. А про гидроэлектространцию упомянул, т.к. это как
> и АЭС - энергетика, электростанция.

Специфика абсолютно другая, уверяю Вас.

> А попутно замечу, что глупые слова, которые Вы мне пытаетесь приписать, про
> исключительность моих задач я никогда не произносил.

Почему тогда Вы не верите специалистам с солидным опытом работы, когда они говорят, что на МЭК-языках успешно и красиво решаются достаточно сложные задачи управления, а не только "примитив"?

> То есть Вы сомневаетесь в квалификации исполнителей?
> Уверяю Вас, зря. Это _очень_ квалифицированные люди.

Зачем они писали все на FBD?


> ГДМ> Отсутствие соответствующей сертификации у Фаствела.
>
> Это какой пункт стандарта?

Требование, чтобы все элементы системы были сертифицированными.

> возможно

Цена обусловлена высоким качеством и надежностью элементов системы.

> да все закрыто, даже какой процессор стоит - секрет.

А что, если неизвестно какой там процессор стоит, то система неработоспособна? Мне вот абсолютно неинтересно, какой там стоит процессор. Мне важно, чтобы обеспечивалось заявленное быстродействие и функциональность (в широком смысле - включая надежность). А от того, какой там процессор стоит, мне не жарко и не холодно - не надо делать фетиш из железок и софта, это просто инструменты для достижения совсем других целей.

> Да, примерно то же самое можно сказать и про других производителей,
> поддерживающих МЭК 61131-3. Я об этом и говорю.

Вас не смущает, что есть масса PC-совместимых МЭК-контроллеров? Я вот, например, считаю, что если подсесть на Рефлекс, топотом от него уйти сложнее, чем от Сименса ;))

> ГДМ> Safety-related part of control systems and/or their safety devices and
> ГДМ> their components must be designed, constructed, selected, assembled and
> ГДМ> combined in accordance with the relevant standards such that they can
> ГДМ> withstand the expected influence
>
> Ну и? Должны быть.

Не "должны быть", а должны соответствовать стандартам.

> Нет. Пока я хочу увидеть пункт стандарта, запрещающий использовать
> компоненты, не сертифицированные на требуемый SIL.

Уверяю Вас, IEC 61508 содержит требования, аналогичные приведенным :)

> А потом, в случае чудесного обнаружения такого пункта, у меня в планах
> поинтересоваться, где же Вы берете сертифицированные шурупы, болты, кнопки,
> провода, и прочую мелюзгу...

Очень остроумно, продолжайте нас веселить :)

> К сожалению, этой информации мало. Единственно можно сказать - процессор -
> вполне.

Для определенных задач вполне, а для управления газоперекачивающим агрегатом его недостаточно. Повторяю то, что Вы благоразумно опустили, - на тот момент на рынке не было PC-based систем управления ГПА, которые бы функционировали на одном процессорном модуле. Насколько я знаю, таких серийных систем нет и сейчас, а то, что представляется на МВИ, построено на базе минимум двух процессорных модулей (это без резервирования).

> А так, только на программистов можно грешить. Было бы интересно на алгоритм
> посмотреть.

Такой же секрет, что и Ваши листы А3. В-основном, ничего сложного, но есть тонкости - задача управления подачей топлива в камеру сгорания и задача антипомпажного регулирования и защиты компрессора.

> Имеется ввиду истинная статистика, разумеется. А отказы есть у всех.
> Тут что-то скрывать глупо.

У нас есть своя статистика по Сименсу, основанная на 6-тилетнем опыте внедрения и эксплуатации систем в количестве _сотен_ штук в год. Хорошая статистика - подавляющее большинство отказов оборудования приходится на этап ПНР и не связано с надежностью самого железа. Отказы в эксплуатации единичны, причем часть из них также обсуловлена внешними причинами (пожар, например).

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   24.05.07 20:38

> Так будут МЭК разносить, поудобнее устраиваться ?

Не стоит :) Вряд ли тут будут что-то разносить, потому как большинство специалистов просто работает и им некогда заниматься ЕРУНДОЙ, решая какие-то искусственные задачи с заранее предсказуемым результатом :)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Виктор 
Дата:   25.05.07 04:39

Т.е. сертифицировать "железку" на основе МикроПиСи невозможно только потому,
что этого не делал Фаствел?
Было озвучено мнение, что оборудование с ядром ПиСи (в любом виде, MicroPC,
PC\104 и т.д.) ПРИНЦИПИАЛЬНО невозможно сертифицировать никому и никогда
только на том основании, что это оборудование на ПиСи. Хотелось бы услышать
аргументы в поддержку такого мнения.

Виктор Прилипко,
ОАО "ИНЭУМ"

> > Что мешает сертифицировать системы на Фаствеле под SILn?
>
> Отсутствие соответствующей сертификации у Фаствела.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Oleg.B.Filichkin 
Дата:   25.05.07 08:36

Тут написано-
===========
Вы тут смешиваете два вопрос: а) вопрос языка, как средства описания,
и б) вопрос реализации языка в виде транслятора, среды разработки,
вспомогательных функций. То, что Вы описываете, - это компиляционная
модель реализации языка, плюс отсутствие продвинутых средств загрузки.
Собственно к языку это не имеет никакого отношения.
================
Что-то совсем запуталси...
Об чем речь?
Об ПС вз ПЛС или о собственном языке?
Язык , не сомневаюсь, просто замечательный
Ну, и чего дальше-то?
Двадцать лет назад родная кафедра занималась разработкой испытательных
стендов ТРА ГТД.
Делалось, сдавалось, выключалось, закрывалось.
Встречаю однокурсников- чего делаешь? А то же самое, но не  на кафедре и с
ма-а-аленькой разницей - все это работает, и сильно востребовано.
К чему это?
А к тому, что от теории до ПРАКТИКИ - десятки лет, причем не только с точки
зрения программмирования, а КОМПЛЕКСНОГО РЕШЕНИЯ, вплоть до шурупов.
 А на удочку "свободы программирования" не поймаете, плавали, знаем...
по крайней мере, в решениях для промышленности.
Потерялся "свободный программист" - и труба. Снесли систему полностью.
Вот, скажем, для супербыстродействующих систем, например, для распознавания
траектории снаряда - тут VME64 как минимум - и языки всяческие
Для бортовых малогабаритных или др. уникальных - PC-104 кубиком.
Для холодильников и светофоров - король PIC.
Ни о чем спор как был, так и остался...

С уважением,
ГИП
ООО "АСУ-ТЭК"
О.Б.Филичкин
г. Пермь
fob( )asutek.perm.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   25.05.07 08:57

Что- я таких категоричных заявлений не помню :) Мои слова были- я таких сертифицированных писи не знаю. :)

> PC\104 и т.д.) ПРИНЦИПИАЛЬНО невозможно сертифицировать
> никому и никогда только на том основании, что это
> оборудование на ПиСи. Хотелось бы услышать аргументы в
> поддержку такого мнения.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   25.05.07 09:11

> Было озвучено мнение, что оборудование с ядром ПиСи (в любом виде, MicroPC,
> PC\104 и т.д.) ПРИНЦИПИАЛЬНО невозможно сертифицировать никому и никогда
> только на том основании, что это оборудование на ПиСи

Где конкретно было озвучено такое мнение???

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 09:20

Hello Kuzmin,

Thursday, May 24, 2007, 8:41:17 PM, you wrote:


>> после этого и сравнивать как будут вести себя решения. ;-)))
>> SS> Ну, и в каком месте искать "ограничения" языков МЭК и связанные с
>> SS> ними неприятности?
>> В реальных практических задачах. Мы вроде с Вами договорились об этом.
>> >> У меня есть и другие практические аргументы, только предъявлять я их
>> >> не буду...
>> SS> Прошу прощения, ПРАКТИЧЕСКИХ аргументов с Вашей стороны пока еще НЕ
>> SS> БЫЛО! Были только ТЕОРЕТИЧЕСКИЕ !!!
>> Ну так давайте перейдем к практике!


KY> Так будут МЭК разносить, поудобнее устраиваться ?:))

Зачем разносить? Я категорически против экстремизма. :-) Больных надо лечить.
Только теплое слово и забота.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   25.05.07 09:24

Никчемный спор опять. Меня тоже на Ваш Рефлекс не затащишь канатом.
Язык который поддерживает только один производитель (и пользователь) - мертворожденный язык. Экзотичная экзотика какой мало.
Самоудовлетворение мягко выражаясь :)

> Зачем разносить? Я категорически против экстремизма. :-)
> Больных надо лечить.
> Только теплое слово и забота.

Адрес этого сообщения    Ответить на это сообщение
 
 Re[13]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 09:53

Hello Гайдаш,

Thursday, May 24, 2007, 11:37:02 PM, you wrote:

ГДМ> Длинные простыни получаются, ну да ладно...

>> Ну не знаком я со спецификой АЭС, и не знаю, как работает перегрузочная
>> машина для АЭС.

ГДМ> Ну если для Вас это что-то значит, то описание матмодели, которая крутится
ГДМ> в контроллерах в реальном времени, - это полпачки бумаги формата А4.

Так и должно быть, если это сделано на МЭК-языках...

>> А я с АЭС не знаком. А про гидроэлектространцию упомянул, т.к. это как
>> и АЭС - энергетика, электростанция.

ГДМ> Специфика абсолютно другая, уверяю Вас.

Я не настаиваю.

>> А попутно замечу, что глупые слова, которые Вы мне пытаетесь приписать,
ГДМ> про
>> исключительность моих задач я никогда не произносил.

ГДМ> Почему тогда Вы не верите специалистам с солидным опытом работы, когда они
ГДМ> говорят, что на МЭК-языках успешно и красиво решаются достаточно сложные
ГДМ> задачи управления, а не только "примитив"?

Потому что разница познается в сравнении. Я сравнивал, насчет
специалистов не скажу.

>> То есть Вы сомневаетесь в квалификации исполнителей?
>> Уверяю Вас, зря. Это _очень_ квалифицированные люди.

ГДМ> Зачем они писали все на FBD?

Думаю, из-за унификации описания алгоримта. Это упрощает общее
описание системы. Известная вещь. Смешаноязыковое программирование.
От него падает надежность ПО.

>> ГДМ> Отсутствие соответствующей сертификации у Фаствела.
>>
>> Это какой пункт стандарта?

ГДМ> Требование, чтобы все элементы системы были сертифицированными.

Пункт?

>> возможно

ГДМ> Цена обусловлена высоким качеством и надежностью элементов системы.

Слова.

>> да все закрыто, даже какой процессор стоит - секрет.

ГДМ> А что, если неизвестно какой там процессор стоит, то система
ГДМ> неработоспособна? Мне вот абсолютно неинтересно, какой там стоит
ГДМ> процессор. Мне важно, чтобы обеспечивалось заявленное быстродействие и
ГДМ> функциональность (в широком смысле - включая надежность). А от того, какой
ГДМ> там процессор стоит, мне не жарко и не холодно - не надо делать фетиш из
ГДМ> железок и софта, это просто инструменты для достижения совсем других
ГДМ> целей.

А Вы подумайте, зачем это делается...

>> Да, примерно то же самое можно сказать и про других производителей,
>> поддерживающих МЭК 61131-3. Я об этом и говорю.

ГДМ> Вас не смущает, что есть масса PC-совместимых МЭК-контроллеров? Я вот,
ГДМ> например, считаю, что если подсесть на Рефлекс, топотом от него уйти
ГДМ> сложнее, чем от Сименса ;))

Ну, в принципе, Вы правы. Только вопрос тут будет не в технической
невозможности использовать МЭК-языки, а в нежелании пользоваться менее совершенным
инструментом.
Аналогия - электродрель и ручная дрель. После электродрели Вы же не
теряете способности пользоваться ручной дрелью? Так и с Рефлексом.
Впрочем, дело даже не в Рефлексе - это лишь один из возможных языков на
основе модели гиперпроцесса... Си-подобный, просто. А можно делать и
Паскале-подобный... ;-)

>> ГДМ> Safety-related part of control systems and/or their safety devices and
>> ГДМ> their components must be designed, constructed, selected, assembled and
>> ГДМ> combined in accordance with the relevant standards such that they can
>> ГДМ> withstand the expected influence
>>
>> Ну и? Должны быть.

ГДМ> Не "должны быть", а должны соответствовать стандартам.

Я же согласился. Это очевидно. Только это не подтверждает Ваши слова,
а почему не подтверждает - было пояснено в той части, которую
почему-то Вы убрали.

>> Нет. Пока я хочу увидеть пункт стандарта, запрещающий использовать
>> компоненты, не сертифицированные на требуемый SIL.

ГДМ> Уверяю Вас, IEC 61508 содержит требования, аналогичные приведенным :)

Пункт?

>> А потом, в случае чудесного обнаружения такого пункта, у меня в планах
>> поинтересоваться, где же Вы берете сертифицированные шурупы, болты,
ГДМ> кнопки,
>> провода, и прочую мелюзгу...

ГДМ> Очень остроумно, продолжайте нас веселить :)

У Вас раздвоение личности? Или неуютно от одиночества?

>> К сожалению, этой информации мало. Единственно можно сказать - процессор -
>> вполне.

ГДМ> Для определенных задач вполне, а для управления газоперекачивающим
ГДМ> агрегатом его недостаточно. Повторяю то, что Вы благоразумно опустили, -
ГДМ> на тот момент на рынке не было PC-based систем управления ГПА, которые бы
ГДМ> функционировали на одном процессорном модуле. Насколько я знаю, таких
ГДМ> серийных систем нет и сейчас, а то, что представляется на МВИ, построено
ГДМ> на базе минимум двух процессорных модулей (это без резервирования).

Без рассмотрения алгоритма - Ваши утверждения голословны.

>> А так, только на программистов можно грешить. Было бы интересно на алгоритм
>> посмотреть.

ГДМ> Такой же секрет, что и Ваши листы А3. В-основном, ничего сложного, но есть
ГДМ> тонкости - задача управления подачей топлива в камеру сгорания и задача
ГДМ> антипомпажного регулирования и защиты компрессора...

Дмитрий Михайлович, ну и в чем смысл эти вещи обсуждать? До нас уже
умные люди все придумали, и даже задачу сформулировали... ;-)

>> Имеется ввиду истинная статистика, разумеется. А отказы есть у всех.
>> Тут что-то скрывать глупо.

ГДМ> У нас есть своя статистика по Сименсу, основанная на 6-тилетнем опыте
ГДМ> внедрения и эксплуатации систем в количестве _сотен_ штук в год. Хорошая
ГДМ> статистика - подавляющее большинство отказов оборудования приходится на
ГДМ> этап ПНР и не связано с надежностью самого железа. Отказы в эксплуатации
ГДМ> единичны, причем часть из них также обсуловлена внешними причинами (пожар,
ГДМ> например).

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

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

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 09:57

Hello Гайдаш,

Thursday, May 24, 2007, 1:27:52 PM, you wrote:

>> еще несколько кликов мышкой (примерно 10-15 секунд), чтобы залить
ГДМ> изменения

ГДМ> В своей личной практике подгружал изменения в контроллер в процессе
ГДМ> запуска газотурбинного двигателя - под таким грузом ответственности это
ГДМ> делается за 3-5 секунд :))))) А 10-50 секунд нужны на то, чтобы найти
ГДМ> ошибку в программе и исправить ее :) А вот 20-30 минут - это чтобы пульс в
ГДМ> норму пришел после этого и помолиться :)

Отлаживать алгоритмы на реальном оборудовании критических производств
крайне нежелательно. Когда-нибудь не удастся найти ошибку за
приемлемое время.

В общем-то большое количество ошибок в программе - одна из
особенностей МЭК-языков.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: Re: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   25.05.07 10:00

Смеюсь уже 10 минут :) А я дурень думал что ошибки программеры делают :)))

> В общем-то большое количество ошибок в программе - одна из
> особенностей МЭК-языков.

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 10:00

Friday, May 25, 2007, 7:39:30 AM, you wrote:

В> Т.е. сертифицировать "железку" на основе МикроПиСи невозможно только потому,
В> что этого не делал Фаствел?
В> Было озвучено мнение, что оборудование с ядром ПиСи (в любом виде, MicroPC,
В> PC\104 и т.д.) ПРИНЦИПИАЛЬНО невозможно сертифицировать никому и никогда
В> только на том основании, что это оборудование на ПиСи. Хотелось бы услышать
В> аргументы в поддержку такого мнения.

Да это адепты ПЛК в полемическом запале сделали... Они просто не знают, что
большинство ПЛК это просто МикроПиСи, залитые эпоксидной смолой...
:-D

>> > Что мешает сертифицировать системы на Фаствеле под SILn?
>>
>> Отсутствие соответствующей сертификации у Фаствела.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[13]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   25.05.07 10:10

> ГДМ> Ну если для Вас это что-то значит, то описание матмодели, которая крутится
> ГДМ> в контроллерах в реальном времени, - это полпачки бумаги формата А4.
>
> Так и должно быть, если это сделано на МЭК-языках...

Еще раз медленно, по буквам - описание МАТМОДЕЛИ. Это вообще никакого отношения ни к каким языкам не имеет, это матаппарат (если конкретнее, то уравнения движения и пространственная геометрия).

> Потому что разница познается в сравнении. Я сравнивал, насчет
> специалистов не скажу.

Я работал с PC-based контроллерами, писал программы на C++. МЭК-языки ничуть не хуже, а в чем-то даже удобнее. И это если абстрагироваться от сервисных возможностей, которые на PC-based контроллерах на порядок хуже. А уж утверждение, что какие-то там "сложные" задачи на МЭК не реализовать и что МЭК только для "простых" вещей - это ПОЛНАЯ ЧУШЬ, заявляю это совершенно ответственно.

> Думаю, из-за унификации описания алгоримта. Это упрощает общее
> описание системы. Известная вещь. Смешаноязыковое программирование.
> От него падает надежность ПО

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

> ГДМ> Цена обусловлена высоким качеством и надежностью элементов системы.
>
> Слова.

Подтвержденные многолетним опытом внедрения и эксплуатации сотен систем на базе этого железа, а не выдуманными искусственными примерами и теоретизированием.

> У Вас раздвоение личности? Или неуютно от одиночества?

Я не один Вас читаю ;))

> ГДМ> Для определенных задач вполне, а для управления газоперекачивающим
> ГДМ> агрегатом его недостаточно. Повторяю то, что Вы благоразумно опустили, -
> ГДМ> на тот момент на рынке не было PC-based систем управления ГПА, которые бы
> ГДМ> функционировали на одном процессорном модуле. Насколько я знаю, таких
> ГДМ> серийных систем нет и сейчас, а то, что представляется на МВИ, построено
> ГДМ> на базе минимум двух процессорных модулей (это без резервирования).
>
> Без рассмотрения алгоритма - Ваши утверждения голословны.

Ваши утверждения не менее голословны - вопрос доверия. Вы почему-то мне не доверяете.

> Ну и здорово. Опубликуйте эту статистику, всем будет интересно. В
> частности, и Вашим заказчикам.

Заказчики в курсе.

> Кстати, и Вам будет интересно на себе испытать, каково публиковать информацию о
> своих проколах, даже если они сделаны на этапе ПНР.

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

И к чему мы пришли?

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[2]: Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   25.05.07 10:13

> Отлаживать алгоритмы на реальном оборудовании критических производств
> крайне нежелательно. Когда-нибудь не удастся найти ошибку за приемлемое время.

Также нежелательно прыгать с крыши 16-го этажа и есть мышьяк. К чему это вообще сказано? Есть теория, а есть ПРАКТИКА, в которой ВСЕМ приходится сталкиваться с подобными задачами - в кратчайшие сроки модифицировать программу и загрузить ее в контроллер без остановки техпроцесса. Продолжайте теоретизировать, но это уже даже не смешно.

> В общем-то большое количество ошибок в программе - одна из особенностей МЭК-языков.

Тоже не смешно. Я даже знаю язык, на котором невозможно сделать ошибку - это Рефлекс, я угадал?

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 10:08

Hello Oleg.B.Filichkin,

Friday, May 25, 2007, 11:33:45 AM, you wrote:

OBF> Тут написано-
OBF> ===========
OBF> Вы тут смешиваете два вопрос: а) вопрос языка, как средства описания,
OBF> и б) вопрос реализации языка в виде транслятора, среды разработки,
OBF> вспомогательных функций. То, что Вы описываете, - это компиляционная
OBF> модель реализации языка, плюс отсутствие продвинутых средств загрузки.
OBF> Собственно к языку это не имеет никакого отношения.
OBF> ================
OBF> Что-то совсем запуталси...
OBF> Об чем речь?
OBF> Об ПС вз ПЛС или о собственном языке?
OBF> Язык , не сомневаюсь, просто замечательный
OBF> Ну, и чего дальше-то?
OBF> Двадцать лет назад родная кафедра занималась разработкой испытательных
OBF> стендов ТРА ГТД.
OBF> Делалось, сдавалось, выключалось, закрывалось.
OBF> Встречаю однокурсников- чего делаешь? А то же самое, но не  на кафедре и с
OBF> ма-а-аленькой разницей - все это работает, и сильно востребовано.
OBF> К чему это?
OBF> А к тому, что от теории до ПРАКТИКИ - десятки лет, причем не только с точки
OBF> зрения программмирования, а КОМПЛЕКСНОГО РЕШЕНИЯ, вплоть до шурупов.

Совершенно верно.

OBF>  А на удочку "свободы программирования" не поймаете, плавали, знаем...
OBF> по крайней мере, в решениях для промышленности.
OBF> Потерялся "свободный программист" - и труба. Снесли систему полностью.
OBF> Вот, скажем, для супербыстродействующих систем, например, для распознавания
OBF> траектории снаряда - тут VME64 как минимум - и языки всяческие
OBF> Для бортовых малогабаритных или др. уникальных - PC-104 кубиком.
OBF> Для холодильников и светофоров - король PIC.
OBF> Ни о чем спор как был, так и остался...

В споре головы развиваются, новые мысли появляются и т.д. В этом смысл
дискуссий и обмена мнениями.. Ведь наша отрасль тоже развивается, на
нее влияет компьютерный мэйнстрим: Изернет, Винтел, ВайФай, КПК...
это тенденции, которые надо отслеживать.

А "свободных программистов" надо отстреливать, согласен..
--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[4]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 10:17

Не, Дмитрий, Вы неверно трактуете мои цели участия в дискусии.
Я понимаю, что текущая реализация Рефлекса сырая, и до его массового
внедрения в промышленность далеко. Ну, а может и не наступит такое
никогда - тоже допускаю. Может ST в сторону Рефлекса сдвинется,
например, в рамках CoDeSys. Или еще что случится.

Поэтому я и не толкаю тут лозунгов - "Все на Рефлекс". Рано еще.
Но обсуждать то Рефлекс мне надо, и оппонентам тоже полезно...
ведь участие в таких обсуждениях, знакомство с Рефлексом позволяет
по новому взглянуть на тот же МЭК, улучшить его понимание, да и новые
техники-паттерны программирования на МЭК освоить.

Friday, May 25, 2007, 12:24:46 PM, you wrote:

drr> Никчемный спор опять. Меня тоже на Ваш Рефлекс не затащишь канатом.
drr> Язык который поддерживает только один производитель (и
drr> пользователь) - мертворожденный язык. Экзотичная экзотика какой мало.
drr> Самоудовлетворение мягко выражаясь :)

>> Зачем разносить? Я категорически против экстремизма. :-)
>> Больных надо лечить.
>> Только теплое слово и забота.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[4]: Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 10:21

Да, Вы правы... если рассматривать предложения вне контекста бывает
очень смешно. Разумеется, ошибаются программисты. Более корректная фраза:

В общем-то большое количество ошибок в программе - одна особенностей
использования МЭК-языков.


Friday, May 25, 2007, 1:00:27 PM, you wrote:

drr> Смеюсь уже 10 минут :) А я дурень думал что ошибки программеры делают :)))

>> В общем-то большое количество ошибок в программе - одна из
>> особенностей МЭК-языков.


--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[4]: Re: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   25.05.07 11:00

Да тут хоть выдирай, хоть не выдирай контекст...как может ПО делать ошибки? При компиляции?
А при чем тогда МЭК? Не понимаю Вашу мысль. Объясните пожалуйста.

С уважением,
Милосердов Дмитрий

> Да, Вы правы... если рассматривать предложения вне контекста
> бывает очень смешно. Разумеется, ошибаются программисты.
> Более корректная фраза:

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   25.05.07 11:36

> Уважаемый Владимир,
> позвольте напомнить Вам, что многократное повторение одного и того же
> спорного утверждения не делает это утверждение истинным.
> Если мне не изменяет память, два года назад Вы уже писали в Конференции
> про "недостатки и ограничения МЭК 61131-3". Но тогда оказалось, что у
> Вас нет ни одного примера ПРАКТИЧЕСКОЙ задачи управления, которая не
> решается на языках МЭК 61131 из-за их "ограниченности". Если у Вас за
> два года появился хотя бы один такой пример (из вашей ПРАКТИКИ, а не
> ТЕОРИИ), пожалуйста, расскажите.
> С уважением,
> Сергей Щекин
> GUTOR Electronic ltd.
>

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

Владимир, если что, поправьте:)

С Уважением
Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   25.05.07 11:59

> > Про недостатки как стандарта, так и самих языков можно почитать тут
> А вот не поверите - читал :) Разбирать по полочкам никакого желания нет,
> но со многими "тезисами" я просто не согласен, т.к. имею опыт, их
> опровергающий.

По существу-то может кто-нибудь возразить? Или так и будет: "не согласен, но молчу":)

Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[13]: PC-совместимый контроллер vs PLC.
Автор: aysanov-r 
Дата:   25.05.07 11:09

Добрый день, всем.

К участникам данной дискуссии.

Уважаемые коллеги, может вы выйдете в коридор и там обсудите эту тему.
C  уважением Руслан Баширович.
ФПК "Формула безопасности"

Гайдаш Д . М .
Subject: Re[13]: [asutp] PC-совместимый контроллер vs PLC.

Hello Гайдаш,

Thursday, May 24, 2007, 11:37:02 PM, you wrote:

ГДМ> Длинные простыни получаются, ну да ладно...

>> Ну не знаком я со спецификой АЭС, и не знаю, как работает перегрузочная
>> машина для АЭС.

ГДМ> Ну если для Вас это что-то значит, то описание матмодели, которая
крутится
ГДМ> в контроллерах в реальном времени, - это полпачки бумаги формата А4.

Так и должно быть, если это сделано на МЭК-языках...

>> А я с АЭС не знаком. А про гидроэлектространцию упомянул, т.к. это как
>> и АЭС - энергетика, электростанция.

ГДМ> Специфика абсолютно другая, уверяю Вас.

Я не настаиваю.

>> А попутно замечу, что глупые слова, которые Вы мне пытаетесь приписать,
ГДМ> про
>> исключительность моих задач я никогда не произносил.

ГДМ> Почему тогда Вы не верите специалистам с солидным опытом работы, когда
они
ГДМ> говорят, что на МЭК-языках успешно и красиво решаются достаточно
сложные
ГДМ> задачи управления, а не только "примитив"?

Потому что разница познается в сравнении. Я сравнивал, насчет
специалистов не скажу.

>> То есть Вы сомневаетесь в квалификации исполнителей?
>> Уверяю Вас, зря. Это _очень_ квалифицированные люди.

ГДМ> Зачем они писали все на FBD?

Думаю, из-за унификации описания алгоримта. Это упрощает общее
описание системы. Известная вещь. Смешаноязыковое программирование.
От него падает надежность ПО.

>> ГДМ> Отсутствие соответствующей сертификации у Фаствела.
>>
>> Это какой пункт стандарта?

ГДМ> Требование, чтобы все элементы системы были сертифицированными.

Пункт?

>> возможно

ГДМ> Цена обусловлена высоким качеством и надежностью элементов системы.

Слова.

>> да все закрыто, даже какой процессор стоит - секрет.

ГДМ> А что, если неизвестно какой там процессор стоит, то система
ГДМ> неработоспособна? Мне вот абсолютно неинтересно, какой там стоит
ГДМ> процессор. Мне важно, чтобы обеспечивалось заявленное быстродействие и
ГДМ> функциональность (в широком смысле - включая надежность). А от того,
какой
ГДМ> там процессор стоит, мне не жарко и не холодно - не надо делать фетиш
из
ГДМ> железок и софта, это просто инструменты для достижения совсем других
ГДМ> целей.

А Вы подумайте, зачем это делается...

>> Да, примерно то же самое можно сказать и про других производителей,
>> поддерживающих МЭК 61131-3. Я об этом и говорю.

ГДМ> Вас не смущает, что есть масса PC-совместимых МЭК-контроллеров? Я вот,
ГДМ> например, считаю, что если подсесть на Рефлекс, топотом от него уйти
ГДМ> сложнее, чем от Сименса ;))

Ну, в принципе, Вы правы. Только вопрос тут будет не в технической
невозможности использовать МЭК-языки, а в нежелании пользоваться менее
совершенным
инструментом.
Аналогия - электродрель и ручная дрель. После электродрели Вы же не
теряете способности пользоваться ручной дрелью? Так и с Рефлексом.
Впрочем, дело даже не в Рефлексе - это лишь один из возможных языков на
основе модели гиперпроцесса... Си-подобный, просто. А можно делать и
Паскале-подобный... ;-)

>> ГДМ> Safety-related part of control systems and/or their safety devices
and
>> ГДМ> their components must be designed, constructed, selected, assembled
and
>> ГДМ> combined in accordance with the relevant standards such that they
can
>> ГДМ> withstand the expected influence
>>
>> Ну и? Должны быть.

ГДМ> Не "должны быть", а должны соответствовать стандартам.

Я же согласился. Это очевидно. Только это не подтверждает Ваши слова,
а почему не подтверждает - было пояснено в той части, которую
почему-то Вы убрали.

>> Нет. Пока я хочу увидеть пункт стандарта, запрещающий использовать
>> компоненты, не сертифицированные на требуемый SIL.

ГДМ> Уверяю Вас, IEC 61508 содержит требования, аналогичные приведенным :)

Пункт?

>> А потом, в случае чудесного обнаружения такого пункта, у меня в планах
>> поинтересоваться, где же Вы берете сертифицированные шурупы, болты,
ГДМ> кнопки,
>> провода, и прочую мелюзгу...

ГДМ> Очень остроумно, продолжайте нас веселить :)

У Вас раздвоение личности? Или неуютно от одиночества?

>> К сожалению, этой информации мало. Единственно можно сказать -
процессор -
>> вполне.

ГДМ> Для определенных задач вполне, а для управления газоперекачивающим
ГДМ> агрегатом его недостаточно. Повторяю то, что Вы благоразумно
опустили, -
ГДМ> на тот момент на рынке не было PC-based систем управления ГПА, которые
бы
ГДМ> функционировали на одном процессорном модуле. Насколько я знаю, таких
ГДМ> серийных систем нет и сейчас, а то, что представляется на МВИ,
построено
ГДМ> на базе минимум двух процессорных модулей (это без резервирования).

Без рассмотрения алгоритма - Ваши утверждения голословны.

>> А так, только на программистов можно грешить. Было бы интересно на
алгоритм
>> посмотреть.

ГДМ> Такой же секрет, что и Ваши листы А3. В-основном, ничего сложного, но
есть
ГДМ> тонкости - задача управления подачей топлива в камеру сгорания и задача
ГДМ> антипомпажного регулирования и защиты компрессора.

Дмитрий Михайлович, ну и в чем смысл эти вещи обсуждать? До нас уже
умные люди все придумали, и даже задачу сформулировали... ;-)

>> Имеется ввиду истинная статистика, разумеется. А отказы есть у всех.
>> Тут что-то скрывать глупо.

ГДМ> У нас есть своя статистика по Сименсу, основанная на 6-тилетнем опыте
ГДМ> внедрения и эксплуатации систем в количестве _сотен_ штук в год.
Хорошая
ГДМ> статистика - подавляющее большинство отказов оборудования приходится на
ГДМ> этап ПНР и не связано с надежностью самого железа. Отказы в
эксплуатации
ГДМ> единичны, причем часть из них также обсуловлена внешними причинами
(пожар,
ГДМ> например).

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

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

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 19:28

Hello Kuzmin,

Friday, May 25, 2007, 2:36:26 PM, you wrote:

KY> Я так понял, в статье утверждается, порочность самого подхода,
KY> когда разные задачи, решаются совершенно разными языками. И
KY> разработчик на любом этапе может столкнуться с проблемой
KY> реализации того или иного алгоритма на уже выбранном
KY> средстве(языке),т.е с отсутствием универсальности. Поэтому при
KY> таком подходе требуется большая начальная проработка решения и
KY> отстутствие вариаций на следующих этапах и новых "хотелок" при
KY> модернизации, т.е не учитывается своя специфика, свои реалии
KY> разработки, а навязываются западные подходы, устанавливающие
KY> другие правила мышления, выгодные отнюдь не разработчикам.

Да, Юрий, примерно так.

В принципе - у некоторых языков МЭК есть хорошее свойство - легкая
изучаемость - это графические языки LD и FBD. Объяснил что такое реле,
и вперед... программируй.

Но тут же есть и подводный камень: много в терминах реле не
напрограммируешь.

А насчет западные подходы или не западные, я бы так вопрос не ставил.
У англичанина мозг также устроен как и у русского, и навыки примерно
одинаковые (ну, конечно, не считая того, что англичанин лучше знает
английский, и совершенно ни бум-бум в русском... ;-)

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[6]: Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   25.05.07 19:20

При чем тут ПО? Я про языки говорил.

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

Языки МЭК здесь при том, что они по сути очень убогие.
LD - метафора реле, отсутствие структурирующих свойств,
FBD - метафора микросхем, data-flow язык, остутствие средств изменения
      потока управления.
SFC - сети Петри со всеми их проблемами: метки, параллелизм, нет
      абстрагирования-структурирования
ST - "псевдо-паскаль", процедурный язык, отсутствует параллелизм,
IL - ассемблероподобность, низкоуровневость.

До кучи - убогая идентификационная система и т.д.

В общем про эти вещи можно почитать в статье "Программирование ПЛК:
языки МЭК 61131-3 и возможные альтернативы", и в статье  "Графика или текст:какой язык нужен программисту?"

Все есть в свободном доступе:
http://reflex-language.narod.ru/articles/articles.htm
http://www.osp.ru/os/2004/01/183824/


Friday, May 25, 2007, 1:43:11 PM, you wrote:

drr> Да тут хоть выдирай, хоть не выдирай контекст...как может ПО делать ошибки? При компиляции?
drr> А при чем тогда МЭК? Не понимаю Вашу мысль. Объясните пожалуйста.

drr> С уважением,
drr> Милосердов Дмитрий

>> Да, Вы правы... если рассматривать предложения вне контекста
>> бывает очень смешно. Разумеется, ошибаются программисты.
>> Более корректная фраза:

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   25.05.07 20:41

Всегда есть рубеж, укоторого надо остановиться и осмыслить дальнейший путь.Так и с языками МЭК. У нас с одним контроллером возникли непредвиденные проблемы. Вычислительная мощность его вполне достаточна для быстрого управления, но использование стандартных блоков, написанных на языках МЭК (напр. блок управления приводом задвижки) быстро "съедает" память контроллера. И вот уже не хватает 4Мбайт и надо покупать контроллер с 16 Мбайт. А это реальные (и не малые) деньги! Вспоминая какие программы я писал на БЭСМ-6 с 32 Кслов (~ 192 Кбайт) я начинаю серьезно подозревать, что реализация языков МЭК (по крайней мере на этом контроллере, в его среде) далека от оптимальности. Конечно программисту очень комфортно практически "под копирку" шлепать на BFD программные блоки, но платить за дополнительное железо и ПО приходится моей конторе.
Мне представляется, что использование языков (включая и Ассемблер) программирования типа С, Фортран во многих приложениях даст существенный экономический эффект.

Деловое предложение всем желающим: готов по договору предложить работу по программированию алгоритмов управления для контроллера на Ассемблере, С или других алгоритмических языках с целью повышения оптимальности загрузки ресурсов контроллера.
Пишите на мой e-mail.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   26.05.07 01:06

Нельзя поподробнее про задачи, в которых не хватает 4 Мбайт памяти? :) Просто программное обеспечение системы на сотню аналоговых входов, 2-3 сотни дискретных входов и столько же выходов, алгоритм которой разрисовывается на 70-120 листов А4,  прекрасно умещается в существенно меньшее количество памяти с использованием МЭК-языков. Один тонкий момент - стандартные блоки по минимуму, никаких SFC и FBD, только SCL (он же ST).

Побольше конкретики про проект (чтобы оценить загрузку контроллера и объем задачи в целом):
Количество исходников: 91 файл
Размер исходников: 1 535 854 байт
Общее число дискретных тегов: ~4000
Общее число аналоговых тегов: ~800
Число внешних тегов: 2983
Число алармов: 2152
Циклы обработки информации: от 0.2 до 1000 мс (основные - 20 и 200 мс)
Число блоков по типам:
- OB: 14
- DB: 165
- FB: 33
- FC: 81
- UDT: 15
- SFB: 2
- SFC: 2

А теперь главное:
Size in load memory: 511 416 bytes
Size in work memory:
- Code: 195 850 bytes
- Data: 238 016 bytes
- Total: 433 866 bytes

Т.е. все это добро, написанное исключительно на SCL (ST), умещается в 512 Кбайт памяти.

Давайте теперь все дружно поплюемся на МЭК-языки и МЭК-контроллеры :) Предлагаю начать г-ну Зюбину - можно привести аналогичные характеристики какого-нибудь типового проекта (я взял банальный серийный проект, которые мы клепаем сотнями в год).

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   26.05.07 12:06

Блоки управления задвижек состоят из чистой дискретки:
- DI ->
1. полностью открыто;
2. полностью закрыто;
3. ход на открытие;
4. ход на закрытие;
5. обрыв питания.
- DO ->
1. открыть;
2. закрыть.
Обычно нагрузка на один контроллер:  1200 -1300 сигналов.
Именно эти блоки забивают память.
Может кто-нибудь подскажет где можно похожий взять агоритм для сравнения?

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   26.05.07 12:31

Предлагаю нарассмотрение блок управления краном, который имеет сл. интерфейс (копирую из исходника):

VAR_INPUT
  onCom      : BOOL; // команда открытия от алгоритма
  offCom     : BOOL; // команда закрытия от алгоритма
  onSig      : BOOL; // сигнал (конечник) открытия крана
  offSig     : BOOL; // сигнал (конечник) закрытия крана
  onBtn      : BOOL; // кнопка открытия крана
  offBtn     : BOOL; // кнопка закрытия крана
  DU         : BOOL; // дистанционное управление
  PermitON   : BOOL; // Разрешение на открытие
  PermitOF   : BOOL; // Разрешение на закрытие
  reset      : BOOL; // сброс блокировки поджима
  onSigBrk   : BOOL; // неисправен сигнал открытого положения
  offSigBrk  : BOOL; // неисправен сигнал закрытого положения
  onComBrk   : BOOL; // неисправна команда на открытие
  offComBrk  : BOOL; // неисправна команда на закрытие
  alertTime  : REAL; // время перестановки, при превышении которого выдаетсЯ предупреждение
  offOutTime : REAL; // время перестановки, при превышении которого снимаетсЯ выходнаЯ команда
  onComDelay : REAL; // время дожима на открытие
  offComDelay: REAL; // время дожима на закрытие
  cycle      : REAL; // цикл вызова (с)
END_VAR
VAR_OUTPUT
  onOut      : BOOL; // выход на открытие крана
  offOut     : BOOL; // выход на закрытие крана
  notOn      : BOOL; // кран не открыт
  notOff     : BOOL; // кран не закрыт
  notGood    : BOOL; // обощенная неисправность ИМ
END_VAR

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

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   26.05.07 16:13

Маленькое добавление :) 912 байт - это FB, а экземплярный DB занимает 46 байт :) Т.е. под экземплярный DB для FB на 1000 кранов потребуется всего 46 * 1000 байт.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Виктор 
Дата:   28.05.07 04:42

Где конкретно было озвучено такое мнение???
>
> С уважением,
> Гайдаш Дмитрий Михайлович

"...как на базе PC-совместимого контроллера (ну, скажем, Octagon/Fastwell
или
что-нибудь подобное) сделать систему, которую можно будет сертифицировать
по SIL3?"

"> И почему на Fastwel-е требования этого SIL не обеспечить
Потому что никто никогда это не сертифицирует."

Есть предложение свернуть "религиозную войну", уж сколько раз было.
Какой смысл сравнивать сладкое с жестким? МЭК, SIL и PC-PLC - три разные
вещи мало связанные. И на PC можно замечательно и просто использовать МЭК, а
PLC при желании можно программировать на С... Да и чем тот-же Simatic
отличается от PC? Конструктивным исполнением и тем, что вместо DOS/Win/QNX
использует собственную ОС. А что мешать на PC использовать такую? Ничего,
кроме отсутствия желания/потребности/экономической целесообразности (нужное
подчеркнуть). А завтра что-то изменится и такая потребность/целесообразность
появится... Но сейчас меня обвинят в беспочвенном теоретизировании ;)

Виктор Прилипко,
ОАО "ИНЭУМ"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Alexander Lokotkov 
Дата:   28.05.07 12:35

Предлагаю нарассмотрение блок управления краном, который имеет сл.
интерфейс (копирую из исходника):

VAR_INPUT
onCom : BOOL; // команда открытия от алгоритма
offCom : BOOL; // команда закрытия от алгоритма
...
END_VAR

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

С уважением,
Гайдаш Дмитрий Михайлович
//////////////////////////////////////////////////////////////////////

Здравствуйте, Дмитрий Михайлович,

Не могли бы Вы разместить и собственно реализацию алгоритма? Мне
просто интересно, как Вы делаете анализ пар переменных вроде
onCom/offCom, которые по логике представляют одну переменную
(открыть/закрыть/ничего не делать). Там ведь вроде бы нужно
запрещенные сочетания отслеживать. Подозреваю, что если бы Вы сделали
что-то вроде:

TYPE ON_OFF_CONTROL : (NO_COMMAND, CMD_ON, CMD_OFF);
END_TYPE

и объединили пары переменных так:
VAR_INPUT
(*
БЫЛО ТАК:
onCom : BOOL; // команда открытия от алгоритма
offCom : BOOL; // команда закрытия от алгоритма
СТАЛО ТАК:
*)
Com : ON_OFF_CONTROL := NO_COMMAND;
...
END_VAR

количество кода, вероятно, несколько подсократилось бы. Ну, и он
хорошо бы лег в автоматный формализм, реализуемый в ST на CASE OF.

Кроме того, каждый BOOL в памяти ПЛК, как правило, занимает минимум
байт. Так что, если среда разработки умеет размещать перечислимые
типы пользователя в байт, то можно сократить по 8 байт памяти на
каждый блок.

С уважением,
Локотков Александр

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   28.05.07 12:47

Alexander Lokotkov писал(а):

> Не могли бы Вы разместить и собственно реализацию алгоритма?

Нет, этого я делать не буду :)

> Подозреваю, что если бы Вы сделали что-то вроде:
> ...
> количество кода, вероятно, несколько подсократилось бы.

Это вряд ли - см. ниже.

> Кроме того, каждый BOOL в памяти ПЛК, как правило, занимает минимум
> байт.

Компилятор (в данном случае SCL) осуществляет выравнивание, при этом один BOOL занимает 2 байта, но если подряд идет 16 BOOL, то они тоже занимают 2 байта, т.е. переменная UDT из 3-х BOOL будет занимать 2 байта, а вот две таких переменных будут занимать уже 4 байта, так что оптимально просто использовать много однотипных переменных подряд (в приведенном примере это 14 переменных BOOL, которые занимают все те же 2 байта).

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   28.05.07 12:50

Виктор писал(а):

> Где конкретно было озвучено такое мнение???
> ...
> Потому что никто никогда это не сертифицирует

Интернет - плохое средство общения. Имелась в виду не принципиальная невозможность сертификации PC-совместимых контроллеров, а невозможность сертификации системы на базе Fastwell в силу отсутствия такой сертификации у Fastwell'а. Требования стандарта однозначно гласят, что все компоненты системы должны быть сертифицированы (но это далеко не все, что требуется).

> Есть предложение свернуть "религиозную войну", уж сколько раз было.

Было :) И автор так и не появился в ветке - видимо, просто провокация или испугался :))) Но почему бы и не побеседовать? Глядишь, кто-то для себя что-то новое откроет...

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re[5]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   28.05.07 17:40

Hello Гайдаш,

Friday, May 25, 2007, 1:13:45 PM, you wrote:

>> Отлаживать алгоритмы на реальном оборудовании критических производств
>> крайне нежелательно. Когда-нибудь не удастся найти ошибку за приемлемое
ГДМ> время.

ГДМ> Также нежелательно прыгать с крыши 16-го этажа и есть мышьяк. К чему это
ГДМ> вообще сказано? Есть теория, а есть ПРАКТИКА, в которой ВСЕМ приходится
ГДМ> сталкиваться с подобными задачами - в кратчайшие сроки модифицировать
ГДМ> программу и загрузить ее в контроллер без остановки техпроцесса.
ГДМ> Продолжайте теоретизировать, но это уже даже не смешно.

Дело не в смехе. Просто есть такая штука как верификация.. Многие ее
практикуют.

>> В общем-то большое количество ошибок в программе - одна из особенностей
ГДМ> МЭК-языков.

ГДМ> Тоже не смешно. Я даже знаю язык, на котором невозможно сделать ошибку -
ГДМ> это Рефлекс, я угадал?

Дмитрий Михайлович, не угадали. Ошибки можно совершать везде, но
статистика будет разная, и характер ошибок тоже.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[5]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   29.05.07 08:59

> Просто есть такая штука как верификация.. Многие ее практикуют

И с верификацией знаком, и с валидацией... Только Вы опять теоретизируете, похоже, а как это в жизни работает не знаете.

А вот Вам еще информация к размышлению:
http://iprog.pp.ru/forum/read.php?f=1&i=43594&t=43228#reply_43594
http://iprog.pp.ru/forum/read.php?f=1&i=43598&t=43228#reply_43598
http://iprog.pp.ru/forum/read.php?f=1&i=43599&t=43228#reply_43599

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   29.05.07 09:41

Hello Гайдаш,

Friday, May 25, 2007, 1:10:54 PM, you wrote:

>> ГДМ> Ну если для Вас это что-то значит, то описание матмодели, которая
ГДМ> крутится
>> ГДМ> в контроллерах в реальном времени, - это полпачки бумаги формата
ГДМ> А4.
>>
>> Так и должно быть, если это сделано на МЭК-языках...

ГДМ> Еще раз медленно, по буквам - описание МАТМОДЕЛИ. Это вообще никакого
ГДМ> отношения ни к каким языкам не имеет, это матаппарат (если конкретнее, то
ГДМ> уравнения движения и пространственная геометрия).

Дмитрий Михайлович!

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

Во-вторых, ну не верю я в математическую формулу на "полпачки формата
А4". Не бывает таких.

>> Потому что разница познается в сравнении. Я сравнивал, насчет
>> специалистов не скажу.

ГДМ> Я работал с PC-based контроллерами, писал программы на C++. МЭК-языки
ГДМ> ничуть не хуже, а в чем-то даже удобнее. И это если абстрагироваться от
ГДМ> сервисных возможностей, которые на PC-based контроллерах на порядок хуже.
ГДМ> А уж утверждение, что какие-то там "сложные" задачи на МЭК не реализовать
ГДМ> и что МЭК только для "простых" вещей - это ПОЛНАЯ ЧУШЬ, заявляю это
ГДМ> совершенно ответственно.

А я и не спорю, что в чем-то языки-МЭК удобнее, чем Си++. Даже могу
сказать, в чем. И уже написано про это.

>> Думаю, из-за унификации описания алгоримта. Это упрощает общее
>> описание системы. Известная вещь. Смешаноязыковое программирование.
>> От него падает надежность ПО

ГДМ> Зависит от того, как именно смешивать. В случае с МЭК-языками они были
ГДМ> специально спроектированы так, чтобы их смешивали, и никакая надежность
ГДМ> ничуть не страдает, если следовать стандарту.

Вы просто не в курсе истории создания МЭК-языков. ;-)

>> ГДМ> Цена обусловлена высоким качеством и надежностью элементов системы.
>>
>> Слова.

ГДМ> Подтвержденные многолетним опытом внедрения и эксплуатации сотен систем на
ГДМ> базе этого железа, а не выдуманными искусственными примерами и
ГДМ> теоретизированием.

Все познается в сравнении. Где статистика?

>> У Вас раздвоение личности? Или неуютно от одиночества?

ГДМ> Я не один Вас читаю ;))

И пишете тоже коллективно? Прошу прощения, даже не приходило в голову.

>> ГДМ> Для определенных задач вполне, а для управления газоперекачивающим
>> ГДМ> агрегатом его недостаточно. Повторяю то, что Вы благоразумно опустили, -
>> ГДМ> на тот момент на рынке не было PC-based систем управления ГПА, которые бы
>> ГДМ> функционировали на одном процессорном модуле. Насколько я знаю, таких
>> ГДМ> серийных систем нет и сейчас, а то, что представляется на МВИ, построено
>> ГДМ> на базе минимум двух процессорных модулей (это без резервирования).
>>
>> Без рассмотрения алгоритма - Ваши утверждения голословны.

ГДМ> Ваши утверждения не менее голословны - вопрос доверия. Вы почему-то мне не
ГДМ> доверяете.

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

>> Ну и здорово. Опубликуйте эту статистику, всем будет интересно. В
>> частности, и Вашим заказчикам.

ГДМ> Заказчики в курсе.

У Вас один заказчик, или статистика отказов распространяется только
среди Ваших заказчиков?

>> Кстати, и Вам будет интересно на себе испытать, каково публиковать информацию о
>> своих проколах, даже если они сделаны на этапе ПНР.

ГДМ> Я за эти проколы не один раз отдувался на совещаниях у заказчика, так что
ГДМ> мне эти ощущения знакомы.

ГДМ> И к чему мы пришли?

Мы пока топчемся на месте.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   29.05.07 11:00

> А насчет западные подходы или не западные, я бы так вопрос не ставил.
> У англичанина мозг также устроен как и у русского, и навыки примерно
> одинаковые (ну, конечно, не считая того, что англичанин лучше знает
> английский, и совершенно ни бум-бум в русском... ;-)

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

С Уважением
Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   29.05.07 11:17

Hello Гайдаш,

Saturday, May 26, 2007, 4:06:58 AM, you wrote:

ГДМ> Нельзя поподробнее про задачи, в которых не хватает 4 Мбайт памяти? :)
ГДМ> Просто программное обеспечение системы на сотню аналоговых входов, 2-3
ГДМ> сотни дискретных входов и столько же выходов, алгоритм которой
ГДМ> разрисовывается на 70-120 листов А4,  прекрасно умещается в существенно
ГДМ> меньшее количество памяти с использованием МЭК-языков. Один тонкий момент
ГДМ> - стандартные блоки по минимуму, никаких SFC и FBD, только SCL (он же ST).

ГДМ> Побольше конкретики про проект (чтобы оценить загрузку контроллера и объем
ГДМ> задачи в целом):
ГДМ> Количество исходников: 91 файл
ГДМ> Размер исходников: 1 535 854 байт
ГДМ> Общее число дискретных тегов: ~4000
ГДМ> Общее число аналоговых тегов: ~800
ГДМ> Число внешних тегов: 2983
ГДМ> Число алармов: 2152
ГДМ> Циклы обработки информации: от 0.2 до 1000 мс (основные - 20 и 200 мс)
ГДМ> Число блоков по типам:
ГДМ> - OB: 14
ГДМ> - DB: 165
ГДМ> - FB: 33
ГДМ> - FC: 81
ГДМ> - UDT: 15
ГДМ> - SFB: 2
ГДМ> - SFC: 2

ГДМ> А теперь главное:
ГДМ> Size in load memory: 511 416 bytes
ГДМ> Size in work memory:
ГДМ> - Code: 195 850 bytes
ГДМ> - Data: 238 016 bytes
ГДМ> - Total: 433 866 bytes

ГДМ> Т.е. все это добро, написанное исключительно на SCL (ST), умещается в 512
ГДМ> Кбайт памяти.

ГДМ> Давайте теперь все дружно поплюемся на МЭК-языки и МЭК-контроллеры :)
ГДМ> Предлагаю начать г-ну Зюбину - можно привести аналогичные характеристики
ГДМ> какого-нибудь типового проекта (я взял банальный серийный проект, которые
ГДМ> мы клепаем сотнями в год).

1535252 байта исходников,
451528 байтов исполняемого кода
8,2 мс - максимальное время цикла
800+ параллельных процессов
100 мс - рабочий цикл
это полноценная система управление, отсечные и запорно-регулирующие клапаны,
двухкомпонентная система вакуумных агрегатов (в составе каждого
агрегата - форвакуумный насос и ДВН), 4-х координатное движение
(+джог-опция, т.е. 6 двигателей с безударным переключением,
интерполяция), противоаварийная защита по критическим параметрам с
упреждением, нагреватели, выносные лазерные датчики уровня расплава,
бихроматические пирометры, система технического зрения, всякая шушера
типа датчиков давления (нескольких типов с перекрывающимся
диапазоном), расхода газа... позиционные манометры, релепротока,
термодатчики и т.д. Автоматический и ручной режим, 30 технологических
макроопераций.

Теги никто не считает. Команд и сообщений предупредительных, аварийных и пр.
заведомо более - 3000 (только начальных типовых кодов сообщений около
трех тысяч, некоторые сопровождаются параметрами с указанием устройства,
некоторые действуют в обе стороны).

Мы такие проекты не клепаем, мы их разрабатываем с нуля. Ну, а
разработанные - тиражируем.

По сигналам, дискретных порядка 80, аналоговых тоже около сотни, хотя
вопрос это непростой, например, в одной телевизионной камере аналоговых
сигналов около _двух миллионов_.

Понимаете, на что я намекаю? ;-)

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[9]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   29.05.07 11:29

Hello Eugeen,

Friday, May 25, 2007, 11:41:13 PM, you wrote:

E> Деловое предложение всем желающим: готов по договору предложить работу по
E> программированию алгоритмов управления для контроллера на Ассемблере, С
E> или других алгоритмических языках с целью повышения оптимальности загрузки
E> ресурсов контроллера.
E> Пишите на мой e-mail.

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

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   29.05.07 11:41

Hello Гайдаш,

Monday, May 28, 2007, 3:50:30 PM, you wrote:

ГДМ> Виктор писал(а):

>> Где конкретно было озвучено такое мнение???
>> ...
>> Потому что никто никогда это не сертифицирует

ГДМ> Интернет - плохое средство общения. Имелась в виду не принципиальная
ГДМ> невозможность сертификации PC-совместимых контроллеров, а невозможность
ГДМ> сертификации системы на базе Fastwell в силу отсутствия такой сертификации
ГДМ> у Fastwell'а. Требования стандарта однозначно гласят, что все компоненты
ГДМ> системы должны быть сертифицированы (но это далеко не все, что требуется).

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

>> Есть предложение свернуть "религиозную войну", уж сколько раз было.

ГДМ> Было :) И автор так и не появился в ветке - видимо, просто провокация или
ГДМ> испугался :))) Но почему бы и не побеседовать? Глядишь, кто-то для себя
ГДМ> что-то новое откроет...

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Владимир Павлович 
Дата:   29.05.07 12:12

> Есть предложение свернуть "религиозную войну", уж сколько раз было...
Нет, не стоит... тема интересная, и в споре родится истина...

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   29.05.07 12:30

> Мы такие проекты не клепаем, мы их разрабатываем с нуля. Ну, а
> разработанные - тиражируем

А теперь, ВНИМАНИЕ, вопрос :)) Сколько времени (в человеко-днях) занимает разработка такого проекта? ;)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   29.05.07 12:38

Да, Юрий, Вы очень интересную и, на мой взгляд, разумную мысль
высказали. Язык заставляет мозг работать в определенном ключе, искать
именно ту форму решения задачи, которая более компактно выражается на
используемом языке.

Сложность проектирования сильно зависит от сложности решаемой задачи и
ограничений, которые заданы условиями задачи. Простая задача, скажем,
управление двумя клапанами, вряд ли вызовет очобые сложности при
решении даже на ассемблере, или в машинных кодах. 100 однородных
клапанов - тоже. Или миллион. Сложность не возрастает. А вот если два
типа клапанов, появляется, или другие устройства, то сложность растет,
особенно если устройства эти взаимосвязаны. Что-то типа, нельзя включать
нагреватель, когда нет воды в системе охлаждения... или, скажем,
включать нагреватель можно только после одной минуты после подачи
воды. Условий может быть много. И вот тут уже начинаются проблемы.

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

Tuesday, May 29, 2007, 2:00:09 PM, you wrote:

>> А насчет западные подходы или не западные, я бы так вопрос не ставил.
>> У англичанина мозг также устроен как и у русского, и навыки примерно
>> одинаковые (ну, конечно, не считая того, что англичанин лучше знает
>> английский, и совершенно ни бум-бум в русском... ;-)

KY> Владимир, я писал про то, что устанавливаются правила мышления, а
KY> не про само мышление.  Разве перечисленные Вами мифилогеммы в
KY> статье, не следуют из ограниченности возможностей языков МЭК, а
KY> если быть более точным из принятого подхода?
KY> Ведь, для того чтобы не сесть в лужу на последующих этапах проекта
KY> необходима кропотливая начальная проработка проекта и
KY> соответственно вряд ли потом будут допускаться изменения в нем. А
KY> это и есть регламентация мышления и далее отсутствие многоязыковой
KY> поддержки и привязка к кросс-платформе, т.е разработчик ограничен
KY> в выборе. Сама по себе регламентация не имеет какой-либо окраски, но
KY> ту которую Вы привели, вынуждает разработчика вместо решения
KY> задачи, стремиться покупать ответы или отказываться от их решения.
KY>
KY> Может этот смысл более скрыт в МЭК, но по-моему, он имеет место.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   29.05.07 14:17

Насчет Сименса: если думаете что мы его применяем - считайте обидели!
Речь идет о ABB AC 800F под FREELANCE 800F. Поддерживаются все языки МЭК-1131.
Technical Data
CPU - Intel 80960HT25/75 32-bit RISC SuperScalar processor up to 150 MIPS
RAM4 MB static read/write memory
Processing time for 1000 instructions< 1.0 ms for binary and 16 bit arithmetic
instructions
< 2 ms for fixed point arithmetic instructions
< 1.5 ms for 32 bit arithmetic instructions.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Igor Petrov 
Дата:   29.05.07 17:57

Sergey Shchekin писал(а):

> 1. Продукт KW-Software, который громко называется SAFEPROG
> programming platform, обеспечивает безопасные программные решения
> ИСКЛЮЧИТЕЛЬНО при использовании языков программирования IEC 61131.
> Т.е. другие языки (Си, Ассемблер и т.д.), которые обеспечивают
> (теоретически) преимущества PC-совместимого контроллера
> (универсальность, высокая производительность) не упоминаются.

Дык и у нас (в смысле в CoDeSys) аналогично. Технология требует специального Safe компилятора. После компиляции код транслируется обратно и сравнивается с исходным, дабы гарантировать отсутствие ошибок при компиляции. Компилятор Си такого не умет в принципе. Остаются МЭК языки. 3S делает этот продукт совместно с Beckhoff и Wago.

См. http://www.3s-software.com/index.shtml?CoDeSysSafety_e

> Причем в качестве примера применения своего продукта KW-Software указывает Phoenix > safety PLC. Что бы это значило?

В настоящее время KW на 100%  дочернее предприятие Phoenix Contact. Это несколько грустно, поскольку многие годы KW был основным конкурентом 3S (CoDeSys) в сегменте МЭК систем программирования высшего класса. Очень похоже на то, что KW вынужден делать новейшие вещи исключительно под Phoenix, притормаживая их появление в своем универсальном комплексе, дабы обеспечить конкурентные преимущества своим контроллерам. В итоге KW уже не главный конкурент 3S.


По МЭК языкам: по нашим данным до 80% программ сейчас пишут на ST. В CoDeSys V3 доработано все, что показалось реальным из критики МЭК. В том числе: в одном ПЛК может крутиться много независимых приложений (каждое компилируется и загружается независимо), параллельные процессы нет никаких проблем запускать из программы в любом числе, к строкам можно обращаться посимвольно (как в Си), Уникод строки. Стандарт расширен ключевыми словами из Java для поддержки полноценного ООП  (интерфейсы, наследование функциональных блоков и полиморфизм), тип ANY, переменное число параметров и возврат нескольких значений в функциях и др. и др. Показательно, что некоторые значимые модули самого CoDeSys написаны в нем самом. Например, встроенная система векторной визуализации HMI (реально это фоновая МЭК задача), компоненты SoftMotion, драйверы сетей и др.
ИМХО критика МЭК систем имеет место, но опирается на исходный древний стандарт, всякие недоделанные инструменты, с которыми приходится иметь дело. Вообще современные инструменты программирования ПЛК сейчас значительно сложнее, чем железо контроллеров и их изготовители все больше переходят на стандартные инструменты. Контроллер с CoDeSys в прошлом году выпустил Митсубиси, на носу премьера нового контроллера Шнайдер с V3. Обе фирмы имеют свои очень не слабые среды программирования, но…
Изначально очень хотелось бы в V3 оставить только языки ST и SFC, но FBD нельзя выбрасывать, поскольку его любят Французы, LD обожают в Штатах, а без IL не могут жить старые немцы. В России с языками проблем нет и заказчиков море, все умные (но бедные -:)
Примерно 5 лет назад было очень много пожеланий упростить установку CoDeSys на PC, поскольку очень много систем автоматизации делалось на PC. Мы вроде бы уже и придумали как это сделать, но тем временем ситуация сильно изменилась и несколько контрактов с изготовителями и дистрибьюторами пром. PC заморозились. Они объясняют это тем, что сейчас PC покупают в основном под серверные приложения, где МЭК даром не нужен. Возможно, существуют и другие причины, но сейчас примерно на 1000 лицензий  CoDeSys SP для ПЛК продается 1 лицензия для PC. Вот такой вот вид с нашей колокольни -:)

Игорь Петров,
ПРОЛОГ

_IP_

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   29.05.07 19:16

Eugeen писал(а):

> Насчет Сименса: если думаете что мы его применяем - считайте обидели!

Просто цифры :)

> Technical Data
> CPU - Intel 80960HT25/75 32-bit RISC SuperScalar processor up to 150 MIPS
> RAM4 MB static read/write memory
> Processing time for 1000 instructions< 1.0 ms for binary and 16 bit arithmetic
> instructions
> < 2 ms for fixed point arithmetic instructions
> < 1.5 ms for 32 bit arithmetic instructions.

CPU 416-2DP (6ES7 416-2XN05-0AB0):
Рабочая память:
встроенная, для хранения программ 2,800 Кбайт
встроенная, для хранения данных 2,800 Кбайт
Время выполнения (1000 инструкций):
логических операций 0.03 мс
операций со словами 0.03 мс
математических операций с фиксированной точкой 0.03 мс
математических операций с плавающей точкой 0.09 мс

CPU 417-4 (6ES7 417-4XT05-0AB0)
Рабочая память:
встроенная, для хранения программ 15 Мбайт
встроенная, для хранения данных 15 Мбайт
Время выполнения (1000 инструкций):
логических операций 0.018 мс
операций со словами 0.018 мс
математических операций с фиксированной точкой 0.018 мс
математических операций с плавающей точкой 0.054 мс

Не находите, что Сименс, на который Вы "обижаетесь", раз так в 30-60 побыстрее будет? :)

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   30.05.07 08:58

Я приводил данные для г-на Зубина. А вообще то я знаю контроллеры и пошустрее S7-400.
Но для системного интегратора, который сам не производит ПТК, важно уметь зарабатывать на соотношении: цена/(качество + функциональность).
 Анализ числителя:
http://www.emikonotomasyon.com/DC/fiyatListeleri/sie%20Fiyat_Listesi_1428160.pdf
показывает значительную цифру, которая никак не компенсируется знаменателем.
Открытость FREELANCE 800F нас очень првлекает.
В FREELANCE 800F меня ничто не ограничивает в применении (контроллер поддерживает):
1. Любых "чужих" (не АББ) модулей УСО не только под PRIFIBUS, но и под CAN, FOUNDATION, MODBUS, INTERBUS.
2. Использовать другую SCADA (не АББ).
3. Даже загружать "чужую" OS в контроллер AC 800F.

А для задач общепромышленного назначения скорости контроллера AC 800F вполне хватает.

Именно по этому, когда мы выходим на тендер вместе Сименсом (напр. Интеравтоматикой) мы их всегда побиваем именно за счет нашего соотношения цена/(качество + функциональность). Думаю что с появлением на рынке все большего числа частных собственников объектов требующих автоматизации (напр. в энергетике), когда этим собственникам откаты с проектов АСУ ТП надо будет платить из своего кармана (а не из кармана РАО ЕЭС) то Сименсу придется совсем туго!

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   30.05.07 09:02

Игорь, спасибо! Вот это действительно статистика.
Если еще прикинуть сколько продается ПЛК со своими средами разработки, то на долю РС (вместе с теми проектами которые реализуются с родными средами) получается что приходится менее 1-го процента продаж.
Я не знаю как там у других, но весь ЗОО-набор в нашей компании знаю отлично.
Проценты доли РС-совместимого не считал конечно + пока нет данных по новоприобретенным Юкосовским активам, но то, что РС-решений у нас единицы- это точно.
И доля их стремительно сокращается. Думаю, что это нормально для нефтянки. Как дела обстоят в других производствах- не знаю, могу предполагать что в металлургии ситуация аналогична.
Остальные- относительно бедны и покупают что могут а не что хотят...


> Возможно, существуют и другие причины, но сейчас примерно на
> 1000 лицензий  CoDeSys SP для ПЛК продается 1 лицензия для
> PC. Вот такой вот вид с нашей колокольни -:)

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   30.05.07 11:03

Игорь Петров писал(а):

> Мы вроде бы уже и придумали как это сделать, но тем временем ситуация
> сильно изменилась и несколько контрактов с изготовителями и
> дистрибьюторами пром. PC заморозились. Они объясняют это тем, что сейчас
> PC покупают в основном под серверные приложения, где МЭК даром не нужен.
> Возможно, существуют и другие причины, но сейчас примерно на 1000 лицензий
>  CoDeSys SP для ПЛК продается 1 лицензия для PC. Вот такой вот вид с нашей

А выходит по утверждениям с Вашего замечательного сайта, что "на сегодняшний день ПЛК это на 90% программный продукт. Контроллер не обеспеченный средствами визуального прикладного проектирования, с поддержкой стандартных языков, использовать очень трудоемко."
А для РС совместимых этот вопрос не на столько критичен? ПО более доступно.

Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   30.05.07 11:27

> Если еще прикинуть сколько продается ПЛК со своими средами разработки, то на долю
> РС (вместе с теми проектами которые реализуются с родными средами) получается что
> приходится менее 1-го процента продаж.

Правильные прикидки... Я уже писал, что встречал оценку доли ПЛК на мировом рынке автоматизации до 98%.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   30.05.07 11:43

Добрый день!

>Возможно, существуют и другие причины, но сейчас примерно на
>1000 лицензий  CoDeSys SP для ПЛК продается 1 лицензия для PC.
>Вот такой вот вид с нашей колокольни -:)

Это совпадает с моим общим ощущением, что количество самосборки резко
упало. Но среди этой 1000 ПЛК наверняка есть с PC-совместимыми
процессорами. Вот очень интересно сколько? Если есть информация
отдельно по Вашим продажам и по 3S.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   30.05.07 14:33

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

Тут еще дело не в языке как таковом, а в средствах, которые предоставляются для решения задчи: их открытость или закрытось.
Именно они заставляют совершенно по разному работать разработчика.
На уме очень показательный пример администрирования системы Windows или UNIX. И та и другая может быть ОС, а подходы совершенно разные. Когда для определенных нужд разработчик системы может скомпилировать под свои задачи ядро ОС,оптимизируя его, администратор WIN в лучшем случае знает какие галочки "мишкой на сервере":) надо выставить в заготовленных формах для этого.
А если их нет? Тогда и становится  ясны два принципиальных подхода а затем уже и мышления к решению задач.


Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   30.05.07 14:50

Это как всегда...идея хорошая а как до реализации дело доходит...
Знаю я одно такое средство от российского производителя- если бы не его перманентные глюки, могло бы стать отличной альтернативой кодесису, тем более что родилось намного раньше.
А так- как было Г, так и померло им.
Есть еще одно хорошее средство от головной боли- мышьяк ;)
А Вынь не умирает и даже процветает..значит кому-то оно нужно? ;)

> Тут еще дело не в языке как таковом, а в средствах, которые
> предоставляются для решения задчи: их открытость или закрытось.
> Именно они заставляют совершенно по разному работать разработчика.
> На уме очень показательный пример администрирования системы
> Windows или UNIX. И та и другая может быть ОС, а подходы
> совершенно разные. Когда для определенных нужд разработчик
> системы может скомпилировать под свои задачи ядро
> ОС,оптимизируя его, администратор WIN в лучшем случае знает
> какие галочки "мишкой на сервере":) надо выставить в
> заготовленных формах для этого.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Kuzmin Yuriy 
Дата:   30.05.07 15:28

>  Это как всегда...идея хорошая а как до реализации дело доходит...
> Знаю я одно такое средство от российского производителя- если бы не его перманентные глюки, могло бы стать отличной альтернативой кодесису, тем более что родилось намного раньше.
> А так- как было Г, так и померло им.
> Есть еще одно хорошее средство от головной боли- мышьяк ;)
> А Вынь не умирает и даже процветает..значит кому-то оно нужно? ;)

А ситуация такова, если Г. кто то подбирает или находится под гос. опекой (еще лучше), то оно глядишь и процветает уже и запашек пропал и главное всем сказано что это хрошее Г., т.е не Г. уже:))

Кузьмин Юрий

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Igor Petrov 
Дата:   30.05.07 17:01

> Кузьмин Юрий
> А выходит по утверждениям с Вашего замечательного сайта, что "на сегодняшний
> день ПЛК это на 90% программный продукт. Контроллер не обеспеченный средствами
> визуального прикладного проектирования, с поддержкой стандартных языков,
> использовать очень трудоемко."

90% имеется в виду объем разработки ПЛК. Разобрать, проанализировать аналоги, нарисовать схему сейчас не так сложно. Разработать инструментарий прикладного программирования гораздо сложнее. И вроде как получается, что с этого и надо начинать. Т.е. сначала выбрать устраивающее инструментальное ПО, изучить что нужно, чтобы реализовать все его возможности и потом сделать под это железо. Однако наши компании (исключения есть) упорно продолжают сначала разрабатывать железо, затем думать как к нему приспособить ПО. Потом получаются проблемы на пустом месте и программисты с мылом и с матом их преодолевают, многих просто не возникло бы, если бы своевременно была применена другая микросхема.

> А для РС совместимых этот вопрос не на столько критичен? ПО более доступно.

Сложный вопрос.
1) Более доступно по возможности выбора – бесспорно. Но, так ли это важно? Потребители ПЛК делают свои деньги на прикладных проектах. Которые надо делать быстро, не забивая себе голову лишним. Cилы приходится направлять на изучение объекта, прикладных алгоритмов, соответствующих требований и стандартов и т.д. и т.п. + предлагается свобода выбора ПО == доп. головная боль. Не лучше ли чтобы изготовитель оборудования продумал этот вопрос и дал проверенный инструмент (или несколько) который идеально состыкованы с железом (не хватало еще драйверы писать) и заточен под подобные задачи?

2) Доступно по цене? Да, если применять ворованное или бесплатное ПО для PC. Если покупать ПО, то для ПЛК оно не дороже чем для PC.
Конкретно в схеме с CoDeSys все проблемы решает изготовитель контроллера. Он покупает лицензии очень крупным оптом и на 1 контроллер получается очень маленькая сумма в сравнении с ценой железа (обычно она спрятана в цене контроллера). Пользователь же получает все необходимое в коробке с ПЛК от изготовителя и сразу может начать работу.

> Илья Аблин
>..Но среди этой 1000 ПЛК наверняка есть с PC-совместимыми
>процессорами. Вот очень интересно сколько? Если есть информация
>отдельно по Вашим продажам и по 3S.
По России за год получилось 12%. По другим странам не знаю.

_IP_

Адрес этого сообщения    Ответить на это сообщение
 
 Re[11]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   30.05.07 18:07

Hello Гайдаш,

Tuesday, May 29, 2007, 3:30:09 PM, you wrote:

>> Мы такие проекты не клепаем, мы их разрабатываем с нуля.. Ну, а
>> разработанные - тиражируем

ГДМ> А теперь, ВНИМАНИЕ, вопрос :)) Сколько времени (в человеко-днях) занимает
ГДМ> разработка такого проекта? ;)

Может и бесконечность, у кого как. До нас три исполнителя подряжались
на задачу Чохральского. Был и университет, и системный интегратор, и
научно-производственное объединение. Силы оказались слабые. Типовые
сроки разработки - десять лет от разработки до внедрения. Полгода-год, чтобы "всосать" азы
техпроцесса, а потом еще и куча натурных экспериментов, чтобы понять, что же
надо.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   30.05.07 20:38

> Дык и у нас (в смысле в CoDeSys) аналогично. Технология требует
> специального Safe компилятора. После компиляции код транслируется
обратно
> и сравнивается с исходным, дабы гарантировать отсутствие ошибок при
> компиляции. Компилятор Си такого не умет в принципе. Остаются МЭК
языки.
>
> Игорь Петров,
> ПРОЛОГ

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

С Уважением,
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   30.05.07 21:17

> Насчет Сименса: если думаете что мы его применяем - считайте
обидели!
> Речь идет о ABB AC 800F под FREELANCE 800F. Поддерживаются все языки
> МЭК-1131.
> Technical Data
> CPU - Intel 80960HT25/75 32-bit RISC SuperScalar processor up to
150 MIPS
> RAM4 MB static read/write memory
> Processing time for 1000 instructions< 1.0 ms for binary and 16 bit
> arithmetic
> instructions
> < 2 ms for fixed point arithmetic instructions
> < 1.5 ms for 32 bit arithmetic instructions.
>
> С уважением, Катковский Е.А.
А что система ABB AC 800F под FREELANCE 800F открыта и под неё можно
написать программу на ассемблере или Си?
Указанный Вами Intel 80960HT25/75 32-bit RISC SuperScalar processor
примерно одного поля ягоды что и 80486 который используется в
Сименсах, так что производительность должна быть одного порядка: чуть
больше-чуть меньше.

С Уважением,
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   30.05.07 21:33

kavlaskin писал(а):

> 80486 который используется в
> Сименсах, так что производительность должна быть одного порядка: чуть
> больше-чуть меньше.

http://iprog.pp.ru/forum/read.php?f=1&i=43643&t=43228#reply_43643- в 30-60 раз отличается производительность, даже не на порядок. И откуда информация о 486-х процессорах в Сименсах? :) Я эту утку (про 486-е процессоры) слышал еще 5 лет назад ;) Только вод беда - потрошили мы процессорные модули, никаких 486-х там нет.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   30.05.07 23:29

>А что система ABB AC 800F под FREELANCE 800F открыта и под неё можно
>написать программу на ассемблере или Си?

Да. Для этого во FREELANCE 800F имеется т.н.
"Application Programming Interface (API)" (артикульный №3BDS008759R04)
Несколько подробней:
http://library.abb.com/GLOBAL/SCOT/scot313.nsf/VerityDisplay/C3FADD1D2FBCA437C125727C000A83DB/$File/3BDD010023_B_ru_Freelance_800F_System_Description.pdf

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re[7]: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   30.05.07 17:57

Hello Гайдаш,

Tuesday, May 29, 2007, 11:59:18 AM, you wrote:

>> Просто есть такая штука как верификация.. Многие ее практикуют

ГДМ> И с верификацией знаком, и с валидацией... Только Вы опять теоретизируете,
ГДМ> похоже, а как это в жизни работает не знаете.

Ну а если знакомы, так почему не используете? Взорвется же когда-нибудь
объект с таким подходим к программированию... поймите правильно, не о
разработчиках пекусь, боюсь случайно рядом оказаться.

ГДМ> А вот Вам еще информация к размышлению:
ГДМ> http://iprog.pp.ru/forum/read.php?f=1&i=43594&t=43228#reply_43594

Ну и? я-то думал что-то про навороченные методы верификации...
Читайте ответ.

ГДМ> http://iprog.pp.ru/forum/read.php?f=1&i=43598&t=43228#reply_43598

Опять же, мне этот интерфейс ничего не говорит. Ни о сложности
алгоритма, ни о качестве его реализации. А на треп ни о чем
у меня нет времени. Так что увольте, без меня.

ГДМ> http://iprog.pp.ru/forum/read.php?f=1&i=43599&t=43228#reply_43599

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

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 08:51

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

Кхгрм-м-м-м-м.... Я себя стараюсь контролировать :) Но Вы просто.... Ахрм-м-м-м... У меня нет слов просто. Приведен кусок кода на языке SCL (ST) - это МЭК-язык. И это такой примитив, который недостоин детального обсуждения - в системах есть существенно более сложные вещи, которые великолепно реализуются на МЭК-языках. Придется и мне Вам напомнить, что многократное повторение одного и того же
спорного утверждения не делает это утверждение истинным (с)

Ну в самом деле, это уже неадекватностью какой-то попахивает, честное слово.

> Ну а если знакомы, так почему не используете? Взорвется же когда-нибудь
> объект с таким подходим к программированию...

За 30 лет внедрения на нескольких тысячах объектов ни разу ничего не взорвали - не переживайте. И не потому, что такие умные, а потому, что есть механизмы обеспечения безопасности, которые не реализуются средствами языков C++ и Рефлекс :) Это во-первых. Во-вторых, там, где это нужно, там оно используется - инструменты даны для того, чтобы их использовать по назначению, а не бездумно пихать во все дыры.

> А на треп ни о чем у меня нет времени. Так что увольте, без меня

Ну так и не трепитесь.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   31.05.07 10:39

Информация, конечно, не из официальных источников.
Очень было бы интересно узнать из первых рук какой же там всётаки
процессор стоит. Сделайте милость огласите результаты "вскрытия".
Про 30-60 раз могу сказать что непонятно откуда эта цифра у Вас
выскочила, скорее всего это ошибка. Если привести 150 MIPS к 1000
инструкций то получим цифру  0.0067 мс, что довольно близко к
параметрам Сименса.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 11:05

kavlaskin писал(а):

> Информация, конечно, не из официальных источников.

Ну разумеется :)

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

Там сименсовская маркировка на процессоре - махровый OEM.

> Про 30-60 раз могу сказать что непонятно откуда эта цифра у Вас
> выскочила, скорее всего это ошибка.

http://iprog.pp.ru/forum/read.php?f=1&i=43643&t=43228#reply_43643 - вот исходное сообщение (цифры для Сименса взяты из документации, в них сомневаться не приходится). Вполне допускаю, что Eugeen мог ошибиться.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Alexey Yakushev 
Дата:   31.05.07 11:48

Здравствуйте, Константин.

Вы писали 31 мая 2007 г., 10:39:05:

k> Про 30-60 раз могу сказать что непонятно откуда эта цифра у Вас
k> выскочила, скорее всего это ошибка. Если привести 150 MIPS к 1000
k> инструкций то получим цифру  0.0067 мс, что довольно близко к
k> параметрам Сименса.

Не следует забывать, что это RISC-процессор. У него инструкции
"короткие", элементарные, таких инструкций для выполнения одной
вычислительной операции (к примеру, сложения двух целых чисел)
требуется несколько, в то время как CISC-процессор, да хоть и
пресловутый i486, это делает за одну операцию. Так что я полагаю, что
ошибки тут нет.

--
С уважением,
Алексей Якушев,
НПК "Ленпромавтоматика".
mailto: yak@xxxxxxx.xxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   31.05.07 11:56

Гайдаш Д.М.> Кхгрм-м-м-м-м.... Ахрм-м-м-м... У меня нет слов просто.
У меня к Вам личный вопрос: Вы уже институт закончили, или на практике подрабатываете?

Igor Petrov> В CoDeSys V3 ... Стандарт расширен ключевыми словами из Java для поддержки полноценного ООП ...
Посмотрите, плз, почту (info)

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 12:11

Бардичев Виктор писал(а):

> Гайдаш Д.М.> Кхгрм-м-м-м-м.... Ахрм-м-м-м... У меня нет слов просто.
> У меня к Вам личный вопрос: Вы уже институт закончили, или на практике
> подрабатываете?

А что, Вы считаете мою реакцию ненормальной? Если Вам в ответ на приведенный кусок кода напишут, что указанная задача не реализуется на данном языке программирования, то как Вы отреагируете? ИМХО, это полная неадекватность.

P.S. На личный поврос ответил лично - смотрите свою почту.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 12:16

Письмо вернулось с пометкой User not found (e-mail из Вашего профиля).

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   31.05.07 12:21

<>Не следует забывать, что это RISC-процессор. У него инструкции
>"короткие", элементарные, таких инструкций для выполнения одной
>вычислительной операции (к примеру, сложения двух целых чисел)
>требуется несколько, в то время как CISC-процессор, да хоть и
>пресловутый i486, это делает за одну операцию. Так что я полагаю, что
>ошибки тут нет.

Не совсем точно, см.:
http://www.tiei.ru/ppage/pages/117/VMSConsp/Glava%202/Index15.htm

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   31.05.07 12:28

>Вполне допускаю, что Eugeen мог ошибиться.

 Я же дал полную ссылку:
http://iprog.pp.ru/forum/read.php?f=1&i=43677&t=43228
Смотрите внимательно описание контроллера.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 12:31

Eugeen писал(а):

>  Я же дал полную ссылку:
> http://iprog.pp.ru/forum/read.php?f=1&i=43677&t=43228

Действительно, ссылка полная :)

> Смотрите внимательно описание контроллера.

Я верю приведенным цифрам, но это в 30 раз медленнее 416-го и в 60 раз медленнее 417-го процессоров.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   31.05.07 12:37

Гайдаш Д.М.> А что, Вы считаете мою реакцию ненормальной?
Когда я был молодым, и имел мало опыта и знаний - точно так же себя вел.

Есть поговорка "Первым заканчивает бесполезный спор тот, кто умнее."
Гайдаш Д.М.> Взять что ли на вооружение?


А про почту - это не к Вам.

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   31.05.07 12:43

Бардичев Виктор писал(а):

> А про почту - это не к Вам.

Вы мне задали ЛИЧНЫЙ вопрос, а для решения ЛИЧНЫХ вопросов существуют другие средства коммуникации. Ответ на Ваш ЛИЧНЫЙ вопрос я написал на почту из Вашего профиля - вот и все.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: *SPAM* Score: 5.1/5.0 - Re: PC-совместимый контроллер vs PLC.
Автор: zyubin@xxx.xxx.xx 
Дата:   31.05.07 12:32

Hello kavlaskin,

Wednesday, May 30, 2007, 11:38:47 PM, you wrote:

>> Дык и у нас (в смысле в CoDeSys) аналогично. Технология требует
>> специального Safe компилятора. После компиляции код транслируется
k> обратно
>> и сравнивается с исходным, дабы гарантировать отсутствие ошибок при
>> компиляции. Компилятор Си такого не умет в принципе. Остаются МЭК
k> языки.
>>
>> Игорь Петров,
>> ПРОЛОГ

k> А про "транслируется обратно" это точная информация?
k> На сколько мне известно задача реверсинжиниринга довольно не
k> тривиальная и исходный код даже в ассемблере  не удаётся восстановить,
k> а про высокоуровневые языки и речи нет.

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

То есть на первый взгляд задача либо нерешаема, либо бесполезна.

--
Best regards,
 zyubin

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   31.05.07 13:14

Гайдаш Д.М.> Письмо вернулось с пометкой User not found (e-mail из Вашего профиля).
Действительно, неправильная настройка ящика. А я писем жду :(
Теперь можете посылать ;)

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   31.05.07 14:49

Ну уж чего чего, а выполнять элементарные команды деление и умножение
RISC-и за один такт умеют. По крайней мере у 80960 такие инструкции
есть.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Igor Petrov 
Дата:   31.05.07 15:06

kavlaskin писал(а):


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

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

_IP_

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ilya Ablin 
Дата:   31.05.07 15:26

Добрый день!

>>..Но среди этой 1000 ПЛК наверняка есть с PC-совместимыми
>процессорами.
>>Вот очень интересно сколько? Если есть информация отдельно по Вашим
>>продажам и по 3S.
>По России за год получилось 12%. По другим странам не знаю.

Похоже, я задал слишком общий вопрос. Можно ли дать цифру не для всех
ПЛК, а только для модульных (крейтовых)? А то мы так смешаем в одну
кучу малоканальные контроллеры, заточенные под узкий класс задач, и
универсальные.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Igor Petrov 
Дата:   31.05.07 20:01

Добрый вечер!

Ilya Ablin писал(а):

> Похоже, я задал слишком общий вопрос. Можно ли дать цифру не для всех
> ПЛК, а только для модульных (крейтовых)? А то мы так смешаем в одну
> кучу малоканальные контроллеры, заточенные под узкий класс задач, и
> универсальные.

Мои данные, относятся именно к смеси. Затрудняюсь подсчитать отдельно модульные, поскольку у нас в лицензиях нет такого деления в принципе, привязка только к типу процессора. По тому что сейчас в разработке и часто спрашивают, лидируют процессоры c ядром ARM.

С уважением,
Игорь Петров

_IP_

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Derischev Maxim 
Дата:   01.06.07 23:19

Один из главных агрументов в пользу PLC, как альтернативе PC-
совместимых контроллеров, ставят возможность визуального
программирования. Мол с языком электроконтактных схем справится любой
средний инженер. Что тут можно возразить. Если человек не справился с
этим, то это уже клинический случай. Безусловно, что
такие "электрические схемы" очень просто отлаживать. Наглядно видно,
когда складывается, или не складывается логическая цепочка. Но есть
одно но, что программы растут очень быстро. И виртуальная
электрическая схема работает совсем не так, как реальная. И очень
быстро вчерашнему электрику приходится познавать, что такая
электрическая схема на самом деле квази-параллельная, что всё
выполняется последовательно и циклически. Очень быстро возникает
нужда в циклической обработке и косвенной адресации. В реальных
электрических схемах этого нет. Когда я такое увидел на S7-200 я
рассмеялся. Чего уж говорить про структуры, индексный вызов... Ни
разу не видел я чтобы, кто-то на S7-400 писал на языке
электроконтактных схем. Язык электроконтактных схем похож на детские
ходунки. Бытовало мнение, что при их помощи ребёнок быстро научится
ходить. Да, в ходунках дети начинают ходить быстро, но отучаются от
ходунков они очень долго. В итоге это приводило к отставанию в
развитии опорно-двигательного аппарата. Известны случаи инвалидности,
когда дети вообще не могли потом передвигаться, без каких-то
технических средств. Вот так полно людей, которые очень быстро
освоили язык электроконтактных схем, и теперь ни на что другое не
способны. Так годами и занимаются простейшими задачами. Тот факт, что
для Симатика придумали язык высого уровня (Паскаль не Паскаль, Си не
Си) доказывает, что визуальное программирование не явлется каким-то
важным преимуществом.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Владимир Е. Зюбин 
Дата:   02.06.07 11:35

Гайдаш Д.М. писал(а):

> > Я уже не обсуждаю то, что алгоблок, с
> > приведенный Вами свойствами, средствами МЭК-языков не пишется.
>
> Кхгрм-м-м-м-м.... Я себя стараюсь контролировать :) Но Вы просто....
> Ахрм-м-м-м... У меня нет слов просто. Приведен кусок кода на языке SCL (ST) -
> это МЭК-язык. И это такой примитив, который недостоин детального обсуждения - в
> системах есть существенно более сложные вещи, которые великолепно реализуются на
> МЭК-языках. Придется и мне Вам напомнить, что многократное повторение одного и
> того же
> спорного утверждения не делает это утверждение истинным (с)
>
> Ну в самом деле, это уже неадекватностью какой-то попахивает, честное слово.
>
> > Ну а если знакомы, так почему не используете? Взорвется же когда-нибудь
> > объект с таким подходим к программированию...
>
> За 30 лет внедрения на нескольких тысячах объектов ни разу ничего не взорвали -
> не переживайте. И не потому, что такие умные, а потому, что есть механизмы
> обеспечения безопасности, которые не реализуются средствами языков C++ и Рефлекс
> :) Это во-первых. Во-вторых, там, где это нужно, там оно используется -
> инструменты даны для того, чтобы их использовать по назначению, а не бездумно
> пихать во все дыры.

Дмирий Михайлович, Вы не кипятитесь, а читайте внимательно, что Вам пишут.
И не надо Си ругать. У многих МЭК-реализаций язык Си, по сути, шестой язык.
Можно книгу И. Петрова перечитать, на русском.

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

> > А на треп ни о чем у меня нет времени. Так что увольте, без меня
>
> Ну так и не трепитесь.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   02.06.07 12:28

Владимир Е. Зюбин писал(а):

> А то, что Вы не верифицируете свои алгоритмы перед загрузкой на объект, это Вы
> же сами и пишете...

Есть разные объекты - для одних верификация требуется, для других - нет. И не надо путать процедуру верификации с проверкой алгоритмов на имитаторе или стенде - это совершенно разные вещи. Насчет исправления ошибок "на лету" - это просто демонстрация возможностей, которые есть у МЭК-сред и ПЛК.

> И не надо Си ругать

Тоже могу посоветовать Вам читать внимательнее - никто Си не ругает, просто есть области, в которых он неприменим. Могу еще раз повторить - каждый инструмент необходимо применять по назначению.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   04.06.07 13:39

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Alexander Kulikov 
Дата:   04.06.07 15:04

----- Original Message -----
From: "kavlaskin"
Sent: Monday, June 04, 2007 1:39 PM

> Что касается  LD, то лично мне ещё ни разу не довелось увидеть
> программиста PLC который бы понимал в работе реальных релейно-
> контактных схем. С развитием PLC надобность в таких схемах может и
> вовсе исчезнуть, а в этом случае даже и инженер АСУТП может не
> вспомнить или не знать вовсе как такая схема работает. В этом случае
> достоинства LD исчезают. Полагаю что программист PLC в любом случае
> все эти языки перекладывает на знакомые ему алгоритмические структуры
> типа И,ИЛИ,ЕСЛИ и т.д.

Работал недавно с программистом из румынского отделния DANIELI.
Так он правил тексты в LAD а не в FBD. А лет ему около 30.

С уважением,
                        Куликов А.И.

ООО <ГТ-Электрофизика>
г.Липецк

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   04.06.07 17:41

Ну и о чём это говорит?
Может быть о том, что к данному контроллеру ничего кроме LAD-а и не
прилагается.

С Уважение
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   04.06.07 23:33

Уважаемый Константин,
По-моему, Ваше замечание примерно соответствует такому:
"Ни разу не встречал профессионального математика, который знал бы
таблицу умножения" ;-).

Человек, не понимающий, как работает релейная схема, едва ли сможет
разобраться с более серьезными вещами в АСУТП. По одной из двух
возможных причин:
а) либо он был двоечником в институте и поэтому не усвоил даже основ,
б) либо он вообще не имеет соответствующего образования (это по теме
давно упоминавшихся "компьютерных мальчиков")

С Уважением
Сргей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Alexander Kulikov 
Дата:   05.06.07 09:42

> >
> > ----- Original Message -----
> >
> > Работал недавно с программистом из румынского отделния DANIELI.
> > Так он правил тексты в LAD а не в FBD. А лет ему около 30.
>
> Ну и о чём это говорит?
> Может быть о том, что к данному контроллеру ничего кроме LAD-а и не
> прилагается.
>
Ну почему, же? Говорит это о том, что не надо обобщать. Среда Step7. Ему LAD
удобнее и понятнее, в отличии от меня.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   05.06.07 11:10

>Работал недавно с программистом из румынского отделния DANIELI.
>Так он правил тексты в LAD а не в FBD. А лет ему около 30.
Аналогичный опыт с хорватскими программистами.
Причем накручивают в LAD такие сети, которые в IL занимали бы несколько строки и условных переходов. Про _минимальную_дизъюнктивную_форму_ вообще речи нет. Когда преобразуешь их страшные вычисления, оказывается, логика то простая.

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   05.06.07 12:18

А Вы сами много за последние пару лет релейных шкафов напроектировали?
Речь не о том что не сможет разобраться, а о том что имеющиеся навыки
работы с релейной логикой должны помочь человеку разобраться с языком.
А навыки такие у специалистов могут отсутствовать и не потому что они
двоечники, а потому что данный вид автоматики постепенно исчезает.
Было бы интересно узнать у участников форума как часто в последние
пару лет им приходилось сталкиваться с реализацией схем управления на
релейной логике.


С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   05.06.07 12:42

kavlaskin писал(а):

> Было бы интересно узнать у участников форума как часто в последние
> пару лет им приходилось сталкиваться с реализацией схем управления на
> релейной логике.

Имменно управление на релейной логике не делают, а вот всяческие системы защиты (в том числе по SIL4) делают именно на ней.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Леонид Мирошко 
Дата:   05.06.07 12:35

> Было бы интересно узнать у участников форума как часто в последние пару
> лет им приходилось сталкиваться с реализацией схем управления на релейной
> логике.

Регулярно. Контроллеры контроллерами, а последний уровень защит - релейная
логика. Например, защита от размораживания калорифера, защиты от сухого
хода, от перегрева ТЭН. И не всегда это один контакт - довольно часто нужно
обеспечить либо работу, либо защиту при выходе контроллера из строя. А
иногда нужно включить оборудование в работу, когда контроллера еще нет
физически. Например, теплопункт на строящемся объекте и
срочно-срочно-срочно...

С уважением Леонид Мирошко.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Бардичев Виктор 
Дата:   05.06.07 12:53

kavlaskin> Было бы интересно узнать у участников форума как часто в последние
пару лет им приходилось сталкиваться с реализацией схем управления на
релейной логике.

В наших системах привод исполнительных механизмов в начальное состояние выполняется именно релейными схемами. То есть, если контроллер выдаст "0" на выход, или сработает сторожевой таймер распределенной периферии, задвижка или кран закроется без контроллера.

Системы безопасности и аварийные выключатели то же управляют минуя контроллер.

С уважением, Бардичев Виктор

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   05.06.07 15:14

Сам я чисто релейные шкафы никогда не проектировал. Но стыковать
АСУТП с релейной автоматикой приходилось довольно часто. Две
возможные причины:

1) Во многих случаях Заказчик хочет сохранить возможность ПОЛНОСТЬЮ
РУЧНОГО управления каким либо оборудованием типа пожарных насосов,
электроуправляемых задвижек и т.п. "Полностью ручное" означает
возможность работы при ПОЛНОМ отказе АСУТП (например, при пожаре в
помещении, где стоят контроллеры).

2) Частичная реконструкция. Например, заказчику нужна система
антипомпажного регулирования компрессора, но вспомогательная
автоматика его полностью устраивает. "Вспомогательная автоматика"
включает в себя маслосистемы смазки и уплотнения, подогреватели
масла, систему вентиляции, технологические задвижки, краны, клапана и
кучу другого оборудования.

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

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

Навыки практической работы с релейной автоматикой помогут сэкономить
кучу времени при решении тривиальных программных задачек, которые
часто съедают значительную долю времени, отведеннго на проектирование
(программирование?) и особенно на пуско-наладку.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Владимир Е. Зюбин 
Дата:   06.06.07 15:25

Гайдаш Д.М. писал(а):

> Владимир Е. Зюбин писал(а):
>
> > А то, что Вы не верифицируете свои алгоритмы перед загрузкой на объект, это Вы
> > же сами и пишете...
>
> Есть разные объекты - для одних верификация требуется, для других - нет. И не
> надо путать процедуру верификации с проверкой алгоритмов на имитаторе или стенде
> - это совершенно разные вещи. Насчет исправления ошибок "на лету" - это просто
> демонстрация возможностей, которые есть у МЭК-сред и ПЛК.

Что такое верификация, несложно выяснить в учебниках и исследованиях по безопасности ПО. А вот Вы почему-то считаете, что тестирование на имитаторах это не верификация. Что же это такое по Вашему, интересно узнать?

> > И не надо Си ругать
>
> Тоже могу посоветовать Вам читать внимательнее - никто Си не ругает, просто есть
> области, в которых он неприменим. Могу еще раз повторить - каждый инструмент
> необходимо применять по назначению.

Си-это универсальный язык, который покрывает МЭК как бык овцу, более того, практически все МЭК-среды на Си-написаны. Не всегда удобен - согласен. Ровно так же как и все МЭК-языки, и кучей, и по отдельности. Поставьте в Си for(;;) и все встанет на свои места.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   06.06.07 16:52

> Имменно управление на релейной логике не делают, а вот всяческие
системы
> защиты (в том числе по SIL4) делают именно на ней.
>
> С уважением,
> Гайдаш Дмитрий Михайлович
> ЗАО "НПФ "Система-Сервис"

Ну а как же контроллеры которые сертифицируют для этих целей(по уровням
SIL) или они всё же ещё неспособны полностью заменить "железную" логику.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re: PC-совместимый контроллер vs PLC.
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   06.06.07 16:56

По SIL 4 вообще запрещено применение микропроцессорной техники :)
Только 4-ка пожалуй только на АЭС...и все.

> Ну а как же контроллеры которые сертифицируют для этих
> целей(по уровням
> SIL) или они всё же ещё неспособны полностью заменить
> "железную" логику.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   06.06.07 17:16

kavlaskin писал(а):

> Ну а как же контроллеры которые сертифицируют для этих целей(по уровням
> SIL) или они всё же ещё неспособны полностью заменить "железную" логику.

Контроллеры сертифицируют только по SIL-1 - SIL-3 :) SIL-4 уже нет.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   06.06.07 19:45

> Я верю приведенным цифрам, но это в 30 раз медленнее 416-го и в 60
раз
> медленнее 417-го процессоров.
>
> С уважением,
> Гайдаш Дмитрий Михайлович
> ЗАО "НПФ "Система-Сервис"

В таком случае можно только догадываться путём каких "оптимизаций"
архитектуры PLC можно было "выжать" из процессора с
производительностью 150MIPS такие "потрясающие" результаты.
Например на сайте Intel для ближайшего по частоте HD-66 процессора
приводятся(документ называется i960 Microprocessor Performance Brief)
такие цифры:
порядка 10000000 единиц в тесте Whetstone-Single Precision. Т.е. это
примерно эквивалентно 10000000 операций в секунду с числами в формате
с плавающей точкой одинарной точности. Что эквивалентно 1000 операций
за 0,1 мс(что очень близко к 0,09 и 0,054 указанной для процессоров
Сименс).  Если учесть что процессор не имеет блока вычислений с
плавающей точкой то команды целочисленной и бинарной арифметики
должны выполняться в несколько раз или даже на порядок быстрее.
Поэтому я не очень то верю в цифры:
Processing time for 1000 instructions< 1.0 ms for binary and 16 bit
arithmetic instructions
< 2 ms for fixed point arithmetic instructions
< 1.5 ms for 32 bit arithmetic instructions.
Хотя, с другой стороны, оператор < можно понимать довольно широко.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   06.06.07 22:14

В Российских нормативах для АЭС нет понятия SIL, ПТК аттестуются по т.н. классу безопасности. На сегодня максимально аттестованопо первому классу 0, по второму классу всего 2 ПТК, , по третьему классу около 10-ти. Процедура аттестации нудная и запутанная, требования непрозрачные (на мой взгляд). Хотя собственно системы безопасности и не требуют для включения и работы каких-либо ПТК. Когда в основу безопасности АЭС закладывается понятие МПА (Максимальной Проектной Аварии) под МПА и рассчитываются все системы безопасности и логика их работы. Считается, что если авария запроектная, то и любое управление ничего не даст будь оно даже нулевого класса безопасности (шутка).

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   07.06.07 00:16

Уважаемые, не проясните ли мне пожалуйста, где это в IEC 61508 запрещено применение микропроцессоров при SIL4?

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   07.06.07 15:11

Константин, для PLC обычно указывается производительность выполнения
инструкций ПРИКЛАДНОЙ программы. А "150MIPS" - это скорость
выполнения инструкций МАШИННОГО КОДА ПРОЦЕССОРА.

Если процессорный модуль PLC реализован на обычном (универсальном)
микропроцессоре (например, x86), то, как правило, он работает в
режиме интерпретатора  прикладной программы. В этом случае на одну
ПРИКЛАДНУЮ инструкцию может потребоваться несколько десятков МАШИННЫХ
инструкций. Отсюда и появляется разница в 30-60 (и более) раз.

Сименс потому и использует свои весьма дорогие OEM-процессоры вместо
универсальных (массовых и дешевых). Цена вопроса - РЕАЛЬНАЯ
производительность системы управления, особенно скорость битовых
операций. Попробуйте написать на ассемблере x86 код, выполняющий
битовую операцию, и Вы сразу увидите всю неуклюжесть x86. А заодно
почувствуете, в какое место "проваливаются" эти MIPS ;-).

C уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   07.06.07 18:53

За сколько по Вашему на х86 будет выполняться битовая операция? И в
чём неуклюжесть? В машинных кодах это ещё неизвестно где программа
будет более неуклюжей. Вы что же серьёзно полагаете что у того же
Сименса используется какой то мудрёный процессор
специально "заточенный" под языки МЭК.
Вот ссылка где описано какой процессор стоит в S-300
http://www.automation-drives.ru/forum/viewtopic.php?t=5893&highlight=%
EF%F0%EE%F6%E5%F1%F1%EE%F0
Там же есть ссылка на фото. На одной из фотографий отчётливо видно
процессор: Infineon SXA1020B2-E. Подробной информации о данном
процессоре, к сожалению, мне найти не удалось.
MIPS-ы, конечно, мало говорят о производительности в конкретных
задачах, но мы же сравниваем время выполнения элементарных операций.
Не хотите же Вы сказать что операторы +,-,*,&,|| в языках МЭК могут
транслироваться в какую то бесконечную череду случайных машинных
кодов.
Если Вы не заметили, то кроме MIPS-ов я указал результаты теста
выполнений операций с плавающей точкой и результаты этого теста также
заставляют задуматься.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Yakushenko 
Дата:   08.06.07 14:46

>Там же есть ссылка на фото. На одной из фотографий отчётливо видно
>процессор: Infineon SXA1020B2-E. Подробной информации о данном
>процессоре, к сожалению, мне найти не удалось.

Все таки это процессор из OEM-ной партии,
сделанной для подразделения A&D.
Хотя внутри это скорее всего более-менее стандартный микроконтроллер или процессор.
Infinion тоже, кстати, частично принадлежит Сименс.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   09.06.07 23:47

> Си-это универсальный язык, который покрывает МЭК как бык овцу, более
того,
> практически все МЭК-среды на Си-написаны. Не всегда удобен - согласен.
> Ровно так же как и все МЭК-языки, и кучей, и по отдельности.

Владимир, какие у Вас порой появляются романтические высказывания!
Видимо, надо понимать так, что применять Си в АСУТП так же практически
полезно, как в реальном животноводстве - покрывать овец быками :-)))).

IMHO, овцу покрывать должен не бык, а баран. Полезнее с точки зрения
ПРАКТИЧЕСКОГО результата ;-).

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   10.06.07 00:22

Неуклюжесть состоит в том, что x86 просто не имеет команд выполнения
битовых операций. Поясню более подробно.
Предположим, в памяти контроллера лежат 2 битовых операнда, над
которыми нужно выполнить операцию И, и результат поместить в память.
Например:
Операнд 1: бит 2 байта X1
Операнд 2: бит 5 байта X2
Результат: бит 7 байта X3
Насколько я понимаю, код для x86 будет примерно следующим. (Заранее
извиняюсь на возможные неточности, т.к. на Ассемблере давно не писал)

MOV AL,X1 ; загрузить байт, содержащий операнд 1
SHR AL,2 ; сдвинуть нужный бит в разряд 0
MOV BL,X2 ; загрузить байт, содержащий операнд 2
SHR BL,5 ; сдвинуть нужный бит в разряд 0
AND AL,BL ; собственно операция
AND AL,01h; наложить маску для выделения бита результата
SHL AL,7 ; сдвинуть бит результата в разряд 7
MOV BL,AL ; и поместить в другой регистр
MOV AL,X3 ; загрузить байт, в который нужно поместить результат
AND AL,07Fh ; наложить маску для обнуления бита результата
OR AL,BL ; получить новое значение байта с результатом
MOV X3,BL ; положить на место байт с результатом

За сколько по-Вашему на х86 будет выполняться битовая операция -
посчитайте сами. Но явно это будет "немного" дольше той операции, что
измеряется в MIPS ;-).
Причем данный код может иметь место только в СКОМПИЛИРОВАННОЙ
программе, которая, к сожалению, лишает PLC возможностей необходимого
on-line сервиса. В ИНТЕРПРЕТИРУЕМОЙ программе код будет гораздо
длиннее.

> В машинных кодах это ещё неизвестно где программа
> будет более неуклюжей. Вы что же серьёзно полагаете что у того же
> Сименса используется какой то мудрёный процессор
> специально "заточенный" под языки МЭК.

Константин, Вы, наверное, будете смеяться, но предмет Вашей иронии -
 "мудрёный процессор специально "заточенный" под языки МЭК" - реально
существует.
Я не полагаю, а знаю, что в контроллерах SIEMENS до SIMATIC S5
включительно использовался специализированный битовый процессор. Или,
если угодно, битовый СОпроцессор, который имел огромное (по тем
временам) быстродействие при выполнении соответствующих операций. В
определенном смысле он действительно был "заточен" именно под  языки
МЭК, поскольку для большинства логических операций
(например, "нормально открытый контакт" в KOP) команда вместе с
адресом операнда умещались в 1 (одно) 16-битовое слово. Если Вы
сможете аргументировано показать, что другой язык (не МЭК) генерирует
более компактный машинный код прикладной программы, я, как
говорится, "съем свой галстук". Или сгрызу свою клавиатуру :-).

Извиняюсь, что говорю только про SIMATIC S5. Просто я с S7 не
работал. Но на 90% уверен, что все вышесказанное применимо и к S7.


> Если Вы не заметили, то кроме MIPS-ов я указал результаты теста
> выполнений операций с плавающей точкой и результаты этого теста
также
> заставляют задуматься.

Я заметил. Но не понял, о чем надо задуматься, глядя на приведенные
Вами цифры. Поясните, пожалуйста, что Вас смущает.


С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Виктор 
Дата:   10.06.07 00:58

> Отсюда и появляется разница в 30-60 (и более) раз.

Логично было бы предположить, что если бы Сименс умел делать процессоры в 60 раз (или в 30, все равно) более быстрые, чем у Интел или АМД, то последние уже давно бы разорились ;)

Виктор
ОАО "ИНЭУМ"

[Non-text portions of this message have been removed]

Адрес этого сообщения    Ответить на это сообщение
 
 Ответ: Re: PC-совместимый контроллер vs PLC.
Автор: Роман Абзаев 
Дата:   09.06.07 21:23

>Infinion тоже, кстати, частично принадлежит Сименс.

  Там весьма небольшая доля. Это бывшее подрозделение было выведено на биржу в ход большой реорганизации 1997-1999 годов и деконсолидировано из отчётности к 2003 году.

  С уважением,
     Роман Абзаев




---------------------------------
 Вы уже с Yahoo!?
 Испытайте обновленную и улучшенную Yahoo! Почту!

[Non-text portions of this message have been removed]

Адрес этого сообщения    Ответить на это сообщение
 
 Ответ: Re: Re: PC-совместимый контроллер vs PLC.
Автор: Роман Абзаев 
Дата:   10.06.07 19:49

>Логично было бы предположить, что если бы Сименс умел делать >процессоры в 60 раз (или в 30, все равно) более быстрые, чем у Интел >или АМД, то последние уже давно бы разорились ;)

  Дело не в скорости, а в заточенности под задачи.

  Роман Абзаев



---------------------------------
 Вы уже с Yahoo!?
 Испытайте обновленную и улучшенную Yahoo! Почту!

[Non-text portions of this message have been removed]

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-УПЧНЕУФЙНЩК ЛПОФТПММЕТ vs PLC.
Автор: Serge 
Дата:   10.06.07 21:38

SS>  Если Вы
SS>  сможете аргументировано показать, что другой язык (не МЭК) генерирует
SS>  более компактный машинный код прикладной программы, я, как
SS>  говорится, "съем свой галстук". Или сгрызу свою клавиатуру :-).

На любом высокоуровневом языке задача решается за раз, при условии доступа к коду
компилятора.

Вводим, например, в язык процедуру (один из самых грубых способов):
__And(v1, bit1, v2, bit2, result, resultBit);
и ее, напрямую, транслируем в маш. инструкцию.

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



--
Best regards,
 Serge                            mailto:legar@xxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Oleg Alekseyev 
Дата:   11.06.07 10:25

----- Original Message -----
From: Sergey Shchekin
Subject: [asutp] Re: PC-совместимый контроллер vs PLC.


> Предположим, в памяти контроллера лежат 2 битовых операнда, над
> которыми нужно выполнить операцию И, и результат поместить в память.
> Например:
> Операнд 1: бит 2 байта X1
> Операнд 2: бит 5 байта X2
> Результат: бит 7 байта X3

Итого, 6 адресов. (запомним).

> Константин, Вы, наверное, будете смеяться, но предмет Вашей иронии -
> "мудрёный процессор специально "заточенный" под языки МЭК" - реально
> существует.
> Я не полагаю, а знаю, что в контроллерах SIEMENS до SIMATIC S5
> включительно использовался специализированный битовый процессор. Или,
> если угодно, битовый СОпроцессор, который имел огромное (по тем
> временам) быстродействие при выполнении соответствующих операций. В
> определенном смысле он действительно был "заточен" именно под языки
> МЭК, поскольку для большинства логических операций
> (например, "нормально открытый контакт" в KOP) команда вместе с
> адресом операнда умещались в 1 (одно) 16-битовое слово. Если Вы
> сможете аргументировано показать, что другой язык (не МЭК) генерирует
> более компактный машинный код прикладной программы, я, как
> говорится, "съем свой галстук". Или сгрызу свою клавиатуру :-).

Было бы весьма любопытно увидеть код приведенного примера в командах
упомянутого сопроцессора. Мне не известны механизмы, как в 16 битовое слово
упаковать код команды и 6 адресов (или хотя бы два). Следовательно, адреса
хранятся в предопределённых индексных регистрах или вершине стека, которые перед
исполнением команды следует загрузить. И где Вы видите "заточенность"?
Если примера не будет, Будем считать, что Вы "съели свой галстук"? ;)

Сергей, Вы, наверное, будете смеяться, но любой процессор с трёхадресной
системой команд на мой взгяд "заточен" под любые языки, в том числе МЭК и Си.
http://www.computer-museum.ru/histussr/12-3.htm

С уважением,
Олег Алексеев.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Дмитрий Цудиков 
Дата:   11.06.07 12:02

> > Си-это универсальный язык, который покрывает МЭК как бык

> овцу, более того,
>
> Владимир, какие у Вас порой появляются романтические
высказывания!
> Видимо, надо понимать так, что применять Си в АСУТП так же

> практически
> полезно, как в реальном животноводстве - покрывать овец
быками :-)))).
Сергей, простите, что вмешиваюсь в вашу дискуссию. Владимир
не романтическое высказывание позволил, а просто неполную
цитату, из Жванецкого. Полностью, если мне не изменяет
память, фраза звучит так: "Швейцария маленькая страна,
Красноярский край покрывает её, как бык овцу".
Пользуясь случаем, раз уж я всё-таки влез, позволю обратить
внимание уважаемых участников на статистические данные: тема
"PC-совместимый контроллер vs PLC" обсуждается уже второй
месяц (с 7-го мая), поступило более 200 сообщений.
Справедливости ради стоит отметить, что крупицы нового
знания, внимательно читая, всё же можно почерпнуть.
Например, из последнего - утверждение о заточенности
процессоров SIMATIC S5 под МЭК, в частности, использование в
нём битовых операндов. Эта информация, действительно,
заслуживает внимания.

С уважением,
Дмитрий Цудиков.

Адрес этого сообщения    Ответить на это сообщение
 
 Ответ: RE: PC-совместимый контроллер vs PLC.
Автор: Роман Абзаев 
Дата:   11.06.07 17:49

>Пользуясь случаем, раз уж я всё-таки влез, позволю обратить
>внимание уважаемых участников на статистические данные: тема
>"PC-совместимый контроллер vs PLC" обсуждается уже второй
>месяц (с 7-го мая), поступило более 200 сообщений.

  Дмитрий, день добрый!

  Эта тема обсуждается в этой конференции не один год...

  Роман Абзаев


---------------------------------
 Вы уже с Yahoo!?
 Испытайте обновленную и улучшенную Yahoo! Почту!

[Non-text portions of this message have been removed]

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   12.06.07 09:39

Уважаемый Олег,
Я говорил про контакт, команду и адрес операнда в ЕДИНСТВЕННОМ числе.
Так что мне тоже было бы любопытно увидеть, как в 16-битовое слово
упаковать код команды и 6 адресов (или хотя бы два) :-).


> ... И где Вы видите "заточенность"?

"Заточенностью" можно считать то, что 1 слово программы (минимальная
единица программы) соответствует 1 символу языка KOP.


> Если примера не будет, Будем считать, что Вы "съели свой
галстук"? ;)

Пример на языке AWL (IL в МЭК 1131):
U M12.2
U M13.5
= M14.7
3 (три) машинных слова по 16 бит.

Предвидя возможную иронию со стороны оппонентов, еще раз подчеркну:
это РЕАЛЬНЫЙ машинный код процессора, а не программа, которая
компилируется и "распухает" в разы.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   12.06.07 09:46

Уважаемый Serge,
К сожалению, я не могу считать Ваш ответ аргументированным.
Не могли бы Вы привести ассемблерный (транслированный) код
своего "изящного" решения?

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Oleg Alekseyev 
Дата:   12.06.07 10:58

----- Original Message -----
From: "Sergey Shchekin"
Subject: [asutp] Re: PC-совместимый контроллер vs PLC.


>
> Предвидя возможную иронию со стороны оппонентов, еще раз подчеркну:
> это РЕАЛЬНЫЙ машинный код процессора, а не программа, которая
> компилируется и "распухает" в разы.
>

Вы обладаете бесценной инсайдерской информацией:
http://www.automation.siemens.com/WW/forum/guests/PostShow.aspx?PostID=41320&Language=en


С уважением,
Олег Алексеев.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   12.06.07 12:49

Олег, я не могу обладать ИНСАЙДЕРСКОЙ информацией, так как в Сименсе
никогда не работал :-).
У меня есть бесценная ЛИЧНАЯ информация, полученная собственными
руками и головой за несколько лет пуско-наладки АСУТП на базе S5. В
частности, эта информация касается недокументированных [для
пользователя] особенностей контроллера. Например, так
называемых "закрытых FB", которые используются для работы с модулями
IP ("интеллектуальной периферии") SIMATIC S5. Cсылка, которую Вы
привели, как раз по теме таких "закрытых FB". И я знаю ответ, который
интересует того парня (china man) ;-).

Да, разумеется, процессор S5 имеет свой язык Ассемблера, которым
пользуются разработчики в самом Сименсе при написании FB. Однако,
логические операции, про которые я написал пример, НЕ СВЯЗАНЫ с
вызовами FB. Еще раз повторяю: это МАШИННЫЙ код, непосредственно
исполняемый процессором.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re[3]: PC-совместимый контроллер vs PLC.
Автор: fox_biz@xxxxxxxx.xx 
Дата:   15.06.07 09:00

E> В Российских нормативах для АЭС нет понятия SIL, ПТК аттестуются по т.н.
E> классу безопасности. На сегодня максимально аттестованопо первому классу
E> 0, по второму классу всего 2 ПТК, , по третьему классу около 10-ти.
E> Процедура аттестации нудная и запутанная, требования непрозрачные (на мой
E> взгляд). Хотя собственно системы безопасности и не требуют для включения и
E> работы каких-либо ПТК. Когда в основу безопасности АЭС закладывается
E> понятие МПА (Максимальной Проектной Аварии) под МПА и рассчитываются все
E> системы безопасности и логика их работы. Считается, что если авария
E> запроектная, то и любое управление ничего не даст будь оно даже нулевого
E> класса безопасности (шутка).

E> С уважением, Катковский Е.А.

Интересно было бы узнать, кто же смог так отличиться, что попал в
список "всего 2 ПТК" и "около 10-ти"?
Насчет прозрачности - это всегда проблема при лицензировании и при
работе с линцензирующими органами.
Некоторые аспекты очень прозрачны - сейсмика, ЭМС, климатика.
А остальное - это ваша задача доказать РосТехНадзору что вы соответсвуете
всем нормативным документам, в которых критерии иногда ну ОЧЕНЬ УЖ
обобщенные. Конечно, иногда это неудобно, но и разработчику ПТК не
вяжет существенно руки.

С уважением, Наконечный С.В.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Serge 
Дата:   14.06.07 22:54

SS> К сожалению, я не могу считать Ваш ответ аргументированным.
SS> Не могли бы Вы привести ассемблерный (транслированный) код
SS> своего "изящного" решения?

ппр битовые операции привести готового решения не могу, но могу в качестве примера
привести поддержку mmx/sse команд в C/C++.

вот это C/C++ код (из реального проекта)
        *pDest = _mm_sub_ps(*pSrc1, *pSrc2);
        *pDest = _mm_mul_ps(*pDest, *pDest);
        *m3 = _mm_shuffle_ps(*pDest, *pDest, _MM_SHUFFLE_R(1, 0, 3, 2));
        *pDest = _mm_add_ps(*pDest, *m3);
        *m3 = _mm_shuffle_ps(*pDest, *pDest, _MM_SHUFFLE_R(2, 0, 0, 0));

а вот это ассемблерный листинг полученный после компиляции этого кода
        subps   xmm0, xmm1
        mulps   xmm0, xmm0
        movaps  xmm1, xmm0
        shufps  xmm1, xmm0, 177                         ; 000000b1H
        addps   xmm1, xmm0
        movaps  xmm0, xmm1
        shufps  xmm0, xmm1, 2

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


--
Best regards,
 Serge                            mailto:legar@xxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[3]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   15.06.07 11:38

>>Интересно было бы узнать, кто же смог так отличиться, что попал в
>>список "всего 2 ПТК" и "около 10-ти"?

Вы сможете обратиться за этой информацией в РосТехНадзор ( в бывш. ГАН).

>>Насчет прозрачности - это всегда проблема при лицензировании и при
>>работе с линцензирующими органами.

Процедура получения лицензии РТН (ГАН) на проектирование, конструирование и производство средств автоматизации для АЭС вполне адекватна и прозрачна, требования к соискателю четко изложены в нормативных документах РТН (ГАН). Специалисты РТН (ГАН) - высококвалифицированные и эрудированные люди!

>>Некоторые аспекты очень прозрачны - сейсмика, ЭМС, климатика.
>>А остальное - это ваша задача доказать РосТехНадзору что вы соответсвуете
>>всем нормативным документам, в которых критерии иногда ну ОЧЕНЬ УЖ
>>обобщенные. Конечно, иногда это неудобно, но и разработчику ПТК не
>>вяжет существенно руки.

Все критерии четко изложены в документе:
"Требования к управляющим системам, важным для безопасности АЭС", НП-026-04 от 05.01.2005 г.

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Дмитрий Чистяков 
Дата:   15.06.07 22:38

Даааа. Проходят годы, а тема не умирает. :-)
Десять лет уже скоро, как спор идёт.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Дмитрий Чистяков 
Дата:   17.06.07 00:04

Что касается популярности PC на рынке АСУ ТП, то озвученные цифры весьма завышены.
На выставке в Ганновере убеждаешься, что самые популярные контроллеры (по крайней мере в Европе) - это S7-300.
Т.к. на выставочных стендах "под столом" часто встречаются именно эти контроллеры. Это стенды фирм производителей различного оборудования от клапанов и датчиков, до приводов, гидравлики и пневматики.

Да и по своему предприятию скажу что статистика подтверждает малое использование PC систем в АСУ ТП. К тому же это всё системы уровня контрольно-измерительного. Да ещё у нас есть пара токарных станков Hercules с автоматизацией на основе PC.
Но эти системы в сравнение не идут с "основными" АСУ ТП агрегатов.

Стоимость равнозначных систем PC и PLC мы здесь тоже сравнивали. И она оказалась сравнима.

Дмитрий Чистяков
ОАО СеверСталь

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Гайдаш Д.М. 
Дата:   17.06.07 01:24

> Что касается популярности PC на рынке АСУ ТП, то озвученные цифры весьма
> завышены.

Это какие? :) Я озвучивал долю PC-based контроллеров на мировом рынке автоматизации - 2% :))) 98% - это PLC.

С уважением,
Гайдаш Дмитрий Михайлович
ЗАО "НПФ "Система-Сервис"

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   17.06.07 15:56

> Константин, Вы, наверное, будете смеяться, но предмет Вашей иронии -
>  "мудрёный процессор специально "заточенный" под языки МЭК" -
реально
> существует.
> Я не полагаю, а знаю, что в контроллерах SIEMENS до SIMATIC S5
> включительно использовался специализированный битовый процессор.
Или,
> если угодно, битовый СОпроцессор, который имел огромное (по тем
> временам) быстродействие при выполнении соответствующих операций. В
> определенном смысле он действительно был "заточен" именно под
языки
> МЭК, поскольку для большинства логических операций
> (например, "нормально открытый контакт" в KOP) команда вместе с
> адресом операнда умещались в 1 (одно) 16-битовое слово. Если Вы
> сможете аргументировано показать, что другой язык (не МЭК)
генерирует
> более компактный машинный код прикладной программы, я, как
> говорится, "съем свой галстук". Или сгрызу свою клавиатуру :-).
>
В то что инструкции языка AWL,STL,IL и машинные команды используемого
процессора одно и тоже, я, мягко говоря, не верю. Интересно было бы
узнать на чём основано Ваше знание.
Упомянутый здесь Infineon ни о каких AWL не знает. Даже если и
предположить что и имеется некий сопроцессор то для его эффективного
использования нужен некий интерфейс которого у Infineon нет.

> Извиняюсь, что говорю только про SIMATIC S5. Просто я с S7 не
> работал. Но на 90% уверен, что все вышесказанное применимо и к S7.

Извиняюсь, но я пока на 90% уверен что сказанное Вами по поводу
сопроцессора не применимо ни к S5 ни к S7. Буду рад если Вы развеете
моё заблуждение хоть какими нибудь подтверждениями существования
подобного сопроцессора.
Может будет интересно:
Сегодня взглянул собственными глазами что внутри у CPU318. Кроме
всего прочего обнаружил я там старый добрый Am386DX-40.
Производительность Am386DX-40 порядка 14 MIPS что соответствует 0,07
мкс для инструкции, что очень близко к заявленным 0,1 мкс для CPU318.
Как думаете это случайное совпадение или нет?

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   18.06.07 06:47

В среднем это 3-4 команды на операцию. При условии выполнения команды
за 0.5-1 такт(а для RISC это вполне обоснованное предположение) это
на много быстрее чем указанные здесь цифры. Кроме того, никакого
глубокого смысла в выполнении битовых операций кроме экономии памяти
я не вижу, по сути это обычная булева логика которая с байтовыми
операндами будет выполняться ещё быстрее.

> Причем данный код может иметь место только в СКОМПИЛИРОВАННОЙ
> программе, которая, к сожалению, лишает PLC возможностей
необходимого
> on-line сервиса. В ИНТЕРПРЕТИРУЕМОЙ программе код будет гораздо
> длиннее.

А какой сервис следует из того что программа интерпретируемая?

>Если Вы
> сможете аргументировано показать, что другой язык (не МЭК)
генерирует
> более компактный машинный код прикладной программы, я, как
> говорится, "съем свой галстук". Или сгрызу свою клавиатуру :-).

А что это докажет?
Мы же  говорим о производительности, а не о "изящьности" языка, тем
более в машинных кодах. Да и что сравнивать? Покажите мне
документацию хоть на один процессор с архитектурой "МЭК-совместимый"
тогда и сравним.

>
> > Если Вы не заметили, то кроме MIPS-ов я указал результаты теста
> > выполнений операций с плавающей точкой и результаты этого теста
> также
> > заставляют задуматься.
>
> Я заметил. Но не понял, о чем надо задуматься, глядя на приведенные
> Вами цифры. Поясните, пожалуйста, что Вас смущает.

Смущает то что это уже реальная производительность, а не
теоретическая как MIPS, кроме того я считаю что вычисления с
плавающей точкой более сложная задача чем любимые Вами битовые
операции и потому более показательная в плане сравнения
производительности, но даже и в этом случае разница колоссальная -
больше чем на порядок. Я такого, признаюсь, не ожидал.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Дмитрий Чистяков 
Дата:   18.06.07 10:24

>Автор: Гайдаш Д.М.
>Дата:   17.06.07 01:24

> Что касается популярности PC на рынке АСУ ТП, то озвученные цифры весьма
> завышены.

>Это какие? :) Я озвучивал долю PC-based контроллеров на мировом рынке автоматизации -> 2% :))) 98% - это PLC.

Звиняюсь, это я криво написал. :-)
За такое соотношение я и отдам свой голос. :-)

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Дмитрий Чистяков 
Дата:   18.06.07 10:27

Что касается кодов программы, то скажу, что трудно найти сейчас программиста на PC-совместимом контроллере, который пишет программы на ассемблере в кодах. Чаще всего это уже ООПы, которые "съедают" всё что можно и нельзя. ;-)

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   18.06.07 10:27

Уважаемый Serge,
Прошу прощения, но я Вас не понимаю. Насколько помню, я говорил об
аппаратной обработке БИТОВЫХ операций в контроллерах SIMATIC S5 и
кодировании ЭТИХ операций. Я высказал мнение, что ни один другой язык
(кроме семейства МЭК 1131) не может генерировать более компактный
машинный код битовых операций, чем это сделано в Симатике. На это Вы
возразили, что "На любом высокоуровневом языке задача решается за
раз". Мне показалось, что Вы беретесь продемонстрировать
свой "изящный способ" решения именно ЭТОЙ задачи ;-).

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

Красивый ход мысли! Тогда я продолжу: "любое транспортное средство
может летать по воздуху, если оно поддерживает такие операции" :-).

А если серьезно, то я как раз и говорил о том, что процессор Симатика
поддерживает битовые операции, а "писишный" процессор (x86) - нет.


С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC vs PLC.
Автор: Роман Седов 
Дата:   18.06.07 12:36

Здравствуйте Sergey,

Monday, June 18, 2007, 9:27:20 AM, Вы писали:


>  Красивый ход мысли! Тогда я продолжу: "любое транспортное средство
>  может летать по воздуху, если оно поддерживает такие операции" :-).
>
>  А если серьезно, то я как раз и говорил о том, что процессор Симатика
>  поддерживает битовые операции, а "писишный" процессор (x86) - нет.

 Вообще странно, люди столько времени потратили на увеличение разрядности процессоров,
 а тут, получается, нужно вернуться к однобитным процессорам. Даже первый процессор Интел был уже четрех битным.
 Ведь если процессор, например, 16-разрядный, ну он просто не может работать с операндами отличными от 16 бит.
 Да, при обращении к флагам, действительно идет работа с битами, но с предустановленными! В этом, наверно, любой
 современный процессор поддерживает прямые битовые операции.

Далее, о чем вообще спор?

----cut-----
За последнее десятилетие типовые наборы команд ЭВМ общего назначения в значительной степени стандартизовались.
Тем более интересной оказалась тенденция к битовой машине в архитектуре микропроцессоров (МП) фирмы Intel .
Началом было появление во внутреннем ОЗУ ОЭВМ Intel 8051 6 (советский аналог КР1816ВЕ31) так называемой области
флагов (адреса 20 H ...2 FH ) объёмом в 128 бит, адресуемой как в байтовом, так и битовом режимах (табл. 1).
Кроме того, в этом МП имеется битовая адресация внутренних портов ввода-вывода и аккумулятора (биты 80 H -0 FFH ).

Наиболее радикальный шаг на пути к битовой ЭВМ  введение битовой адресации в МП 803867 (табл. 2).
Битовые строки в этом МП могут размещаться в памяти или в 16/32-разрядных регистрах общего назначения (РОН).
Значение смещения бита в строке начинается с нуля и соответствует размеру адресуемого операнда. Если операнд
находится в регистре, то смещение не должно превышать 15 или 31 бит в соответствии с разрядностью регистра.
Если битовая строка размещается в памяти, то смещение будет в диапазоне от -2 до +2 гигабит. Искомый бит (или биты)
в строке адресуется с помощью аппаратного пересчёта смещения в номер байта от начала строки (<смещение> DIV 8) и
номера адресуемого бита в этом байте (<смещение> MOD 8).

Команды, приведенные в табл. 2 и 3, (тут уже ссылка на мотороловские
процы)   это базовые операции, из которых на уровне подпрограмм можно построить
более сложные процедуры над битовыми строками. Между типами данных, поддержанных аппаратными средствами и
реализуемых в языках программирования высокого уровня (ЯВУ), существует глубокая двусторонняя связь.
Логические данные (типы Logical или Boolean) в некоторых ЯВУ представлены в памяти одним, а иногда даже и
двумя байтами, что делает работу с ними неэффективной и не совсем прозрачной.

---cut---

Источник (http://www.computer-museum.ru/technlgy/bit_comp.htm  )

Но все равно, предоставляя такой расширенный набор битовых команд, на
машинном уровне будет идти работа с полноценым 16 разрядным словом,
если машина 16 разрядная.

Осталось только выбрать, какой же процессор симатика, а какой -
"писишный".

Один товарищ, не смог к сожалению найти пост, ранее писал пример на Си
и на асме под указанные команды, но его, как я увидел, не поняли. Ну
вот нет в стандартном Си поддержки этих команд. Скорее всего они есть
в Симатике (во всяком случае очень похоже). Но при чем тут железо?


С Уважением,
 Роман Седов

инженер-программист
ООО Фирма "Калининградгазприборавтоматика"

mailto:R.Sedov@xxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   18.06.07 15:59

На сименсовском Руководстве по программированию.
Там приведена подробная информация, включая машинные коды и время
исполнения каждой команды. Конечно, если Maschinenсode - это то, о
чем я думаю ;-).
Также можно почитать на русском языке книгу "Программирование
функциональных блоков на языке STEP 5" и посмотреть, какие команды
есть в составе языка AWL для S5. (Скачать можно отсюда:
http://www.automation-drives.ru/as/products/doc.php?l1=Архив%20старых%
20продуктов&l2=STEP5&l3=doc)

А еще есть личный опыт.
SIMATIC S5 содержит "закрытые" функциональные блоки. Если Вы такой
блок откроете в редакторе KOP/FUP/AWL, то увидите следующее (если мне
память не изменяет):
SPA M001
BE
То есть, безусловный переход на какую-то метку и "конец блока". (Я
опустил раздел объявления параметров).
Если Вы сумеете такой "закрытый" блок превратить в "открытый", то
далее (после двух вышеуказанных команд языка AWL) увидите самый
натуральный ассемблер. Причем в этой ассемблерной программе
употребляются и стандартные (документированные) команды языка AWL, и
чисто ассемблерные команды, которые НЕ описаны в руководстве по языку
AWL. Я этот код видел своими глазами :-). На основании этого я делаю
вывод, что язык AWL является подмножеством языка Ассемблера
процессора S5.


> Упомянутый здесь Infineon ни о каких AWL не знает.

Ясный перец. Контроллер SIMATIC S5 появился примерно в 1983-84 году.
Т.е. за 12 лет до появления компании Infineon :-).


> Извиняюсь, но я пока на 90% уверен что сказанное Вами по поводу
> сопроцессора не применимо ни к S5 ни к S7. Буду рад если Вы
развеете
> моё заблуждение хоть какими нибудь подтверждениями существования
> подобного сопроцессора.

Руководство по программированию. См. выше ссылку на страницу для
загрузки.


> Может будет интересно:
> Сегодня взглянул собственными глазами что внутри у CPU318. Кроме
> всего прочего обнаружил я там старый добрый Am386DX-40.
> Производительность Am386DX-40 порядка 14 MIPS что соответствует
0,07
> мкс для инструкции, что очень близко к заявленным 0,1 мкс для
CPU318.
> Как думаете это случайное совпадение или нет?

Думаю, случайное совпадение, потому что наличие там Am386DX-40 не
говорит об отсутствии там других микропроцессоров. Вы не видели там
случайно микросхем с OEM-маркировкой? Например, c двумя-тремя
цветными точками? Или с 3-4-значным номером, которого не найти ни в
одном каталоге микросхем? Возможно, Am386DX-40 используется в
качестве коммуникационного процессора.


С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   18.06.07 18:02

> В среднем это 3-4 команды на операцию.

У меня, к сожалению, получилось не 3-4, а 12 ассемблерных команд.
Если предположить, что один операнд был в регистре, и результат тоже
остается в регистре (как у Симатика), то у меня будет 10 команд.
Видимо, Вы гораздо лучше меня знаете ассемблер. Поэтому очень
хотелось бы увидеть Ваш код (те самые 3-4 команды) с такой же
функциональностью.


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

Согласен с Вами ровно наполовину.

Между прочим, про семейство Infineon C166  написано: Enhanced Boolean
Bit Manipulation Facilities. Вам не кажется, что это тот самый
БИТОВЫЙ СОПРОЦЕССОР, интегрированный в один чип с универсальным
процессором?


> А какой сервис следует из того что программа интерпретируемая?

В случае интерпретируемой программы можно организовать изменение
программы on-line, т.е. без останова контроллера и управляемого
процесса. Как это сделать в скомпилированной программе - я не знаю.
Если у Вас есть пример такого on-line сервиса, реализованного в
случае скомпилированной программы, расскажите, пожалуйста.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   18.06.07 19:30

> У меня, к сожалению, получилось не 3-4, а 12 ассемблерных команд.

Вы же сами приводили решение этой задачи на языке AWL, если не
ошибаюсь там было три команды - отсюда и 12/3 = 4. То же самое
получается и на STL(только мнемоники другие) полагаю что на IL будет
подобное. По крайней мере, команды, которая выполняет зараз описанную
Вами задачу в теперешнем "ассемблере" S7 я не знаю.

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

Было бы интересно узнать Ваше мнение в более развёрнутом виде.

> Между прочим, про семейство Infineon C166  написано: Enhanced
Boolean
> Bit Manipulation Facilities. Вам не кажется, что это тот самый
> БИТОВЫЙ СОПРОЦЕССОР, интегрированный в один чип с универсальным
> процессором?

Незнаю.
Надо посмотреть более внимательно.

>
>
> > А какой сервис следует из того что программа интерпретируемая?
>
> В случае интерпретируемой программы можно организовать изменение
> программы on-line, т.е. без останова контроллера и управляемого
> процесса. Как это сделать в скомпилированной программе - я не знаю.
> Если у Вас есть пример такого on-line сервиса, реализованного в
> случае скомпилированной программы, расскажите, пожалуйста.

Пожалуй, нет.


С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Privodchik 
Дата:   18.06.07 21:08

Надеюсь не обижу данный ресурс если сообщу прямо сюда ссылку на сайт инженеров автоматизации и приводчиков http://ingener.info где мы оказываем друг другу помощь и делимся опытом. Мы готовы автоматизировать все что угодно, лишь бы это было кому-нибудь нужно и интересно. Сайт объединяет приводчиков, программистов, ЧПУшников (системщиков), знатоков контроллеров и переферии, а токже спецов робототехники, гидропривода, электроники и электрике. Если кого0то забвл, не обижайтесь пожалуйста, наша специфика только кажется узкой, на самом деле она захватывает очень широкий круг специалистов и сфер деятельности.
Заходите на форум, общайтесь, читайте статьи и новости, качайте архивы с документацией - у нас все для всех.
P.S. Спешите, время, когда роботы делают роботов (предел автоматизации) достигнуто!

Все о ПЛК (PLC) ЧПУ регуляторах и приводах
Помощь инженеров автоматизации и электроников по контроллерам и числовому программному управлению
http://ingener.info

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   18.06.07 21:25

> На сименсовском Руководстве по программированию.
> Там приведена подробная информация, включая машинные коды и время
> исполнения каждой команды. Конечно, если Maschinenсode - это то, о
> чем я думаю ;-).
> Также можно почитать на русском языке книгу "Программирование
> функциональных блоков на языке STEP 5" и посмотреть, какие команды
> есть в составе языка AWL для S5. (Скачать можно отсюда:
> http://www.automation-drives.ru/as/products/doc.php?l1=Архив%
20старых%
> 20продуктов&l2=STEP5&l3=doc)

Ну так они и PLC свои называют не иначе как CPU, поэтому не удивлюсь
если и Maschineсode это действительно не то о чем Вы думаете.
Я частенько посматриваю документацию на S7, если на S5 в том же стиле
тогда даже и смотреть не буду. Мне бы хотелось увидеть описание на
микропроцессор в стиле даташитов к тому же интелу или инфинеону.


> > Упомянутый здесь Infineon ни о каких AWL не знает.
>
> Ясный перец. Контроллер SIMATIC S5 появился примерно в 1983-84
году.
> Т.е. за 12 лет до появления компании Infineon :-).

На сколько мне известно Infineon это отделившаяся от Сименса группа
которая как раз и занималась разработкой процессоров. Так почему у
них в линейке процессорных ядер нет процессора с AWL подобной
системой команд. Опять же если в составе Сименса больше нет
разработчиков процессорных ядер тогда откуда им взяться(ядрам в
смысле)?


> Думаю, случайное совпадение, потому что наличие там Am386DX-40 не
> говорит об отсутствии там других микропроцессоров. Вы не видели там
> случайно микросхем с OEM-маркировкой? Например, c двумя-тремя
> цветными точками? Или с 3-4-значным номером, которого не найти ни в
> одном каталоге микросхем? Возможно, Am386DX-40 используется в
> качестве коммуникационного процессора.

Видел, и, конечно же, не случайно.:-)
Цельных 3 в BGA корпусах.
На одной из них гордо красуется Siemens SPS(на сколько мне известно
немецкое SPS это английское PLC).
Может это и действительно мэк-совместимый микропроцессор.
Но тогда получается что программа отнюдь не интерпретируемая, а,
наоборот - компилируемая, поскольку получается программа в реальных
машинных кодах микропроцессора.

С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   18.06.07 21:32

Прошу прощения. Я Вас неправильно понял и почему-то решил, что Вы
под "операцией" имеете в виду весь кусок кода, который у меня занял
12 команд на ассемблере :-).


> > > ...Кроме того, никакого
> > > глубокого смысла в выполнении битовых операций кроме экономии
> > памяти
> > > я не вижу, по сути это обычная булева логика которая с
байтовыми
> > > операндами будет выполняться ещё быстрее.
> >
> > Согласен с Вами ровно наполовину.
> >
>
> Было бы интересно узнать Ваше мнение в более развёрнутом виде.

Память нынче стоит недорого. Это хорошо. Но в PLC, как правило,
используется не совсем обычная и совсем не дешевая память. И
требования к ней иногда взаимно-противоречивые: с одной стороны,
хорошо бы побольше и побыстрее, а с другой - необходима экономичность
(т.к. backup на батарейке) и надежность (а она зависит от объема).
Поэтому, IMHO, не так очевидно, что окажется более эффективным:
битовый процессор + немного дорогой и качественной памяти, либо
универсальный процессор + много дешевой памяти.

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-УПЧНЕУФЙНЩК ЛПОФТПММЕТ vs PLC.
Автор: Mikhail Komarov 
Дата:   19.06.07 10:16

Здравствуйте, Sergey.

Вы писали 18 июня 2007 г., 18:02:06:

SS> В случае интерпретируемой программы можно организовать изменение
SS> программы on-line, т.е. без останова контроллера и управляемого
SS> процесса. Как это сделать в скомпилированной программе - я не знаю.
SS> Если у Вас есть пример такого on-line сервиса, реализованного в
SS> случае скомпилированной программы, расскажите, пожалуйста.

Такой сервис имеет большинство CoDeSys-контроллеров, т.е. со средой
разработки и средой выполнения от 3S-software.

Online-сервис предлагает:
- изменение программы online;
- наблюдение значений переменных во время выполнения программы;
- осциллографирование быстрых изменений;
- средства отладки (точки останова, выполнение покомандно, по одному
циклу);
- мониторинг загрузки процессора;

и наверное еще что-то забыл.


--
С уважением, Михаил Комаров mkomarov@xxxxxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   19.06.07 17:02

Здравствуйте, Михаил.

Читал описание на их сайте. По поводу изменений он-лайн написано как-
то очень неконкретно.
Цитата:
Изменения в режиме он-лайн
Эта функция позволяет вносить определенные изменения в программу без
остановки работы контроллера. Например, если нужно изменить отдельные
POU , переменные или типы данных.


А еще на странице http://www.3s-software.com/index.shtml?
News&news=atp_int_neufeld лежит описание процедуры тестирования
производительности контроллера с CoDeSys. В той же статье приведен
отчет с конкретными данными. Тестировался контроллер (или процессор?)
PowerPC MPC5200, 396 МГц. Для операций с данными типа BOOLEAN
(видимо, байтового формата) получен такой результат: 10 000 операций
(AND/OR) за 1325 мкс. Если я не напутал с математикой, то это 0,1325
мкс на операцию. Как насчет сравнения с Симатиком S7-300? Тем самым,
который из процессора 386DX40 (по слухам) выжимает 0,1 мкс на
операцию? :-)))))

Хочу спросить Константина Власкина: Константин, на какие размышления
наводит Вас производительность этого RISC процессора в РЕАЛЬНОМ
приложении, на КОМПИЛИРОВАННОЙ программе? Сколько там у него MIPS
должно быть, при 396 МГц ;-))  ?

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Виктор 
Дата:   20.06.07 00:58

>Тестировался контроллер (или процессор?)
>PowerPC MPC5200, 396 МГц. Для операций с данными типа BOOLEAN
>(видимо, байтового формата) получен такой результат: 10 000 операций
>(AND/OR) за 1325 мкс. Если я не напутал с математикой, то это 0,1325
>мкс на операцию. Как насчет сравнения с Симатиком S7-300? Тем самым,
>который из процессора 386DX40 (по слухам) выжимает 0,1 мкс на
>операцию? :-)))))

Тест проводили на EvalBoard под этот процессор, CoDeSys работал под ОС Linux. Вот из-за него, Linux'а, такой результат и получился. На "чистом" процессоре все было бы совсем иначе. В Симатике своя ОС (или ее подобие), "заточенная" для исполнения определенных задач, накладных расходов там минимум или вообще 0.
Рассматривать производительность железа и софта отдельно друг от друга не очень корректно, по моему. Плохой софт загубит самое распрекрасное железо. Линукс не приспособлен для решения таких задач, у него большие накладные расходы, которые и тормозят работу исполнительной системы CoDeSys (или любой другой).
Результаты работы под WinCE и OS9 уже другие (особенно для OS9 - 5 нс на операцию):
http://www.3s-software.com/se_data/_filebank/Prolog/sp_pps_ru.pdf
Инфинеоновский SAB80С167 (почти Intel 80186 с небольшими изменениями-дополнениями) на 20 МГц и то дает 0,57 мкс на операцию при работе без ОС.
АРМ на 160 МГц под WinCE дает 11 нс на инструкцию...
Ссылка на все тесты: http://www.3s-software..com/index.shtml?ru_Datenbltter

Виктор Прилипко,
ОАО "ИНЭУМ"

[Non-text portions of this message have been removed]

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   20.06.07 13:00

MIPS-ов там 760.
А что касается результатов то я думаю дело может быть в том числе и в
том что:

Due to the unavailability of standardized test procedures for
comparing different programmable logic controllers
(PLCs), such comparisons, especially as concerns performance, were
quite difficult in the past.



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

Кстати, по поводу:

"Enhanced Boolean Bit Manipulation Facilities"
Как я понял речь не о сопроцессоре, а вот о чём:
Enhanced boolean bit manipulation with direct addressability of 4
Kbits for peripheral control and user defined flags.
Возможно, что раньше было только 1 или 2 Kbits или и того меньше.



С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-УПЧНЕУФЙНЩК ЛПОФТПММЕТ vs PLC.
Автор: Mikhail Komarov 
Дата:   20.06.07 14:10

Здравствуйте, Sergey.

Вы писали 19 июня 2007 г., 17:02:31:

SS> Читал описание на их сайте. По поводу изменений он-лайн написано как-
SS> то очень неконкретно.
SS> Цитата:
SS> Изменения в режиме он-лайн
SS> Эта функция позволяет вносить определенные изменения в программу без
SS> остановки работы контроллера. Например, если нужно изменить отдельные
SS> POU , переменные или типы данных.
Имеется в виду, что нет возможности внести изменения в конфигурацию
оборудования (добавить/удалить модули), нельзя изменить структуру
задач (изменить время цикла, добавить/удалить задачу, изменить
приоритеты задач).
Но можно удалить/добавить/изменить программы, функции, функциональные
блоки, переменные, типы данных.

SS> А еще на странице http://www.3s-software.com/index.shtml?
SS> News&news=atp_int_neufeld лежит описание процедуры тестирования
SS> производительности контроллера с CoDeSys. В той же статье приведен
SS> отчет с конкретными данными. Тестировался контроллер (или процессор?)
SS> PowerPC MPC5200, 396 МГц. Для операций с данными типа BOOLEAN
SS> (видимо, байтового формата) получен такой результат: 10 000 операций
SS> (AND/OR) за 1325 мкс. Если я не напутал с математикой, то это 0,1325
SS> мкс на операцию. Как насчет сравнения с Симатиком S7-300? Тем самым,
SS> который из процессора 386DX40 (по слухам) выжимает 0,1 мкс на
SS> операцию? :-)))))
Приведу данные по контроллерам ABB AC500.
Тестов сам не делал, маркировку чипов не смотрел, но платформа
контроллеров - PowerPC. Есть три варианта производительности:
Время выполнения 1000 инструкций, мс:
Тип инстукций           PM571    PM581    PM591
Битовые                 0,3      0,15     0,05
Целочисленные 16 бит    0,3      0,15     0,05
С плавающей точкой      6        3        0,5

И вот еще, PM581 c Ethernet ест 80mA 24VDC.

--
С уважением, Михаил Комаров mkomarov@xxxxxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[9]: PC-совместимый контроллер vs PLC.
Автор: Constantin 
Дата:   20.06.07 17:35

Не дочитал еще до конца ветку, но уже спешу выразить мой респект господину zyubin'у. А господину Гайдашу могу сказать, чтобы он не зарывался, и желаю, чтобы он вовремя встал на путь истинный.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[13]: PC-совместимый контроллер vs PLC.
Автор: Constantin 
Дата:   20.06.07 18:03

Что же вы их выгоняете. Очень интересная дискуссия! Из нее можно извлечь полезные выводы.

Я для себя вывел следующее:

Существует 2 типа разработчиков АСУ ТП. Первый – те, которые не парятся по жизни о внутренностях контроллеров, их программировании (не на МЭК311), интеграции в систему АСУ ТП сторонних приборов, панелей и т.д., люди, которым не нужна суть системы. Главное это заплатил – получил. Быстро и работает. Если что, сошлюсь на производителя. Есть же люди, которые не боятся задач оптимизации системы при помощи различных её вариаций, подбором различного оборудования, программировании контроллеров на Си (естественно, когда это действительно нужно).

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

Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[13]: PC-совместимый контроллер vs PLC.
Автор: Eugeen 
Дата:   20.06.07 18:45

Вспоминаю Сталинское, пройденное: "Лошадь - кулацкое животное - должна вымереть!
Все кто не "под Сименсом" = Лошадь!
Это был Социализм по Сименсу!
Теперь наступает "рыночная (Базарная!) экономика.
Вопрос: Что делать с Лошадью?

С уважением, Катковский Е.А.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-УПЧНЕУФЙНЩК ЛПОФТПММЕТ vs PLC.
Автор: Serge 
Дата:   22.06.07 01:18

SS>  А если серьезно, то я как раз и говорил о том, что процессор Симатика
SS>  поддерживает битовые операции, а "писишный" процессор (x86) - нет.

Если серьезно, то утверждали Вы совсем другое, а именно что "ни один другой язык
 (кроме семейства МЭК 1131) не может генерировать более компактный
  машинный код битовых операций"

Покажите, пожалуйста, в этой фразе хоть намек на процессор Симатек.

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


--
Best regards,
 Serge                            mailto:legar@xxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Sergey Shchekin 
Дата:   23.06.07 16:07

OK. Если Вы хотите поспорить на тему отдельной фразы, вырванной из
контекста - нет проблем, продолжим.

Но считаю необходимым уточнить формулировку. В моем письме, из
которого взята эта цитата, говорилось о реально существующем
контроллере SIMATIC S5 и его машинном коде прикладной программы для
АСУТП. Признаюсь, я привел там неверную информацию об объеме: битовая
операция в машинном коде Симатика занимает не одно, а два слова (т.е.
не 2, а 4 байта). Память меня подвела, т.к. я уже 12 лет не работал с
Симатиком :-(. Приношу всем свои извинения.

Итак, повторяю уточненную формулировку: среди практически
существующих языков программирования реально существующего
оборудования ни один другой язык (кроме семейства МЭК 1131) не может
генерировать более компактный (<4 байт/оп) машинный код битовых
операций прикладной программы АСУТП.

Serge, если Вы по-прежнему считаете, что моё утверждение ошибочно,
пожалуйста, приведите свой пример машинного (или ассемблерного) кода
битовой операции и укажите оборудование, на котором работает этот код.


> Покажите, пожалуйста, в этой фразе хоть намек на процессор Симатек.

Serge, наверное, Вы хотели написать "Симатик"?
Если так, то весь абзац, из которого Вы взяли мою фразу, посвящен
контроллерам SIMATIC S5.


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

Смелое заявление :-).
"Огласите весь список, пжалста..." (Операция "Ы")

С уважением,
Сергей Щекин
GUTOR Electronic ltd.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   24.06.07 12:14

> Но считаю необходимым уточнить формулировку. В моем письме, из
> которого взята эта цитата, говорилось о реально существующем
> контроллере SIMATIC S5 и его машинном коде прикладной программы для
> АСУТП. Признаюсь, я привел там неверную информацию об объеме:
битовая
> операция в машинном коде Симатика занимает не одно, а два слова
(т.е.
> не 2, а 4 байта). Память меня подвела, т.к. я уже 12 лет не работал
с
> Симатиком :-(. Приношу всем свои извинения.
>
> Итак, повторяю уточненную формулировку: среди практически
> существующих языков программирования реально существующего
> оборудования ни один другой язык (кроме семейства МЭК 1131) не
может
> генерировать более компактный (<4 байт/оп) машинный код битовых
> операций прикладной программы АСУТП.

К примеру тот же инфинеон такие команды имеет. И занимают они как раз
4 байта. Например команда BAND op1, op2 выполняет операцию
логического И с битами op1 и op2, результат помещается в op1.
Полагаю, что инфинеон в наборе этих команд не оригинален и вполне мог
их позаимствовать у того же интеловского MCS51 семейства.
Что касается машинных команд то вопрос что внутри симатика как S5 так
и S7 до сих пор остаётся  открытым. Ваш аргумент с кодами MC5 не могу
считать убедительным. Программа на Яве тоже состоит из набора
низкоуровневых команд виртуального процессора, но это не говорит о
том что процессор имеет этот набором инструкций. Опять же S7 тоже
имеет свой набор "машинных" команд MC7, но, тем не менее, внутри этих
контроллеров предположительно стоят процессоры таких команд не
имеющие, например, тот же 315-й.



С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-УПЧНЕУФЙНЩК ЛПОФТПММЕТ vs PLC.
Автор: Serge 
Дата:   25.06.07 13:09

SS>  Итак, повторяю уточненную формулировку: среди практически
SS>  существующих языков программирования реально существующего
SS>  оборудования ни один другой язык (кроме семейства МЭК 1131) не может
SS>  генерировать более компактный (<4 байт/оп) машинный код битовых
SS>  операций прикладной программы АСУТП.

mov al, p
and al, r
mov s, al

и что самое интересное такое решение всех устроит.


SS>  Смелое заявление :-).
SS>  "Огласите весь список, пжалста..." (Операция "Ы")

т.е. хотите сказать, что под Симатик не разрабатывают высокоуровневые языки?
т.е. Симатик это такой "неуловимый Джо", который нафиг никому не нужен, кроме людей,
которые знают только МЭК?


--
Best regards,
 Serge                            mailto:legar@xxxx.xx

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Alex G. Zentner 
Дата:   18.06.07 22:19

>На одной из них гордо красуется Siemens SPS(на сколько мне известно
>немецкое SPS это >английское PLC).
Не совсем в тему, но ИМХО немецкое SPS это аналог нашего АСУ (агл. DCS).
Во всяком случае в немецких проскпектах под SPS они подразумевают глобальную
систему CPU+DI+DO+переферия+т.д.

Всего хорошего!
Центнер Алексей.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re: PC-совместимый контроллер vs PLC.
Автор: Valery Bobekh 
Дата:   28.06.07 18:05

> Не совсем в тему, но ИМХО немецкое SPS это аналог нашего АСУ (агл. DCS).
> Во всяком случае в немецких проскпектах под SPS они подразумевают глобальную
> систему CPU+DI+DO+переферия+т.д.

SPS (speicherprogrammierbare Steuerung) = PLC

100%

Бобех В.И.

ИНЕОС, Германия

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kavlaskin 
Дата:   30.06.07 15:05

> Не совсем в тему, но ИМХО немецкое SPS это аналог нашего АСУ (агл.
DCS).
> Во всяком случае в немецких проскпектах под SPS они подразумевают
глобальную
> систему CPU+DI+DO+переферия+т.д.

По данным Lingvo:
SpeicherProgrammierbare Steuerung программируемый контроллер

Вот одна из многих ссылок на немецкий ресурс
http://www.wikischool.de/wiki/Speicherprogrammierbare_Steuerung



С Уважением
Константин Власкин

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: kozin_ae 
Дата:   11.10.11 16:03

Минуло 4 с лишком года. Лежит куча сломанных копий.... И где тот бурно обсуждаемый язык Рефлекс? Ау, кто нибудь знает? А то может я чего-то упустил....

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Зоркальцев А.А. 
Дата:   11.10.11 17:02

Здравствуйте Александр,

>>Минуло 4 с лишком года. Лежит куча сломанных копий....
>>И где тот бурно обсуждаемый язык Рефлекс?
>>Ау, кто нибудь знает? А то может я чего-то упустил....
Вопрос как-то задан некорректно, не располагая к обсуждению.

Было бы интересно услышать о развитии стандартов для PLC (IEC 61131-3),
DCS (IEC 61499) и альтернативных решениях как в теории, стандартах так и в
конкретном оборудовании.

Вот тут к теме IEC 61499 и IEC 61870-5.  Вроде у ISaGRAF есть в версии 5 и
6. Кто-нибудь уже пробовал в энергетике, для каких задач и на какой
платформе ?


 ---
 С уважением,
 Зоркальцев Александр
 ООО ЭлеТим, г. Томск.

Адрес этого сообщения    Ответить на это сообщение
 
 RE: PC-совместимый контроллер vs PLC.
Автор: Ivan Zhukov 
Дата:   11.10.11 18:43


Как модератор, предлагаю создать для этого отдельную тему, а в этой
очень большой и старой ничего не писать. Зря её подняли. В подобных случаях
лучше создавать новую тему-продолжение, а на старую давать только ссылку
в новой теме.


Зоркальцев А.А. писал(а):

> Здравствуйте Александр,
>
> >>Минуло 4 с лишком года. Лежит куча сломанных копий....
> >>И где тот бурно обсуждаемый язык Рефлекс?
> >>Ау, кто нибудь знает? А то может я чего-то упустил....
> Вопрос как-то задан некорректно, не располагая к обсуждению.
>
> Было бы интересно услышать о развитии стандартов для PLC (IEC 61131-3),
> DCS (IEC 61499) и альтернативных решениях как в теории, стандартах так и в
> конкретном оборудовании.
>
> Вот тут к теме IEC 61499 и IEC 61870-5.  Вроде у ISaGRAF есть в версии 5 и
> 6. Кто-нибудь уже пробовал в энергетике, для каких задач и на какой
> платформе ?
>
>
>  ---
>  С уважением,
>  Зоркальцев Александр
>  ООО ЭлеТим, г. Томск.

Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[7]: PC-совместимый контроллер vs PLC.
Автор: Александр Кузнецов 
Дата:   20.10.11 07:38

>Предлагаю нарассмотрение блок управления краном, который имеет сл. интерфейс (копирую из исходника):

>VAR_INPUT
>  onCom      : BOOL; // команда открытия от алгоритма
>  offCom     : BOOL; // команда закрытия от алгоритма
>  onSig      : BOOL; // сигнал (конечник) открытия крана
>  offSig     : BOOL; // сигнал (конечник) закрытия крана
>  onBtn      : BOOL; // кнопка открытия крана
>  offBtn     : BOOL; // кнопка закрытия крана

и так далее

Нагло залезу с критикой :)

Зачем измерять время REAL`ом?

Кроме того, скомпилированный исходник пусть и занимает около килобайта, но в том же симатике вызов каждого экземпляра этого FB сожрет еще байт 600-700.

WBR, Alex

Адрес этого сообщения    Ответить на это сообщение
 
 Re: PC-совместимый контроллер vs PLC.
Автор: Алексей Дмитриев 
Дата:   27.10.11 14:00

Читал, читал - так ни черта и не понял. PC-совместимые контроллеры с точки зрения конечного юзера ничем от обычных не отличаются, но это только если Вам не нужны специфические функции операционной системы, например Windows или MS-DOS.
Например Вы умеете программить на Step-7, ничто не помешает вам установить на обычный IBM-PC Soft PLC WinLC и спокойно программировать это (а что это такое вообще?) на том-же STEP 7. Есть другие программные средства, например CoDeSys Runtime для PC или IsaGraf - ну это из широко известных.
А вообще это сильно облегчает разработчику жизнь, например FESTO долгое время выпускала свой PS1 Professional, железяка ничто иное как IBM PC AT с промышленным конструктивом и развитым вводом/выводом. Продавался с системами программирования FST - классический фестовский софт со времен царя гороха, то есть юзер, умеющий программировать на FST405 мог спокойно продолжать тоже самое и на новой платформе, а также с MultiProg или вообще голый просто с MS-DOS, ну это для особо одаренных любителей программить системы управления на языках, которые для этого не предназначены, типа С или Паскаля.
Резюме - PC - совместимый контроллер это только архитектура железа и ОС. Если юзер не хочет об этом знать, он и не узнает никогда.

Адрес этого сообщения    Ответить на это сообщение
 Список форумов    


 Список форумов  |  Нужен логин? Регистрируйтесь здесь 
 Логин пользователя
 Имя пользователя:
 Пароль:
 Помнить пароль:
   
 Забыли ваш пароль?
Введите имя пользователя или e-mail, и новый пароль будет послан на email, указанный в вашем профиле.

Рейтинг@Mail.ru