Свежие (в том числе и относительно свежие) модели программируемого реле 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.
