Связи S7 лет уже много. И многие про него знают тоже много. И даже много используют. Работать с ними весьма легко - создал S7 connection, разместил, где надо, функциональные блоки PUT/GET (самый простой вариант) или BSEND/BRECEIVE, выполнил download, и все - полный превед, знай только, контролируй состояние флагов NDR и Error.

Чаще всего оба коммуникационных партнера находятся в одной сети. А что делать, если CPU находятся в разных сетях Profinet? Или, еще круче, один участник обмена подключен к некоему промежуточному узлу по Profinet, а второй - к этому же промежуточному узлу по Profibus.

В данной заметке рассмотрим функционал, появившейся в «прошивке» 2.8 (поддерживается в Step 7 версии 16 и выше) серии контроллеров S7-1500, а именно — перенаправление (форвард) ip-пакетов между интерфейсами.

Классические линейки контроллеров Siemens, а именно — Simatic S7-300 и Simatic S7-400, поддерживают протокол Modbus TCP как в качестве клиента, так и в качестве сервера. Эта поддержка не лишена одного существенного недостатки, она платная, и стоимость лицензии весьма высока.

Если заказчик — «богатый», а интегратор — «умный» (опытный), то факт платности лицензии и ее стоимость не приводит к неприятностям, все известно заранее, на этапе составления спецификации, бюджет согласован заранее. Если применяется серия S7-1200 / 1500, то вопрос даже не поднимается, эти PLC поддерживают Modbus RTU и TCP без дополнительного лицензирования.

На практике встречаются случаи, когда ничто не «предвещало беды», но модбас на «трехсотнике» неожиданно становится нужен (никогда такого не было, и вот опять!). Не учли что-нибудь, форс-мажор или просто разгильдяйство. Какие в этом случае пути решения?

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

Disclaimer. Написанное относится к 16ой версии и публикуется очень запоздало. В версии 17 функционал был расширен, и добавлена возможность мигания как минимум динамическим диалогом свойства background color.

Свежие (в том числе и относительно свежие) модели программируемого реле Logo! от компании Siemens поддерживают передачу данных по протоколу Modbus TCP как в качестве клиента, так и в качестве сервера. К ним относятся модули версий 8.1 & 8.2 (FS4) и 8.3. В настоящей заметке рассматривается простой вариант с использованием circuit diagram, сетевой проект не используется. В качестве среды разработки применяется LOGO!Soft Comfort версии 8.3.0.

-Нам срочно нужна связь

-Половую предложить не могу!

(с) Звездные Войны. Буря в стакане. Студия "Божья Искра" (ст. о/у Goblin)

Году эдак в 2011 я на правах фрилансера написал и внедрил ПО для управления водонапорной станцией. По итогам система получилась распределенной и даже немного сложной, но начиналось все с локальной станции управления одной насосной установкой.

Проектная организация заложила CPU Simatic S7-313C. Неожиданно мне стало интересно, как это будет выглядеть на новой линейке Simatic? Влезет ли прикладная программа, легко ли она портируется? Сколько стоит решение - внедренное ранее и выбранное мной сейчас?

Обнаружил в базе знаний Siemens (SIOS) интересный пример использования контроллеров линейки S7-1200 и S7-1500 в качестве клиента протокола MQTT

Ссылка на первоисточник.

Попробуем разобраться?

S7-соединения, применяемые для обмена информацией между устройствами серии S7-300, 400, 1200, 1500, являются конфигурируемыми. Это означает, что необходимо явно указать устройствам, кто с кем общается. В общем случае эти соединения являются двунаправленными (двухсторонними или же bilaterally), т.е. добавление конфигурируемого соединения происходит для обоих ПЛК, что приводит к необходимости прогрузки обоих ПЛК. Это не вызывает особенных проблем, если оба ПЛК находятся в ведомстве службы АСУТП предприятия, и для обоих ПЛК есть на руках актуальное прикладное ПО. Но встречаются и частные случаи — необходимо наладить обмен между «старым» S7-300 и «новым» S7-1500, причем, исходники старой программы утрачены. Ну, или эксплуатация просто боится трогать ПЛК. Или эксплуатации просто нет, задача организации обмена «висит» на интеграторе «новой» системы, что приводит к предыдущему условию — трогать ППО неизвестной системы никому особо не хочется.

Давно хотел рассказать про тонкости программирования обмена по протоколу Modbus RTU в случае, когда контроллер (в нашем случае S7-1214) выступает RTU Master'ом. Недавно меня попросили помочь с обменом между ПЛК и частотным преобразователем Sinamics V20, ну и почему бы не написать заодно заметку, постаравшись приблизить решение задачи к боевым условиям.

Продолжаем тему программирования протокола Modbus TCP на контроллерах Simatic S7-1500. В прошлый раз речь шла о серверной части, сегодня опишем клиентскую. Клиент Modbus TCP — это узел, который генерирует запросы к серверу, т.е. запрашивает данные и передает уставки/команды. В терминологии Modbus RTU это «мастер», ведущее устройство. В отличии от RTU, в протоколе TCP может быть несколько «мастеров» (правильно — клиентов).

Первая спецификация протокола Modbus была опубликова в 1979 году. Протокол предназначен для опроса подчиненных устройств по принципу «запрос-ответ». Modbus RTU (Remote Terminal Unit) работает по последовательному интерфейсу передачи данных (RS-232, RS-485, RS-422). Сегодня речь пойдет о немного измененном протоколе, Modbus TCP, работающий на прикладном уровне стека протоколов TCP/IP.

Для начала посмотрим, как настраивается (программируется, если быть точнее) серверная часть. Modbus TCP Server — аналог Modbus RTU Slave, то есть, является подчиненным устройством. Это важно, не путайте. Сервер лишь отвечает на запросы, но не генерирует их.

В данном примере применяется CPU S7-1516 с версией прошивки 2.6. Серия S7-1200 программируется аналогично.

Протокол OPC UA (https://ru.wikipedia.org/wiki/OPC_UA) появился впервые в контроллерах Simatic во второй версии прошивки и в Step 7 версии 14. Тогда контроллер можно было настраивать только в качестве OPC UA - сервера, то есть ПЛК мог отвечать на запросы и отдавать данные, но не мог сам инициировать связь и опрашивать других участников сети.

Радикально ситуация меняется в ноябре-декабря 2018 года с выходом прошивки 2.6 и Step 7 версии 15.1. Появляется возможность настроить CPU в качестве OPC UA клиента. А это, в свою очередь дает нам возможность организовать защищенный канал обмена информацией машина-машина (контроллер-контроллер).

Начиная с версии 4.4 операционной системы контроллеров линейки S7-1200 появилась возможность опрашивать их по протоколу OPC UA. В настоящий момент времени поддерживается только серверная часть (ПЛК может отвечать на запросы клиентов), клиентская часть — не поддерживается.

В настройке OPC UA сервера на S7-1200 есть отличия от S7-1500.

Скачивая недавно с сайта winccoa.com установщик последнего патча версии 3.17, с некоторым удивлением, постепенно перешедшим в ликование, обнаружил, что список поддерживаемых дистрибутивов Linux расширился и до Debian. Дело в том, что посмотреть на работу системы в ОС, отличной от Windows, мне хотелось давно, но из всех дистрибутивов Linux я более-менее понимаю только Debian, а привыкать к новому ради баловства откровенно не хотелось. Собственно, и под Debian установка проходит не сильно гладко.

Итак, надоело! Даже, не так, ДОСТАЛО! А точнее, за.... Впрочем, не буду прибегать к ненормативной лексике. Квартира, купленная 2.5 года назад - это не квартира, а какое-то вечное испытание. Да такое, что Форт Баярд отдыхает. Кроме того, в конце игры Баярда можно нехило поднять золотишка, а чем тут все закончится - я еще не знаю. Недостаточная (ниже норм, утвержденных Правительством РФ, а эти нормы, скажем так, разрабатывались моржами) температура воздуха в помещении, отсутствие горячей воды по утрам, а ежедневное принятие душа превращается в соревнование "кто быстрей", ибо вода неожиданно может стать кипятком. Или, наоборот, льдом. Бездействие управляющей компании, сбор инициативной группы, объявления по подъездам, коллективная жалоба... это и многие другие веселые подробности останутся за рамками повествования.

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

В рамках базового курса в системе WinCC OA используются только внутренние переменные системы. Никаких внешних подключений не предполагается. Однако, слушатели базового курса всегда под завершение учебы просят продемонстрировать, как же считать переменную с «настоящего живого ПЛК». Поскольку WinCC OA относится к продуктам компании Siemens, то логичным будет продемонстрировать подключение к контроллеру компании Siemens и чтению с него нескольких переменных. В нашем случае будем подключаться к PLC серии S7-1200.

Набор драйверов WinCC OA включает в себя два вида драйверов для контроллеров Simatic — это s7 и s7plus. Разница в них следующая: s7 предназначен для связи с ПЛК классической серии S7-300 / S7-400, а s7plus — для современной линейки S7-1200 / S7-1500. Драйвер s7plus указывается при установке отдельно. Он может отсутствовать в вашей системе, если вы его не устанавливали. Вне зависимости от того, какой используется драйвер (хоть iec104), общие принципы сохраняются. Необходимо в консоли добавить соответствующий драйвер. Далее сконфигурировать соединение с устройством и задать этому соединению номер добавленного драйвера, активировать. Так же требуется на DPE навесить конфиг Periphery Address и выполнить настройки, указав корректный адрес переменной.

Для начала необходимо прописать в консоли драйвер. Технически добавление драйвера в систему не отличается от добавления менеджера. Откроем консоль, нажмем в ней Append a new manager

В процессе создания модели поведения клапанов мы создали (и в прошлой части модифицировали его) скрипт Model, в котором было несколько вызовов dpConnect и несколько callback-функций. Тогда я писал, что это «быстрый, но неправильный способ». Эта пауза была необходима, чтобы предварительно ознакомиться с функцией dpQuery. Предлагаю вернуться немного назад и реализовать модель медленно и очень занудно правильно, теперь при помощи функций семейства dpQueryConnect. Откроем наш скрипт Model.

Оживим уже созданную (но пустую) панель Trends графиком изменения переменной во времени. Однако, перед тем, как смотреть на тренды, их необходимо сконфигурировать и каким-то образом задать значения, чтобы они скопились в базе данных. Необходимо, чтобы в системе была переменная, которая меняла свое значение. Необходимо повесить соответствующий конфиг на эту переменную, чтобы значения складывались в архив. Для типа точек данных Flap у нас есть DPE с названием Flow (расход) и типом int. Этот DPE и будем использовать для ознакомления с трендами. Для имитации поведения системы у нас уже есть созданный control-скрипт Model. Предлагаю его и использовать для иммитации расхода. Откроем скрипт Model