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

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

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

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

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

0

TOF тогда сделал так

ЗДН ЛОГ нужно было, зачем - уже не помню.

0

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

0

У меня был ЩУ (щит управления) и 4 ЩУП (щит управления печью).
ЩУ отслеживал состояния работы отдельных ЩУП и включал какое-то общее для всех оборудование.

В программе от ПЛК ЩУ виртуальными связями подключил все ШУП - получилось как солнышко с центром в ЩУ. Не было прохождения насквозь никакого сигнала. Только ЩУ-ЩУП1, ЩУ-ЩУП2, ЩУ-ЩУП3, ЩУ-ЩУП4.

Хотя провода, конечно, гирляндой соединялись.

Реально смонтировали 2 из 4 печей, но проект был на 4. Вернусь домой - покажу главный холст.

1

Сообщение от ФедосеевПавел получилось как солнышко с центром в ЩУ

Ага, я тоже уже прихожу к такому варианту...

Сообщение от ФедосеевПавел Вернусь домой - покажу главный холст.

Было бы неплохо )

0

В общем, у меня получилась вот такая конструкция (согласно прошлой тестовой задаче):
Радиальная схема связи:

Слейвы одинаковые (кроме адреса, естественно), включая собственные списки:

Мастер (ведущий) - отдает приказы и получает состояния ведомых:

Таким образом получается, что у мастера добавляется кол-во виртуальных входов/выходов, согласно кол-ву подчиненных.
В симуляторе работает как часы.
Если в настоящей связи KontarBus все так и будет, то это то, что мне нужно!

0

Главный холст


Один из однотипных Slave (ЩУП4).
"Из HMI" и "В HMI" - это параметры для ввода и вывода параметров в операторскую панель.
"ШУП" - основной алгоритм работы щита без внутренних энергонезависимых параметров.

0

ФедосеевПавел, ага, ну да. Такую топологию я и представлял уже, после того как задал вопрос. На картинках, полагаю, передача данных между ШУП и ШУ - односторонняя?

0

Да, получилась односторонняя - от ЩУП_N к ЩУ и другая от ЩУ к МР20.
Можно было бы и команды в ЩУП направлять, но необходимости не было.

0

Сообщение от ФедосеевПавел Можно было бы и команды в ЩУП направлять

Но для этого пришлось бы дорисовывать выхода у ЩУ и входа у ШУП-ов, и соединять их. Как я понял, в этой системе проектирования, линия связи не работает в обе стороны...

Добавлено через 1 минуту
Т.е. входы, выходы и их соединения однозначно определяют направление связи.

0

Да, совершенно верно.
Связи показываются для каждого направления для каждой переменной.

1

ФедосеевПавел, окей, вопрос касательно связи между Контарами более-менее прояснился.
Спасибо за содействие!
Возможно позже, немного порасспрашиваю по поводу увязки HMI с этой системой (ну, чтобы самому долго не увлекаться изучением этого).

0

Хорошо. Постараюсь вспомнить.
У меня оставалась нерешённая проблема - при отключении щита Slave на панели всплывало окно о прерывании связи и его было проблематично убрать. Так и не разобрался...

0

И снова, как говорится, здравствуйте.
Коль уж мы немного "перебежали" на софт "Конграф", то в качестве заметки приведу пример - как разделить дробное (float) число (температуру/напряжение...) на два целых, например, для передачи их по внутренней сети KontarBus.

В библиотеке Конграфа на самом деле есть соотв. функциональные блоки, и в нашем случае подходит блок АН-2 ЦЕЛ, который выполняет побайтное преобразование аналогового числа в два целых. Но проблема в том, что свои операции, включая результат, он помещает в память регистров, например, для передачи в Modbus. Эта память недоступна для памяти программы, т.е. для того же симулятора, ну и как следствие, мы не сможем передать этот результат по сети KontarBus другому устройству.

Для выхода из этой "неприятной" ситуации, я разработал свой ФБ, который выполняет то же, что и библиотечный АН-2 ЦЕЛ:

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

После создания блока прописываем у значащих (выходных) субмодулей следующие параметры:


Теперь они доступны в симуляторе (да и вообще в программе внутри блока).

Вставим наш ФБ в текущую программу для проверки, например, температуры:

и проверим результат в симуляторе:

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

0

Мне казалось, что связь между ПЛК по внутренней сети возможна в любом формате чисел.

А при разделении "аналогового" числа на два целых (typecast) АН-2 ЦЕЛ можно отправить результаты в ЗДН ЦЕЛОГО в котором выход спрятать и присвоить его переменной из списка.
Или просто не уяснил цель преобразования.

0

ФедосеевПавел, оказалось, что нет.

Сообщение от ФедосеевПавел АН-2 ЦЕЛ можно отправить результаты в ЗДН ЦЕЛОГО

Не-а, внутри программы там будет "ничего", т.е. даже не нули. Что и понятно, т.к. все это находится в регистрах реального ПЛК.

0

Точнее сказать - они скорее всего передаются, но увидеть в отладке их нельзя, после встроенного ФБ, т.к. он вычисляет все в памяти регистров конкретного ПЛК. А передать то в другой блок без проблем.

Добавлено через 1 минуту

Сообщение от ФедосеевПавел и присвоить его переменной из списка.

пробовал. не помогло )

0

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

При помощи АН-2 ЦЕЛ отправлял по Modbus аналоговое число на панель, это работало, а вот разделение на регистры в список не пытался добавлять. Возможно, какая-то недоработка симулятора или всей среды.

0

В одном моменте не до конца разобрался — передача тегов из ПО КОНСОЛЬ в проект для панели. ...... Теперь добавляю теги из ПЛК к тегам проекта панели кнопкой «Импорт CSV…». И получаю нерабочий проект для панели! Всё потому, что теги ПЛК не добавились, а полностью заменили существовавшие внутренние теги панели. Чтобы выйти из этой ситуации, пришлось: ......

Также, мне советовали создавать проект для панели без использования шаблона — тогда проект создаётся без внутренних тегов, с которыми нужно дополнительно возиться при обновлении проекта для ПЛК.

Опишу этот момент из своего опыта:
Да, если создавать проект без использования шаблона, то "пользовательских" меток в нем не будет совсем, т.о. импортированные теги просто заносятся в таблицу и ничего не перезаписывают лишнего.
Однако, если проект создан на основании шаблона, то в нем будут присутствовать некоторые теги "по умолчанию" примерно такого вида:

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

и тогда вновь добавляемые теги не перезапишут системные. Работа проекта в HMI не нарушится.

1

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

И так, запущена в работу автоматизация средне-статистической котельной (2 котла), на основе приборов МЗТА. Схема IO и межблочных связей вышла следующая:

Для наглядной имитации и проверки на объекте тех или иных узлов автоматики, для панели Weintek был разработан ряд экранов:

Можно отметить, что большинство "заводских" алгоритмов (блоков) в ПО Контар - сделано весьма добротно. Таких как ПИД-регуляторы, компараторы, различного рода преобразователи и прочие 'локальные' вещи. В то же время, действительно важным вещам, что касается связи и безопасности, уделено слишком мало внимания. Т.е. они оказались не работоспособны вообще, в плане реализации конвенций и требований IEC, либо работоспособны "наполовину". Остальную "половину", как обычно, пришлось дорабатывать напильником.

Так же, существуют некоторые "тонкости", которые не освещены нигде в документации/справке и познаются только "случайно" в ходе ПНР.

Не буду касаться всех замеченных недостатков: достаточно будет упомянуть только банальную проверку связи между устройствами, т.н. ФБ "ПРВ СВЗ (М)".
Работает эта система в режиме "симплекс", т.е. в одном направлении Slave -> Master. Ведущее устройство узнает что какой-то Слейв отвалился, а вот чтобы Слейв знал о пропаже связи с Мастером - нужно самостоятельно реализовать тоже самое, только наоборот. От сюда, кроме всего прочего, растет "паутина" межблочных связей на общей картине взаимодействия.

Кроме того, если в системе участвует панель, которая в свою очередь получает все данные от всех ПЛК через тот же WebLinker, то она как бы сама определяет потерю связи с блоками. Для этого ФБ проверки связи вообще становятся не нужны.

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

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

Не мало вопросов и к "железной" составляющей этих ПЛК, что набрасывает очевидную тень на бесперебойность и надежность работы систем на их основе. Не редки случаи, когда при ошибочной подаче "не того сигнала/нагрузки" в порт - порт выгорает полностью. Если в других, по-настоящему промышленных ПЛК проблема легко решается путем перебивки входа/выхода на соседний свободный, то здесь без замены целого ПЛК не обойтись. Так же, встречались самопроизвольные переключения состояния приборов в режим "СТОП" по неведанным причинам, равно как и не переход их в режим "RUN" после пропажи и восстановления питания.
Можно сказать, что автоматизация на их основе требует практически 100%-го участия человека рядом (оператора) на случай таких странных поведений. Этот факт значительно нивелирует рекламный лозунг "Подключил и забыл".

1

Какой-то глюк с загрузкой картинок, продублирую:

1