Свежие (в том числе и относительно свежие) модели программируемого реле Logo! от компании Siemens поддерживают передачу данных по протоколу Modbus TCP как в качестве клиента, так и в качестве сервера. К ним относятся модули версий 8.1 & 8.2 (FS4) и 8.3. В настоящей заметке рассматривается простой вариант с использованием circuit diagram, сетевой проект не используется. В качестве среды разработки применяется LOGO!Soft Comfort версии 8.3.0.
Начнем с функционала сервера протокола Modbus TCP. Для серии FS4 создаем диаграмму с именем FS4_MB_srv, задаем ip-адрес и выставляем тип оборудования. Саму диаграмму сохраняем с тем же именем, FS4_MB_Srv.
Теперь необходимо немного оживить систему. Выходы Q1..3 я проводами подаю напрямую на входы I1..3. В диаграмме рисуем вот такую архи-сложную математическую модель.
Выход Q1 меняет свое состояние на противоположное каждые 2 секунды, выход Q2 активен постоянно, а состояние входа 1 копируется в меркер M1. Загружаем и убеждаемся, что программа работает.
Для включения функционала сервера Modbus необходимо заглянуть в свойства диаграммы еще раз.
Оставляем все, как есть. Порт 502 принят портом для протокола Modbus TCP, разрешаем все входяшие соединения. Там же в настройках смотрим карту адресов Modbus.
Загружаем все изменения и запускаем клиент Modbus. Для начала используем клиент на PC. Клиенту указываем ip-адрес сервера, это 192.168.43.211 и порт, он был оставлен по умолчанию, т.е. 502. Протокол Modbus TCP унаследовал от Modbus RTU адрес устройства, он же device address, он же slave id и т.д., однако он актуален только для «мостов» RTU-TCP. Если устройство является «оконечным», то slave id должен игнорироваться. В настройках сервера Modbus TCP реле Logo! этой настройки нигде нет. Экспериментальным путем подтверждено, что Logo! ведет себя «правильно» и игнорирует id в запросе. Настраиваем клиент на чтение первых 4 дискретных входов (входа 1..4), первых 4 дискретных выходов (койлы, начиная с 8193) и одного меркера (снова койл, но с номером 8257). В вышеуказанной таблице номера койлов и регистров приведены по базе 1, что в моем клиенте настраивается. Если у вас что-то идет не так, попробуйте сместить адресацию на единицу (например, читать койлы не с 8193, а с 8192… увы, но до сих пор многие производители железа и софта допускают разночтения стандарта, особенно в части адреса и номера регистра или койла, в общем — необходимо импровизировать).
Скриншот ниже показывает состояние дискретных входов (слева) 1..4, дискретных выходов (посередине) 1..4 и флаг M1 (права).
По таблицам я вижу, что состояние битовых переменных меняется в соответствии с программой. Зададим значение выхода Q3 в «истину». В связи с тем, что выход Q3 подан напрямую на вход I3, он должен поменять свое состояние так же на «истину», что и наблюдаем на скриншоте ниже.
Попробуем прочитать и записать адреса типа V, которые доступны по Modbus в качестве регистров хранения и койлов. Пока что в виде слов. Обращаю внимание, что адреса типа V идут по сквозной нумерации, начиная с нуля, а размерность области памяти указывается отдельно. VB0 — байт 0. VW0 — слово, которое начинается с байта 0. И так далее. В общем, наблюдаем аналогию с ПЛК Simatic.
С адресами типа V тоже все работает. Обратите внимание, что слово VW0 — это байты VB0 и VB1. Таблица данных составлена исключительно для наглядности. Изменение значений работает, разумеется, в обе стороны.
С памятью типа V в программе Logo! можно работать блоками типа network input/output, выполнять преобразование float — int и т.д. Запишем в регистры хранения 1 и 2 (по базе 1) вещественное значение 10.5 и преобразуем его в программе.
Настройка протокола Modbus в версии 8.3 имеет некоторые отличия. Для начала создадим диаграмму с именем L8_3_MB_srv, зададим ip-адрес 192.168.43.212, укажем тип оборудования (Logo! 8.3) и полностью скопируем программу. Связывать выхода со входами на этом реле я не буду, чуть позже это реле мы превратим в клиента modbus. Достаточно просто временно поднять на нем сервер и убедиться, что он так же функционирует.
Более новое реле у меня оказалось с релейными (масло маслянное, да) выходами, поэтому можно даже не смотреть изменение состояния дискретного выхода Q1. Его включение и отключение каждые две секунды и так прекрасно слышно. В настройках необходимо вначале разрешить протокол Modbus.
И только потом добавить соединение Modbus-сервера.
В остальном все работает аналогично и не заслуживает отдельного внимания. Со спокойной совестью закрываем клиент протокола на PC, убираем Modbus Server Connection в Logo!, очищаем программу (двухсекундное щелкание реле начинает потихоньку сводить с ума) и приступаем к настройкам клиента на реле версии 8.3.
Первый способ настройки клиента — сопоставление переменных в рамках соединения. Для этого задаем соединение клиента с сервером.
И переходим в его настройки.
Тут я указываю ip-адрес сервера и его порт, а так же составляю таблицу, что/откуда читаем и что/откуда пишем. В данном случае читается состояние 4 дискретных входов, а их значение размещается в меркерах (флагах) M1..4. Unit ID (адрес подчиненного modbus-устройство) задан, как 255. Эта настройка, как я говорил выше, целиком и полностью зависит от реализации сервера Modbus. В нашем случае сервером выступает Logo!, которая игнорирует этот ID.
Вытаскиваем на диаграмму локального реле 4 флага и смотрим на их изменения.
M1 моргает каждые 2 секунды, M2 горит постоянно, что соответствует нашей гениальной модели.
Немного расширим данные.
Во флаги M10..13 читаем состояние дискретных выходов сервера, а состояние M22 шлем на дискретный выход Q3 удаленного реле. Напоминаю, что номера регистров и койлов/входов можно посмотреть в настройках и скриншот я приводил чуть выше. Так же чуть дорабатываем программу локального реле и проверяем его работу.
Выход Q3 теперь дистанционно меняет свое состояние раз в две секунды. Все работает, как надо, это видно и по состоянию удаленного Q3 (локальный меркер M12) и по состоянию удаленного I3 (на который замкнут выход Q3) по меркеру M3.
К сожалению, я не нашел способ контролировать состояние соединения с сервером. Кроме флагов M можно использовать, разумеется, и другие адреса. В принципе, этот способ весьма хорош, и я к нему даже вернусь чуть попозже, но лично с моей точки зрения он лишен наглядности. Первый взгляд на диаграмму не дает четкого понятия, что тот или иной меркер является «сетевым». Можно прописать имя меркера, можно ставить коменты, это факт. Однако, второй способ, использование сетевых входов/выходов, более нагляден, но тоже не лишен недостатков.
Для рассмотрения обмена с сервером при помощи сетевых переменных, я очищаю диграмму и удаляю созданное соединение. Теперь я помещаю на диаграмму блок типа Network input
И приступаю к конфигурации этого блока. Читаем первый дискретный вход с сервера Modbus.
Тиражируем на оставшиеся дискретные входы, загружаем и проверяем работу. Тут приходится применять т.н. Open Connector (X1..X4), без него программа не прогружается. Вместо открытого коннектора, разумеется, в боевой программе следует использовать вменяемый, нужный и полезный блок, а не эту заглушку.
Становится интересно, а что с соединениями? В явном виде на этот раз коннекшен не задавался. Посмотреть на соединения можно все там же, в настройках.
Соединение создано автоматически. Какие либо настройки изменить невозможно. Дорабатываю схему, получаем в итоге то же самое. Чтение 4 входов, чтение состояния 4 выходов и циклическая запись 0 и 1 и выход 3 удаленного реле. Отличия от первого варианта — в использовании заглушек и промежуточного меркера.
Второй способ лично мне кажется более наглядным (вопрос вкусовщины, не более). Однако, использование сетевых переменных неприменимо, если возникает необходимость считать 2 регистра, как одно значение. Network analog input позволит считать только один.
Напоминаю, что вещественный float — это 4 байта или 2 регистра. А у нас Logo…В этом случае применяем первый способ и читаем два регистра в область V, как двойной слово. Поэтому снова стираем программу на 8.3, а заодно и дорабатываем FS4. Мне совершенно не хочется записывать какое-либо значение в область VD на «серверном» реле. Поэтому записывать значение я буду одним клиентом Modbus TCP (на ПК), а считывать — на другом. Что произойдет, если к реле, на котором прописано только одно «серверное» соединение, подключить более одного клиента? Все правильно, второй клиент не подключится. Что надо сделать, чтобы подключиться двумя клиентами? Обратно, правильно, надо просаить два соединения. Вот так теперь выглядят настройки сети сервера Modbus на Logo FS4.
Приятная неожиданность. Для обоих соединений я указываю порт 502, и все работает. Я ожидал, что для второго коннекшена потребуется указать другой порт.
Клиент на ПК подключается к серверу FS4 и читает/пишет регистры хранения 1..4, воспринимая их, как вещественную величину. На стороне реле Logo! регистры хранения 1 и 2 соответствуют адресу VD0.
Настраиваем клиент на Logo 8.3. Два регистра хранения считываются с сервера и помещаются по адресу VW10..VW12 (оно же VD10).
Смотрим таблицу данных Logo 8.3 и видим заданное с другого клиента значение 666.0, находящееся по адресу VD10.
Комментарии (30)
Sky4eg
14.02.2022 11:12+1Ох напрограммировал я в свое время контроллеров Logo! Очень интересно было. Начиная автоматикой для гаража в коттедже и заканчивая компонентами городских подстанций! Однажды при помощи модуля и 2 дополнений написал программу управления пожарной сигнализцаии на 16 этажей! Получилось дешевле чем на релюшках, но не взяли в массовое производство из-за того, что сборщики взбунтовались, так как не было сложной обвязки и они получали в разы меньше на сборке данных шкафов )
milman_kaz
14.02.2022 12:52Детально написаны изыскания автора на "тему" ) Мне был интересен сам факт появления ModbusTCP на LOGO, т.к. в некоторых задачах микроавтоматизации действительно этот девайс вне конкуренции по сочетанию бренд-качество-цена-функционал. Теперь еще и с модбасом. Спасибо!
PR200SD
14.02.2022 12:57У ОВЕН вышел ПР103 с поддержкой Modbus TCP, пример управления из нескольких мест, в том числе и с панели оператора недавно тестировал, все ОК:
Siemargl
14.02.2022 23:09Когда Овен дороже Сименса....
Сравнение не прямое, и Овен только зарелизился, но Лого и аналогам уже лет 15, баги отловили...Выбор так себе
PR200SD
15.02.2022 07:05А как Вы сравнивали какой вариант дороже?
Я из стать не очень понял тип реле лого, по скриншотам только косвенно увидел 4 дискретных входа и 4 дискретных выхода, полный набор периферии мне не известен у лого.
Рассмотренный выше экземпляр ОВЕН ПР103 имеет 16 дискретных входов, 8 универсальных аналоговых, которые так же могут быть дискретными, 16 выходов, порт RS485 встроенный и возможность установить ещё один RS485, и встроенный облачный сервис. Это если коротко. Теперь можно говорить о цене.
Siemargl
15.02.2022 07:31Лого в базе обойдется мне в 7000р. Сравнить с ПР103 за 11400р напрямую сложно, просто потому что "Остальные модификации появятся в продаже в первой половине 2022 года.", а добирать модулями смыла не вижу - не для всех задач нужно большее кол-во входов.
ingwar_85
15.02.2022 05:13Недавно пришлось делать проект: logo8+Kinco по MB TCP. Откровенно говоря о лого сложилось такое себе впечатление. Софт тупой и глючный. Сам лого нормально работает только мастером. Если перевести в слэйв пользовательская программа, перестаёт выполняться. Вроде так и положено. Но если поупражняться в загрузкой проекта подольше можно добиться слэйв режима с работой программы. Техподдержка у Siemens по Logo тоже никакая. В общем тот же ПР200 и то интереснее.
Кстати, задачка знатокам. Как сохранить в энергонезависимой памяти Logo целочисленную переменную считанную с пвнели через MB ? Например мне необходимо было задавать с панели в реле значение максимальных и минимальных обротов. И хотелось, что бы эти данные хранились именно в лого, ибо так надёжнее. Увы. Разобраться не смог, техподдержка тоже не подсказала как быть. В итоге пришлось хранить параметры в панели управления. Может кто тут подскажет? )
akcount Автор
15.02.2022 06:45В моем примере Logo работает сервером (слейвом) модбаса, и ППО при этом функционирует. Возможно, у Вас совпали изменения в ППО и добавление функционала Modbus TCP Server, но гадать я не буду.
Про реманентность данных в логах, увы, не подскажу.
ingwar_85
15.02.2022 07:34Блин, а вот сейчас обидно было! ))
Прошу прощения, увидел вашу статью глубокой ночью и не особо вчитывался.
Кажется я копал не в ту сторону... я делал проект во вкладке NetworkProject и переключал лого в онлайн настройках в режим ведомого. На что он ругался и прикаждой загрузке прошивки просился обратно в режим мастера.
А нужно было копаться Diagram Mode. И делать всё по аналогии с вашим проектом.
Жаль теперь нет "железки" на руках.
Спасибо вам за вашу статью! Теперь мое мнение о Лого немного улучшилось.
В свое оправдание цитирую запрос в техподдержку и их ответ:Есть возможность назначить в сети LOGO! как Slave? Нужна подчинённость операторской панели. Сейчас после загрузки программы система запрашивает переход в Master.
Режим ведущий-ведомый предполагает, что ведомое лого это просто безмозглый вход-выход присоединённый к ведущему лого. Собственной программы у такого прибора нет. Доступ только к I и Q областям. Протокол зашит в Лого и описан только применительно к связке LOGO-LOGO. Для панелей такой режим незадокументирован. Работа с операторской панелью это частный случай клиент-серверной связи через S7 функции. Для этого Лого должно иметь программу а это автоматически отсекает режим «ведомый».
akcount Автор
15.02.2022 08:02Я бы приаттачил сюда сейчас картинку с престарелым мастером кунг-фу с поднятым вверх указательным пальцем, но мне, откровенно, лениво. Ведь надо вначале разобраться, что ты делаешь, потом понять, что ты делаешь не так, а лишь потом делать далеко идущие выводы.
Ладно, ворчать закончил )
Все верно, Вы копали не в ту сторону. Если я переведу свое реле FS4 в ведомый режим, то он из реле превратиться в безмозглый, как ловко подметили мои коллеги из саппорта, интерфейсный модуль для ведущего реле, а его (ведомого) программа не будет выполняться.
Превращаю в ведомого 
Программа арбайтен нихт Но стоит лишь вернуть его в режим мастера, как работа возобновляется.
И совершенно неважно, какой тип проекта Вы применяете, отдельные диаграммы или сетевой проект. И там, и там необходимо лишь сконфигурировать соответствующее соединение. Сетевой проект в этом отношении даже более нагляден.
С учетом того, что Вы юзали панель, Вам надо было сконфигурировать логу! в качестве сервера Modbus или S7... в зависимости от того, какой протокол понимает сама панель.
aborisevskiy
Молодцы Siemens, могли бы конечно и раньше. Долго они добавляют протоколы, например Modbus TCP в контроллерах S-300 только отдельными платными билиотеками, совсем не дешевыми.
Сейчас мне больше B&R нравятся, функционал мощнее намного, протоколы Modbus TCP, OPC UA - по умолчанию. Можно залить в PLC математическую модель (SimIntech, Simulink, MapleSim или просто тандарта FMI).
akcount Автор
Про Modbus TCP для трехсотой серии я в течении ближайших 2-4 недель планирую написать заметку в моем любимои стиле "автоматизация для бедных" )
aborisevskiy
В Российских компанияю любят экономить ))) "автоматизация для бедных" - это точно. Я работотал с DirectLogic, Rockwell - все на борту по умолчанию. Разный подход, американский и европейский.
shadson
Концепция уже и у S поменялась. Для современных 1200/1500 библиотеки и TCP, и RTU - бесплатные и встроенные.
aborisevskiy
да, 1200/1500 красота ))) работал, TIA Portal - супер
Siemargl
В Роквелле убрали 485 порт и модбас "по умолчанию" вместе с ним
А Прософт-модули для модбаса там еще дороже, чем у Сименса
firez
На мой взгляд, как раз американские компании самые жлобские. "Жлобее" Rockwell разве что только Emerson.
В плане документации и софта Siemens IADT самые лучшие. А вот поддержка HVAC продуктов хромает на обе ноги - всё закрыто, документацию зачастую так просто не найти.
Sergeant101
Как то не вяжутся SIEMENS и автоматизация для бедных.
akcount Автор
А Вы на цену Logo! посмотрите, причем, не "листовую", а у дистров.
andersong
В ряде случаев реализация автоматизации на Сименс получается дешевле, чем на Овен.
DmSting
Это на ЛОГО или всё-таки что-то большее, где уже PXC100 вылезают?
andersong
Серия S7-1200 недорогая и вполне функциональная. ПС: карма не позволила ответить сразу, сорри.
vakhramov
Был бы он ещё нужен, этот модбас. Всегда можно реализовать клиент-сервер посредством сокетов :)
А так наверное есть какой-нибудь драйвер для сименс, который объектную модель контроллера через API предоставляет.
akcount Автор
С частотниками Вы тоже предлагаете через сокеты общаться? )
vakhramov
Так ведь модбас/TCP (о котором в статье речь) же через сокет) В частотниках иногда есть встроенный ПЛК для таких целей.
akcount Автор
Что-то Вы все в кучу смешали.
Модбас не нужен, есть сокеты. Но модбас работает через сокеты. А в частотниках ПЛК встраивают для этого.
Вспомните модель ISO OSI. Да, многие ее не любят, но в качестве наглядного пособия - подойдет. Modbus TCP - это прикладной уровень модели. То есть, четко оговоренный формат передачи пакетов. Вы зачем-то приплетаете уровень TCP, то есть - транспортный. Можно ли организовать обмен между ПЛК на транспортном уровне? В ряде случаев можно. А для некоторых целевых систем, т.н. ПЛК или смарт-реле, такой функционал недоступен. Зато есть стандартизированный и общепринятый протокол. В данном случае - Modbus TCP.
Главное тут - общепринятость и стандартзированность.
vakhramov
чтобы организовать modbus/tcp, нужно точно иметь TCP. Как его не "приплетать" :)?
Чтобы организовать modbus/tcp - нужно этот modbus с обеих сторон поддержать. Когда решение "из коробки" поддерживает этот модбас, и особо не важна скорость - то да, как вариант. Но:
Была задача брать данные из ёкагавы и отправлять в TSDB Osi/PI SDK. Для простоты выбрал python. Чтобы использовать некоторые библиотеки - нужно чтоб подходила лицензия, и чтобы реализовать функционал со стороны узла-сборщика данных - нужно эти лицензии изучить, и это тоже работа. Это добавляется к работе по изучению маппинга регистров, ну и немного страданий с флоат значениями ))
ajratr
Сокеты это же не протокол. Всё равно необходимо установить правила обмена информацией.
Драйвера, позволяющие получить объектную модель контроллера, такое есть. Называется OPC протокол. Современная спецификация OPC UA встраивается в контроллеры. Но ещё не все контрооллеры её поддерживают.
vakhramov
)) Спасибо, я это прекрасно знаю. Про драйвер - имел ввиду то, что по 102 порту к коммуникационному процессору siemens присоединяется, или к 44818 от роквел :)
То, что торчит с контроллерной стороны OPC DA/UA/modbus и других распространённых сервисов унификации