PLC для освоения

[Ryzhij]

Самая доступная статья об особенностях PAC из тех, что мне попадались:
https://www.opto22.com/documents/1634_P ... _Paper.pdf - оригинал
http://opto22.ru/inform_page/prim.php - перевод
http://opto22.ru/downloads/1634_1_8_ru.doc - перевод

[san]

Насколько я понимаю, термин PAC является недостаточно устоявшимся, и каждый производитель трактует его так, как ему удобнее. Это вам не наука, где за использование неправильной терминологии могут побить канделябрами, а "сурьезный бизнес" :D

+1

[Ryzhij]

Насколько я понимаю, термин PAC является недостаточно устоявшимся, и каждый производитель трактует его так, как ему удобнее. Это вам не наука, где за использование неправильной терминологии могут побить канделябрами, а "сурьезный бизнес" :D

В статье по приведённой ранее ссылке указывается на авторство термина PAC - ARC Advisory Group - http://www.arcweb.com
Сама ARC утверждает, что:

[+] ARC Clients

ARC Clients
ARC serves many Fortune 1000 companies. Our clients include 3M, BASF, Oracle, SAP, Microsoft, ABB, DuPont, Siemens, ExxonMobil, Dow Chemical, Eli Lilly, Emerson, Invensys, Nestlé, Yokogawa, Rockwell Automation, Saudi Aramco, Schneider Electric, and IBM

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

[VADR]

Ага, а удалил статью (судя по информации отсюда: http://en.wikipedia.org/wiki/Programmab ... controller) человек, который очень много знает об АСУТП (http://en.wikipedia.org/wiki/User:Crisco_1492):

I am a Canadian student, who is currently studying Indonesian literature in Yogyakarta, Indonesia.

[embedd]

Самая доступная статья об особенностях PAC из тех, что мне попадались:
https://www.opto22.com/documents/1634_P ... _Paper.pdf - оригинал
http://opto22.ru/inform_page/prim.php - перевод
http://opto22.ru/downloads/1634_1_8_ru.doc - перевод

судя по статье пытаются применить PAC вместо PLC

[Ryzhij]

судя по статье пытаются применить PAC вместо PLC

Я бы выразился иначе: многие желают приобрести PAC по цене PLC
Да, я бы и сам не прочь, но...

[Daes]

судя по статье пытаются применить PAC вместо PLC

Я бы выразился иначе: многие желают приобрести PAC по цене PLC Да, я бы и сам не прочь, но...

чуть выше была речь о неприменении для управления (в конце цитаты), или вы хотите PAC для других целей ?

ICP DAS называет данный класс устройств PAC - Programmable Automation Controller. "Из коробки" его можно использовать в качестве конвертера интерфейсов/протоколов. Есть готовые программы, реализующие сервер последовательного порта и Modbus gateway, сравнительно просто можно реализовать свои задачи подобного рода. Дополнительная фича - шина, открытая для создания на ее основе собственных устройств. Фактически, такой PAC - микроконтроллер "для ленивых". Есть RS-232, RS-485, Ethernet, (недо)ОС, библиотеки... В такой ипостаси 7188ex использовались у нас в достаточно специфической системе сбора весовой информации.

Есть модификация 7188 с таргетом ISaGRAF, т.е. фактически PLC на том же железе. Такие устройства для сбора информации мы используем достаточно широко, но для управления технологическими процессами не применяем.

[Ryzhij]

Упомянутое железо от ICP DAS я бы для целей DCS тоже применять по-остерёгся, только для DAQ.
Но вот ControlLogix от RockwellAutomation, который тоже позиционируется как PAC, мы применяем широко.
/Никакой рекламы, просто факт/

[Daes]

Упомянутое железо от ICP DAS я бы для целей DCS тоже применять по-остерёгся, только для DAQ.
Но вот ControlLogix от RockwellAutomation, который тоже позиционируется как PAC, мы применяем широко.
/Никакой рекламы, просто факт/

увы, я теряюсь в различиях между PAC и PLC

[Михайло]

Я для себя просто понимаю: если у PLC операционная система открытая (типа WinCE, Linux), то это PAC. Больше никаких критериев не рассматривается. Это сугубо мое мнение.

[Daes]

Я для себя просто понимаю: если у PLC операционная система открытая (типа WinCE, Linux), то это PAC. Больше никаких критериев не рассматривается. Это сугубо мое мнение.

Если бы эти ОС считались закрытыми что изменилось бы ?
Отличие программирования PC и PLC может быть критерием разделения на PAC и PLC?

[Михайло]

Если бы эти ОС считались закрытыми что изменилось бы ?

Это означало бы, что ты должен работать в пределах жестко заданных рамок. Никаких тебе C/C++, Isagraf, Codesys...

[Daes]

Если бы эти ОС считались закрытыми что изменилось бы ?

Это означало бы, что ты должен работать в пределах жестко заданных рамок. Никаких тебе C/C++, Isagraf, Codesys...

Не понятна связь набора программ с открытостью ОС и далее с разделением на PLC и PAC

[Михайло]

Ну это Ваша проблема... :D

[Бондарев Михаил]

Я для себя просто понимаю:

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

[MuadDib]

2 Daes
Я не понимаю, зачем лезть в дебри сравнения PLC и PAC, тем более что даже у производителей нет единого мнения на счет последних. В своем первом посте в данной ветке я уже писал, что нужно ориентироваться на поставленную задачу. Если целью является изучение основных принципов программирования мейнстримного АСУТПшного железа, то PAC однозначно не при делах. Возьмите любой ПЛК со средой программирования, основанной на IEC 61131, и изучайте. Не нравятся "Овены" - альтернативы вам в этой ветке уже подсказали. Не нравится сам подход IEC-языков? Сочувствую, но индустрию по вашему вкусу никто переделывать не будет.
Да, бывают задачи АСУТП, в которых PLC не справляются. Но для решения таких задач нужна конкретика, оборудование и ПО подбирается индивидуально. Устройство, которое одинаково хорошо решает любые задачи, не существует в природе. Более того, если вы при решении типичной PLC-задачи напишете что-то свое на PC-совместимом железе, никто вам спасибо не скажет. Да вы и сами пожалеете, если через несколько лет после сдачи в эксплуатацию вас привлекут к поиску неисправностей в таком вот "монстре франкенштейна". :)

[leon78]

Я для себя просто понимаю: если у PLC операционная система открытая (типа WinCE, Linux), то это PAC. Больше никаких критериев не рассматривается. Это сугубо мое мнение.

У Schneider Electric в линейке, называемой PAC, контроллеры Quantum, Premium, M580, M340. Операцонная система у них закрытая, программируются они под Unity в IEC 61131-3
http://www.schneider-electric.com/produ ... BUSINESS=1

[san]

+1 MualDib
Некоторые проивзодители отдельно по спецзаказу продают SDK под свои ПЛК. Тот же Шнейдер Электрик может продать UNITY PRO EFB Toolkit, с помощью которого можно разработать свой функциональный блок или функцию на C++

[leon78]

+1 MualDib
Некоторые проивзодители отдельно по спецзаказу продают SDK под свои ПЛК. Тот же Шнейдер Электрик может продать UNITY PRO EFB Toolkit, с помощью которого можно разработать свой функциональный блок или функцию на C++

Активно пользовался EFB Toolkit для Concept. Пробовал EFB Toolkit для Unity. Назначение - написание своих функцилнальных блоков на Си вместо языков МЭК 61131-3. Ни о каком доступе к ОС контроллера речи нет.

[san]

Активно пользовался EFB Toolkit для Concept. Пробовал EFB Toolkit для Unity. Назначение - написание своих функцилнальных блоков на Си вместо языков МЭК 61131-3. Ни о каком доступе к ОС контроллера речи нет.

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

[leon78]

На выходе генерируется библиотека, аналогично стандартным Концептовским библиотекам. Там код для 16ти и 32х битных контроллеров. Доступна эта библиотека для любого типа контроллеров.