В предыдущей заметке (https://habr.com/ru/post/651329/) был затронут вопрос организации связи программируемого реле Logo! компании Siemens по протоколу Modbus TCP. В том примере применялись отдельные диаграммы для каждого устройства. Кроме режима диаграмм Logo!Soft Comfort предоставляет возможность создания т.н. «сетевых проектов» (network projects).

Сетевые проекты, с моей точки зрения, гораздо нагляднее в части обмена информации между узлами, включая «не логовские» устройства, что в большей мере соответствует концепции Totally Integrated Automation компании Siemens. С другой стороны, в настоящий момент применение сетевых проектов ограничено — в них невозможно использование языка LAD, а так же создание пользовательских функций (User Defined Functions). Вряд ли это можно считать существенным недостатком, но найдутся и недовольные.

Сделаем допущение. В сети находятся два реле Logo! — версии FS4 и 8.3, а так же сервер протокола Modbus TCP. Предположим, что сервер — это устройство чтения дискретных входов на 16 каналов, информация предоставляется, как digital inputs, номера входов лежат в диапазоне от 0 до 15. Если активны входа 0 и 1 одновременно, то мы включаем локальный выход 1 (Q1). Посколько такого устройства у меня по факту нет, обойдемся симуляцией на ПК. Модули Logo! выполняют роль клиентов протокола и считывают данные с сервера.

Запускаем Logo!Soft Comfort и переходим на вкладку Network

Добавляем два реле — версии 8.1/8.2 (FS4) и версии 8.3, все, как в прошлый раз. Сразу задаю ip-адрес и убираю Default Gateway, я не собираюсь выпускать эти девайсы в сеть, даже через NAT.

Получаем вот такую структуру

Не помешает еще добавить и сервер протокола Modbus TCP. Добавляется он точно так же, но выбирать необходимо Modbus-совместимое устройство

Картина теперь выглядит следующим образом

Внизу каждого устройство я выделил красным ряд прямоугольников. Это ничто иное, как логические соединения. В верхней части зеленым у нас «физика», внизу — «логика». Поскольку в ТЗ указано, что два лого! должны быть клиентами одного сервера, то «хватаеся» мышью на один из прямоугольников реле и тыщим до прямоугольника сервера модбас. Весь цЫмез тут заключается в том, что тянем линию мы от клиента до сервера. Если тянем от лого до модбас, то лого будет клиентом, а модбас — сервером. Наборот тоже справедливо.

Двойной клик на соединении вызывает окно со свойствами этого коннекшена и списком читаемых/записываемых переменных (второй способ организации обмена, описанный в предыдущей заметке).

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

Вернем все, как было. Сделаем два соединения к одному серверу. Обратите внимание, что когда вы создаете соединение между логой версии 8.3, вы получаете предупреждение, что создание коннекшена откроет соответствующие порты TCP (права доступа). По умолчанию эти порты закрыты.

Смотрим, что получилось

Два соединения «наложились» друг на друга. Для удобства не помешает их растащить.

Теперь совсем другое дело. Смотрим еще раз на свойства обоих соединений и прописываем переменные. На этот раз читать будем в область памяти V. 16 дискретных входов, начиная с нулевого читается в область памяти V, начиная со смещения 0.0. Unit ID сервера не трогаем (но как я говорил в прошлый раз, многое зависит «от», есть реализации серверов, чувствительных к этому ID), порт по умолчанию 502. Стартовый адрес дискретного входа сервера у нас выставляется 1. Ноль выставить невозможно. Опять же, надо внимательно смотреть карту регистров сервера. Как я писал в прошлый раз, нередко возникает путаница между номером и адресом регистра/дискрета.

Располагаем теперь прочитанные переменные (область V) на диаграмму реле. Для их чтения (и записи) необходимо использовать блоки типа Network input.

В свойствах блока указываем использование памяти локальных переменых (VM) и указываем абсолютный адрес, с 0.0 по 1.7. И так 16 раз. Вывод блока network input замыкаем на заглушку Open connector. Удаленные входы 0 и 1 уходят на блок «И», выход которого замыкается на Q1, в соответствии с ТЗ.

Чтение данных с сервера Modbus TCP выполняеся успешно.

Теперь переходим к свойствам соединения по Modbus TCP для второго реле, версии 8.3. По умолчанию задается порт 503 (очевидно, как порт, следующий за 502). Тут очень много зависит от реализации сервера, от того, позволяет ли сервер Modbus множественные подключения к одному порту TCP. В данном случае полагаем, что сервер дает нам такую возможность и правим 503 на 502. Так же добавляем список читаемых переменных, по аналогии с первым реле.

Копируем диаграмму с реле FS4 в реле 8.3, загружаем и убеждаемся в работоспособности.

Таким образом мы проверили работоспособность протокола Modbus с использованием сетевых проектов среды Logo!Soft Comfort.