CODESYS + ПЛК МЗТА (МС8.3)

Привет коллеги.
Впервые в своей практике столкнулся с ПЛК российского производства (ну, как 'российского': на процах Cortex, ага), а именно, ПЛК МЗТА МС8.
"Родная" среда разработки этих ПЛК Конграф, скажем так, больше похожа на пособие для изучения программирования для школьников. Как-то не зашла. Поэтому, я задумал вести разработку текущего проекта с этим ПЛК в универсальной среде CODESYS. Тем более, что производитель поддерживает это, выпуская соотв. таргеты.

Из всей что я нашел довольно скудной инфы по этому поводу, я предположил, что для разработки достаточно подключить библиотеку, в которой присутствует лишь один тип: "kb.D-2" - это дисплейный модуль на самом деле. Но через него, теоретически, можно взаимодействовать со всей линейкой ПЛК МС серии.
Но не это главное.
Главный вопрос возник в сопоставлении физических адресов ПЛК, которые изображены на картинке ниже, с адресами, принятыми для системы программирования (типа %IX0.0 / %QX0.0).

Понятно дело, что когда я доберусь до реального физического ПЛК МЗТА (или он до меня доберется), то я быстро разберусь где собака порылась. Но, пока этого не произошло, если кто знает, буду признателен за комментарии по этому поводу.

Видео ниже, было записано мною для одного моего товарища по прежней работе и фактически является руководством по вхождению в программирование этих ПЛК в среде CODESYS с наглядным примером симуляции. Может быть, оно окажется полезным кому-то еще, поэтому, я решил его выложить и здесь, на форуме.

0

Спасибо



Уже сменил работу на другую, на предыдущей для целей автоматизации котельной с теплопунктом уже несколько раз проектировщики применяли комплект Овен КТР-121. Отмечу у него несколько недостатков:
- двухпроводное подключение датчиков температуры - т.е. точность измерения не очень высока, но терпима
- применять только высокоомные датчики температуры, например, Pt1000
- после включения питания каскадного КТР-121 - котловые КТР должны быть все в АВТО
Сам настраивал, смотрел пару лет за эксплуатацией - вроде бы удачный комплект получился.

Добавлено через 31 минуту
С контроллерами МЗТА работал один раз - там автоматизация не получилась из-за неправильного техпроцесса и неправильного подбора оборудования, поэтому в автоматическом режиме работа длилась по несколько часов в день под надзором операторов и технологов, т.е. не долговременно - пока заказчик не отказался от дальнейших экспериментов до замены технологии. Прошло 5 лет и всё никак...

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

Из-за коротких циклов работы не сталкивался с проблемами надёжности.
Успел сжечь один выход (транзистор) - при замене реле =24V не учёл наличия внутри него диода включённого с другой полярностью - перепаял.

Было несколько контуров регулирования - аналоговый ПИД управлял ПЧВ поддержания давления, дискретный ПИД поддерживал уровень. Работали хорошо.
Не понравилось то, что не было возможности копирования настроек между перезаписью программ.

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

0

Мотив Заказчика перейти на "свои" контроллеры понятен как минимум по двум причинам:
- более низкая стоимость оборудования по сравнению с "буржуйским" (Mitsubishi/Simens);
- очевидные проблемы это оборудование достать, ввиду сложившихся реалий (санкции, внешнеполитическая обстановка и т.п.).
Понятно дело, каждому хочется сэкономить, причем, желательно с максимальным сохранением исходного функционала готового комплекса.
Однако, Заказчику не сразу становится видно, что достичь желаемого функционала, к которому он "привык" по предыдущему опыту с европейской линейкой ПЛК - довольно трудно, а иногда и вовсе невозможно.

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

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

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

Иными словами, пришлось хорошо постараться, чтобы свести эту "сборную солянку" хоть к какой-то логически правильной работе. Так же, стало известно, что даже у этих же спецов этого завода - практически всегда возникали трудности с пуско-наладкой своего же оборудования: заявленный функционал либо не работал, либо работал не так, как было задумано и обговорено в заказчиком. В подавляющем большинстве случаев это приходилось устранять/дорабатывать уже на месте в процессе ПНР.
Один мой коллега рассказывал, что на одном из объектов такой "проект" вводили в эксплуатацию почти 3 месяца, причем специалистами завода-изготовителя этого оборудования и котлов. Доходило до почти полного переписывания программ ПЛК прям "на коленке".

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

1