Программирование контроллеров ОВЕН (ПЛК110) с использованием MasterSCADA

Добрый вечер, уважаемые форумчане!

Собираюсь выполнять проект насосной станции с использованием MasterSCADA и ПЛК110 (точная модель контроллера ПЛК110-24.32.P-L).
Имею опыт работы в области автоматизации, но использовать MasterSCADA и продукцию ОВЕН собираюсь впервые. Поэтому вопросы общего характера.

Внимательно ознакомившись с разделом форума по MasterSCADA могу сделать заключение, что подавляющее большинство вопросов относится к архитектуре с использованием OPC-сервера.
Вместе с тем MasterSCADA позволяет программировать PC-совместимые контроллеры, к которым, в частности, относится ПЛК110. Более того процесс создания системы значительно упрощается при использовании интегрированного пакета, отсутствует лишнее звено передачи данных (OPC-сервер) и лишние инструменты разработки (CoDeSys). Казалось бы это должно быть генеральной линией. В связи с этим первый вопрос:
1. Почему мало обсуждений об использовании MasterSCADA для программирования контроллеров ОВЕН? Поделитесь опытом, кто использовал MasterSCADA для программирования контроллеров. Расскажите об известных проблемах. Буду благодарен за пример проекта какого-либо объекта для изучения.

Второй и третий вопросы более конкретные.

2. В системе необходимо будет опрашивать приборы по ModBus RTU. Правильно ли я понимаю, что для организации обмена по ModBus RTU в MasterSCADA уже все встроено. Необходимо просто настроить нужный порт на протокол ModBus RTU, добавить устройства, в них регистры и все должно заработать. Или здесь могут быть проблемы?

3. Мой коллега (мнению которого я не полностью доверяю) сообщил, что лет 5 назад, он имел дело с контроллерами ОВЕН и у них часто горели выходы. Насколько это обоснованное мнение. Прокомментируйте, пожалуйста.

Заранее благодарен, Спорягин Кирилл.

Цитата:

---

Сообщение от SKV

1. Почему мало обсуждений об использовании MasterSCADA для программирования контроллеров ОВЕН?

---

Потому что мало кто пользуется этой функцией. Ваш Капитан Очевидность. :D

Цитата:

---

Сообщение от SKV

3. Мой коллега (мнению которого я не полностью доверяю) сообщил, что лет 5 назад, он имел дело с контроллерами ОВЕН и у них часто горели выходы. Насколько это обоснованное мнение. Прокомментируйте, пожалуйста.

---

ИМХО.
Для серьёзной нагрузки лучше ставить промежуточное реле. Т. к. заявленный коммутируемый ток до 3 А, лично у меня вызывает сильные сомнения. Особенно при частой коммутации.

Мне кажется что МастерСкада не сможет запрограммировать ПЛК ОВЕН и любые другие, где используется определенная среда рантайм, такие как CDS, STEP 7 и т.д.
Это несколько для иных ПЛК вроде предназначено.

Цитата:

---

Сообщение от melky

Мне кажется что МастерСкада не сможет запрограммировать ПЛК ОВЕН и любые другие, где используется определенная среда рантайм, такие как CDS, STEP 7 и т.д.
Это несколько для иных ПЛК вроде предназначено.

---

Сможет. Только при заказе контроллера надо указать в конце обозначения в место M или L (система исполнения CoDeSys), МР (система исполнения MasterPLC).

smk1635 ага, так и думал, что среда должна быть другой.

Цитата:

---

Сообщение от melky

smk1635 ага, так и думал, что среда должна быть другой.

---

Угу. Почему и не использую контроллеры с МастерПЛК.
Заказная позиция. И кроме как в связке с Мастерскада, ни где не применишь.

Так а почему не используете MasterSCADA для решения задач. Если ее используют в связке с OPC-сервером, то разумнее, как мне кажется, использовать MS и для программирования контроллера.

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

Aso, можете расширить ответ.
Вот я смотрю, что можно использовать ВФБ мотор, задвижка, клапан, аналоговый датчик, ПИД-регулятор. Естественно есть элементарные логические операции, возможность написать ST-блок.
Что еще надо?
Я хорошо знаком со Step7 (в частности с SCL). На мой взгляд возможности там те же, только готовых блоков нет (задвижка, мотор, клапан). Если их хотите, то платите деньги еще за что-нибудь вроде PSC7. А это очень большие деньги.
Так в чем же слабый функционал?

Если Вас это устраивает - пользуйтесь. Вы получаете отличный софтлоджик. Ценой некоторого отсутствия унификации - но это стандартный подход в софтлоджик-системах.

Вот только сравните с функционалом КДС.

SKV а вы случаем не пробовали библиотеки Oscat ? вроде бы они есть и для STEP 7, тогда видимо не возникало бы вопросов, что где-то чего-то нет.

Цитата:

---

Сообщение от SKV

Так а почему не используете MasterSCADA для решения задач. Если ее используют в связке с OPC-сервером, то разумнее, как мне кажется, использовать MS и для программирования контроллера.

---

Используем MasterSCADA. И достаточно активно. Именно в связке с ОРС-сервером.

А причины следующие:
1. Контроллеры с КДС как правило всегда в наличии, а с Мастер ПЛК - заказная позиция.
2. Помимо проектов с MasterSCADA, есть куча проектов - локалок. Соответсвенно в ЗИП можно держать контроллеры с КДС, которые подойдут на любой объект.
3. ИМХО. МастерПЛК не дотягивает по функционалу по сравнению с КДС.

И откровенно говоря, сильно недолюбливаю язык программирования CFC (который на сайте Инсата ошибочно называется FBD). :)

Вопрос не в том, есть библиотека в Step7 или нет. Вопрос в том, что и в MasterSCADA все есть. Так почему не популярно такое решение?
Что касается библиотеки Oscat. Спасибо за ссылку. Буду иметь ввиду. Другое дело, что мы свою библиотеку создали для Step 7. Так же можно поступить в MasteSCADA.

2. Помимо проектов с MasterSCADA, есть куча проектов - локалок. Соответсвенно в ЗИП можно держать контроллеры с КДС, которые подойдут на любой объект.
А почему и на локалки не ставить MS?

3. ИМХО. МастерПЛК не дотягивает по функционалу по сравнению с КДС.

Так, а в чем именно не дотягивает. Можете привести примеры?

Господин SKV не поймите превратно, но пока что Ваши посты более похожи на рекламу... Рекомендую попробовать и то и другое. Тогда можно будет обсуждать, благо MasterSCAD можно как и CODESYS скачать и попробовать.
1. Мы можем изготавливать контроллеры ПЛК110 с системой исполнения от Master SCADA. Не делаем этого массово, так как действительно нет запросов на такой продукт. се определяет рынок.
2. Когда то делая проект ПЛК - MasterSCADA мне пришлось немного разобраться с набором блоков в MasterSCADA. Разобрался. Не удобно. CODESYS реально легче освоить. Хотя конечно наличие спец.библиотек, в частности по опросу оборудования, позволяет данному продукту найти свою нишу.
Ну а дальше дело вкуса. Если у Вас будет насущная задача и стабильный спрос по использованию ПЛК ОВЕН с MasterSCADA - мы для Вас даже склад будем держать...

З.Ы.: Ну и предвкушая потенциальное развитие разговора: Может программирование контроллеров ОВЕН (или любых других) из под MasterSCADA действительно неудобно, и по этому компания Инсат не первый год работает над своей собственной полноценной системой программирования?

Рекламой, конечно, никакой я не занимаю, а просто пытаюсь разобраться в вопросе.
К сожалению, более менее конкретного ответа пока никто не дал.
Неужели нет тех, кто использовал MS для программирования PC-совместимых контроллеров?

Цитата:

---

Сообщение от capzap

ПЛК Овен не PC-совместимый, это система реального времени

---

Это не так. Контроллеры ОВЕН PC-совместимые.

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

Ядро MasterSCADA действительно исполняется только на ПЛК с ОС Linux. В контроллерах под это ядро портировал Linux,
Ну если Вам интересны конкретно отзывы людей, которые использовали - давайте подождем отзывов.
Но как и писал - очень мало продавалось контроллеров с этим ядром.
Так что я бы на Вашем месте скачал и попробовал.

Я уже во всю изучаю MasterSCADA, уже давно пробую. Есть вещи, которые я попробовать не могу (например, потому что для них нужен контроллер с модулями УСО, которого у меня нет), есть вещи, для осознания, которых нужен опыт. Тут и пытаюсь найти людей, которые смогут им поделиться.

Я позволю подытожить, выделить те вещи, на которые пока мне не удалось услышать ответа.

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

И второй вопрос, который полностью остался без внимания.
2. В системе необходимо будет опрашивать приборы по ModBus RTU. Правильно ли я понимаю, что для организации обмена по ModBus RTU в MasterSCADA уже все встроено. Необходимо просто настроить нужный порт на протокол ModBus RTU, добавить устройства, в них регистры и все должно заработать. Или здесь могут быть проблемы?

П.С. Как я понимаю на форуме должен быть пользователь от ИнСАТ, почему он молчит?

Цитата:

---

Сообщение от SKV

Правильно ли я понимаю, что для организации обмена по ModBus RTU в MasterSCADA уже все встроено. Необходимо просто настроить нужный порт на протокол ModBus RTU, добавить устройства, в них регистры и все должно заработать

---

Да, именно так и настраивается Modbus в контроллере.
После назначения протоколу порта, в него можно добавлять устройства и регистры.

Цитата:

---

Сообщение от SCADAMaster

Да, именно так и настраивается Modbus в контроллере.
После назначения протоколу порта, в него можно добавлять устройства и регистры.

---

Спасибо.
А первый вопрос?

Множество наших клиентов внедряли контроллеров для управления и диспетчеризации различных систем (водоснабжение, нефтедобыча, вакуумные установки).
Их проекты, по очевидным причинам, мы выложить не можем.

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

Спасибо за ответы.

Попробовал некоторые вещи написать на MasterSCADA, как на softlogic-системе.
Делюсь некоторыми соображениями.
В целом впечатление хорошее, но есть следующие недостатки.

1. Ранее мною было сказано, что основное преимущество данного подхода заключается в использовании уже готовых функциональных блоков (ФБ), таких как "Аналоговый датчик", "Мотор", "Клапан", полностью интегрированных. Это означает, что добавление таких ФБ в проект обеспечивает как его логическое исполнение в контроллере, так и его визуализацию на уровне АРМа оператора, без дополнительных усилий по организации тэгов ОРС-сервера и согласования в работе. Но использование данных ФБ оборачивается и определенным недостатком. Так как это блоки стандартные, то внести в них изменения не представляется возможным и приходится мирится с теми недостатками, которыми они обладают. Для меня такие недостатки следующие:
1.1 ФБ "Аналоговый датчик" производит только регистрацию выхода аналогового параметра представленного в физических единицах за границы (верхняя и нижняя, предупредительная и критическая). Этот блок не преобразует коды АЦП в физический сигнал. Тут необходимо пояснить, что тот стиль программирования, к которому я привык, подразумевает, что подобный ФБ служит также для преобразования кодов АЦП, полученных со входа модуля аналоговых входов, в физический сигнал. Для чего имеет такие настройки как диапазон измерения физического сигнала и диапазон кодов АЦП. Получается, что используя стандартный блок, я все же должен создать свой дополнительный блок для преобразования кодов АЦП в физический сигнал и затем уже его выход подавать на вход стандартного блока. Что приводит к увеличению числа ФБ в проекте.
1.2 Для этого же ФБ следует отметить, что в стандартном его исполнении не предусмотрена возможность изменять технологические границы из окна детализации. Доступен только просмотр. Вместе с тем, зачастую техническому персоналу необходимо изменять технологические границы, а значит необходимо будет менять их в проекте, что представляется неудобным.
1.3 В ФБ "Мотор" в случае регистрации ситуации не включения мотора или его не выключения, выдается сообщение "Авария ...", в окне детализации также отображается слово "Авария". Моя практика работы на ТЭЦ, показывает, что персонал не любит слово "Авария". Для них это что-то серьезное. В случае несрабатывания мотора, они говорят о его "неисправности". Но изменить слово "Авария" в окне детализации невозможно.
1.4 Также для ФБ "Мотор" в окне детализации используется одинаковая мнемоника для случаев блокировки и местного режима.

2. Отсутствие некого средства, с помощью которого можно было бы определять текущие значения переменных в контроллере, без подключения верхнего уровня MasterSCADA. Поясню зачем это нужно. Я привык выполнять проекты автоматизации таким образом, чтобы критическая часть логики выполнялась в контроллере. Так, например, алгоритмы технологических защит и блокировок должны обязательно полностью выполняться в контроллере, вне зависимости от состояния подключения АРМа оператора к контроллеру. Проверка работоспособности такой функциональности, очевидно, должна осуществляться при отключенной MasterSCADA. Но в этом случае, нет доступа к переменным контроллера и трудно диагностировать его состояние, например, если что-то в алгоритме работает неверно. Подключение MasterSCADA в этом случае делает эксперименты не чистыми. Выход из сложившейся ситуации можно было бы видеть, допустим, в возможности в контроллере сконфигурировать функциональны блок, отвечающий за выдачу переменных в порт, а затем чтения этих переменных с помощью программы HyperTerminal или подобной.

3. Необходимо платить за лицензию на контроллер (сейчас это 8600 рублей за 100 точек ввода/вывода). Правда, не нужно платить за ОРС-сервер.

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

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