Множество наших клиентов внедряли контроллеров для управления и диспетчеризации различных систем (водоснабжение, нефтедобыча, вакуумные установки).
Их проекты, по очевидным причинам, мы выложить не можем.
Спасибо.
Буду надеяться, что эту тему прочтут те кто использовал MS для программирования контроллеров и поделятся опытом.
Спасибо за ответы.
Попробовал некоторые вещи написать на MasterSCADA, как на softlogic-системе.
Делюсь некоторыми соображениями.
В целом впечатление хорошее, но есть следующие недостатки.
1. Ранее мною было сказано, что основное преимущество данного подхода заключается в использовании уже готовых функциональных блоков (ФБ), таких как "Аналоговый датчик", "Мотор", "Клапан", полностью интегрированных. Это означает, что добавление таких ФБ в проект обеспечивает как его логическое исполнение в контроллере, так и его визуализацию на уровне АРМа оператора, без дополнительных усилий по организации тэгов ОРС-сервера и согласования в работе. Но использование данных ФБ оборачивается и определенным недостатком. Так как это блоки стандартные, то внести в них изменения не представляется возможным и приходится мирится с теми недостатками, которыми они обладают. Для меня такие недостатки следующие:
1.1 ФБ "Аналоговый датчик" производит только регистрацию выхода аналогового параметра представленного в физических единицах за границы (верхняя и нижняя, предупредительная и критическая). Этот блок не преобразует коды АЦП в физический сигнал. Тут необходимо пояснить, что тот стиль программирования, к которому я привык, подразумевает, что подобный ФБ служит также для преобразования кодов АЦП, полученных со входа модуля аналоговых входов, в физический сигнал. Для чего имеет такие настройки как диапазон измерения физического сигнала и диапазон кодов АЦП. Получается, что используя стандартный блок, я все же должен создать свой дополнительный блок для преобразования кодов АЦП в физический сигнал и затем уже его выход подавать на вход стандартного блока. Что приводит к увеличению числа ФБ в проекте.
1.2 Для этого же ФБ следует отметить, что в стандартном его исполнении не предусмотрена возможность изменять технологические границы из окна детализации. Доступен только просмотр. Вместе с тем, зачастую техническому персоналу необходимо изменять технологические границы, а значит необходимо будет менять их в проекте, что представляется неудобным.
1.3 В ФБ "Мотор" в случае регистрации ситуации не включения мотора или его не выключения, выдается сообщение "Авария ...", в окне детализации также отображается слово "Авария". Моя практика работы на ТЭЦ, показывает, что персонал не любит слово "Авария". Для них это что-то серьезное. В случае несрабатывания мотора, они говорят о его "неисправности". Но изменить слово "Авария" в окне детализации невозможно.
1.4 Также для ФБ "Мотор" в окне детализации используется одинаковая мнемоника для случаев блокировки и местного режима.
2. Отсутствие некого средства, с помощью которого можно было бы определять текущие значения переменных в контроллере, без подключения верхнего уровня MasterSCADA. Поясню зачем это нужно. Я привык выполнять проекты автоматизации таким образом, чтобы критическая часть логики выполнялась в контроллере. Так, например, алгоритмы технологических защит и блокировок должны обязательно полностью выполняться в контроллере, вне зависимости от состояния подключения АРМа оператора к контроллеру. Проверка работоспособности такой функциональности, очевидно, должна осуществляться при отключенной MasterSCADA. Но в этом случае, нет доступа к переменным контроллера и трудно диагностировать его состояние, например, если что-то в алгоритме работает неверно. Подключение MasterSCADA в этом случае делает эксперименты не чистыми. Выход из сложившейся ситуации можно было бы видеть, допустим, в возможности в контроллере сконфигурировать функциональны блок, отвечающий за выдачу переменных в порт, а затем чтения этих переменных с помощью программы HyperTerminal или подобной.
3. Необходимо платить за лицензию на контроллер (сейчас это 8600 рублей за 100 точек ввода/вывода). Правда, не нужно платить за ОРС-сервер.
Вот основные недостатки, которые мне удалось обнаружить.
Хочу попробовать решить аналогичную задачу с использованием CoDeSys и уже на основании непосредственного сравнения выбрать вариант программирования.
Понял почему ФБ "Аналоговый датчик" имеет вход в физических единицах.
Аналоговые модули ОВЕН позволяют преобразовать унифицированный сигнал (токовый или напряжение) в физические единицы прямо в модуле.
Видимо, поэтому.