Доброе время суток.
Возник вопросик по Modbus TCP.
Поискал по сети на счёт того, могут ли работать контроллеры по Modbus TCP как мульти-мастера? Во многих местах написано что протокол является multi-master, но многие утверждают обратное . Примерная задача: например (3-xx) контроллера с Modbus TCP, 1-2 панель управления c Modbus TCP, и СКАДА. Как они будут взаимодействовать между собой? Под мульти-мастера я подразумеваю то , что каждый контроллер может сам записывать или считывать данные с другого, например в случае если не будет работать панель управления и или СКАДА.
Какие могут быть подводные камни?

Все зависит от реализации стека. Количество мастеров, в принципе, не ограничено НИЧЕМ. Вопрос в корректном разборе прочитанных данных и временной синхронизации при доступе к шине. В одномастеровой сети эта проблема не стоит. Ну и тайм-аутами есть некоторые заморочки.

А сколько IP-соединений поддерживает Ваш контроллер? Многие контроллеры имеют существенные ограничения на количество соединений. Modbus TCP работает поверх IP, т.е. надо настроить IP-соединение от каждого контроллера к каждому контроллеру, от каждого контроллера к панели управления. От каждого контроллера к ПК со СКАДА. Ну и потом, сконфигурировать обмен по Modbus TCP как нужно Вашей системе.

Получается что количество "мастеров" в сети зависит только от того, сколько IP адрессов можно "вбить в контроллер"? Другими словами посылать данные можно только тем устройствам, которые прописаныв контроллере, а slave он будет всё равно? Возможна ли широковешательная посылка данных?


Какие например?

Если есть ОДИН мастер, то, инициировав обмен, он САМ отслеживает тайм-ауты при работе со слэйвом, сам распределяет времена сеансов.
Если есть несколько мастеров, то встает вопрос контроля над линией и занятости слэйва в ДРУГОМ сенасе. В Profibus DP эта проблема решалась круговой раздачей маркера на владение каналом (сказку "12 месяцев" помните?).
Можно, конечно, создать НЕСКОЛЬКО виртуальных сетей, в которых каждое устройство выступает или как Мастер или как Слзйв (неохота на английскую раскладку переключаться). Для небольшого количества устройств это "прокатывает" - скорости физ. каналов хватит.
Но вообще-то это хлопотное дело, если сами не пишите стек, а пользуетесь готовым.
Если сами пишите стек, то идея кругового маркера очень даже "катит", а создать два объекта (мастер и слэйв) на одном контроллере достаточно просто.

У Вас Modbus TCP, а не Modbus UDP. Причем тут широковещательная? В случае c PLC, IP адреса не в контроллер "забиваются", а при конфигурировании конкретного соединения указываются. Какой контроллер? Сложно говорить "в общем и целом", ggg__ggg правильно указывает, если сами реализуете стек (к примеру, РС-based контроллер используется), то сможете решить задачу как Вам хочется.

Овен ПЛК может работать как мультимастер/мультиslave. Подводный камень тут один - каждый мастер/slave требует отдельного соединения по TCP/IP. А не во всех панелях/контроллерах есть ресурсы на это.

Почитал тут инфу в интернете и что то ничего не понял на счёт стека, зачем его самому писать то?
Вот выдержки из документации:
1.Crevis NA-9189 ModBus/TCP Network Adapter:

Slave node (MODBUS/TCP Server)
8 MODBUS/TCP, 4 HTTP, BOOTP. TBD

2.Wago 750-841 ETHERNET TCP/IP Programmable Fieldbus Controller

A controller is able to produce a defined number of simultaneous socket
connections to other network subscribers:
15 connections via MODBUS/TCP (read or write input and output data
from the controller)

Получается что в 1 случае может быть 8 одновременных соединений , а во втором-15. Причём Wago может быть одновременно Master/Slave.
Я правильно понял?
Думаю проблемы начинаются только, если количество контроллеров превышает, в данном случае, эти значения.

Да Ваго около 10 соединений нормально тянет, дальше тормоза.

Про "стэк" забудьте - это Вас эмбеддеры пугают Стэк - куча кода на С++ который зашивается во флэш микроконтроллера или крутится на компе.

Не совсем так. Все эти соединения - это ЭМУЛЯЦИЯ PtP-соединения. В этой паре устройство может быть как Мастером, так и слэйвом.
Не вдаваясь в тонкости, для ТСР Вы можете создать несколько пар (соединений) как правило, ШТАТНЫМИ средствами контроллера.
Далее начинается собственно Modbus. Есть СТАНДАРТНЫЕ библиотеки работы с ним, просто на вход им суются данные, полученные из соединения, или выход с них дается на вход соединению. Вообщем, типичное "паразитирование", прозрачное для пользователя.
Просто всякие тайм-ауты (типа, устройство "сдохло") зависят от физических характеристик канала связи. Ну, еще добавляются аварии, обнаруженные библиотеками обслуживания соединения.
Есть вариант создания динамического соединения (надо- создали), но это редкость. Каждое статическое соединение требует памяти и ресурсов процессора контроллера. Они не бесконечны, да еще нужно что-то оставить для работы с программой. Этим и ограничивается максимальное количество статических соединений.
Примерно так, несколько сумбурно, но максимально упрощенно. И С++ тут не при чем....

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

Другое будет работать только в своей локальной сети с хабами и без постороннего трафика. Т.е. ценность этого "другого" стремится к нулю.

да создавайте ДИНАМИЧЕСКИЕ соединения, кто-ж мешает? Просто ОС многих контроллеров не поддерживает эту возможность - не за чем!!!
надо помнить, что Modbus - это протокол "для двоих". Возьмите 485, там надо контролировать только ОДНУ линию, и ДИНАМИЧЕСКОЕ соединение
Мастер-слэйв вообще 3 копейки стоит. Запрос - таймер - ответ. ОЧ-Чень хорошо все работает, и простенько. Хоть 1 слейв, хоть 200. Только адрес успевай менять. А ТСР несколько сложнее, хотя основная "загвоздка" - в несущем протоколе. Возьмите UDP - надежность чуть меньше (придется немного с перезапросами поколдовать), зато реализуется на порядок проще.

Что Вы понимаете под "динамическим" соединением? Открыл, послал запрос, получил ответ, закрыл =>перешёл к другому Slave? так можно, но тогда темпа опроса чаще 1 раза в секунду в сетях общего пользования не получите. Установление и закрытие соединения по TCP - процедура не мгновенная.
Плюс некоторые ModBus TCP/IP slave устройства имеют неприятную привычку впадать в безопасное состояние при закрытии соединения.
Так чта 1 сокет - 1 slave.

Из всего написанного, могу только сделать вывод, что при малом количестве устройств, замарачиватся проблемой нет смысла, всё будет работать, так сказать, само собой. Но вот при количестве оборудовании превышающий некоторый критический уровень, стоит поломать голову о назначении привилегий отдельным контроллерам, и возведении их в ранг Мастер.

Я бы сказал при малом количестве одновременных сессий, а не малом количестве устройств.

Вставлю свои пять копеек. Modbus/TCP - это архитектура клиент-сервер, а не мультимастер. Здесь явная путаница в терминологии, доставшаяся в наследство от классического Modbus.

Как правило, в контроллерах количество одновременных соединений по Modbus/TCP ограничено. То есть, к одному серверу ("слейву") может подключиться до N клиентов ("мастеров"). Где N зависит от типа контроллера (например, для WAGO 750-841, как тут справедливо указали, 15).

Если необходимо обеспечить большее количество клиентов, нужно использовать Modbus/UDP, так как UDP - транспортный протокол без установления соединения.

Вот и мне казалось что протоколы на базе изернета это все-же клиент-сервер, а не мастер-слейв.

З.Ы. Коллега qqq_qqq маркер по кругу это все-же почивший в бозе Profibus FMS

Для Модбаса это одно и то-же: мастер=клиент, сервер=слейв. Просто в случае Ethernet термины клиент и сервер используются чаще.

По стандартам Modbus IDA, на прикладном уровне между Modbus-приложениями, не зависимо от реализации, используется модель клиетн-серверного взаимодействия. На нижних уровнях все зависит от реализации. Так, например, для Modbus-RTU/ASCII на канальном уровне - метод доступа к шине Master/Slave. Так что Master/Slave и клиетн-сервер - это разные вещи.
Но, в Modbus-RTU/ASCII возможен только один клиент, поскольку только приложение мастера может инициировать обмен, а значит являтся клиентом. В остальных реализациях все зависит от реализации нижних уровней, что естественно нужно смотреть в документации. В самом Modbus TCP/IP ограничений нет.

Перечитал стандарт внимательнее, был не прав, термины относятся к разным уровням. И поэтому-же термины master/slave не применимы к Modbus-TCP.

Вполне применимы. Просто клиент/сервер практически однозначно ассоциируется с TCP. ТСР пришел в автоматизацию несколько позже Modbus'а,
актуальность проблемы доступа к шине потеряна. "Хоронить" Modbus пока не собираются, вот и пытаются "осовременить" терминологию. Думаю, принципиального отличия между master/slave и client/server нет, просто второе звучит "благообразней и моднее".

Мода тут не при чем. Просто в текущих версиях стандартов это не совсем одно и то-же: http://modbus-ida.org/specs.php

На рисунке Modbus-RTU/ASCII, в других вариантах Modbus термины master и slave встречаются только при рассмотрении совместимости с Modbus-RTU, т.к. нижний уровень там другой.

Текущие - они на то и текущие.

Клиент/сервер и мастер/слейв это совсем разные вещи.
Клиент (запросчик) просит выполнить какое-то действие у сервера. Сервер, выполнив действие может ответить клиенту (если сервис с подтверждением). Причем мы сейчас говорим о взаимодействии между програмами. По сути две программы могут крутится на одном устройстве, или на различных устройствах даже не на одной сети.
Мастер шины - это устройство, которое определяет порядок доступа к шине, тоесть устройство, дающее право кому-то говорить на шине. По сути, это обмен между узлами на шине на канальном уровне. Одна из задач канального уровня обеспечить обмен данными между узлами на одной сети.
Приложения в сетях Modbus, обменивающиеся данными между собой, не обязательно должны находится на одной шине (например Modbus RTU). Есть примеры, когда узел на Ethernet (где нет мастеров и слейвов) по Modbus TCP/IP обмениваются данными с узлами на Modbus RTU (где есть мастера) через шлюзы. Замечу, что такой обмен поддерживается самим протоколом. Клиент/серверное взаимодействие остается, а мастер/слейв остается только на Modbus RTU.