UniSet  2.6.0
Реализация ModbusTCP 'multi' master
  - \ref sec_MBTCPM_Comm
  - \ref sec_MBTCPM_Conf
  - \ref sec_MBTCPM_ConfList
  - \ref sec_MBTCPM_ExchangeMode
  - \ref sec_MBTCPM_CheckConnection

  @section sec_MBTCPM_Comm Общее описание ModbusTCPMultiMaster
  Класс реализует процесс обмена (опрос/запись) с RTU-устройствами,
  через TCP-шлюз. Список регистров с которыми работает процесс задаётся в конфигурационном файле
  в секции \b <sensors>. см. \ref sec_MBTCPM_Conf

  При этом для шлюза можно задавать несколько ip-адресов (см. <GateList>), если связь пропадает по
одному каналу (ip), то происходит переключение на другой канал (через timeout мсек), если пропадает
с этим каналом, то переключается на следующий и так по кругу (в порядке уменьшения приоритета, задаваемого
для каждого канала (cм. <GateList> \a priority).

  @section sec_MBTCPM_Conf Конфигурирование ModbusTCPMultiMaster

  Конфигурирование процесса осуществляется либо параметрами командной строки либо
  через настроечную секцию.

  \par Секция с настройками
  При своём старте, в конфигурационном файле ищётся секция с названием объекта,
  в которой указываются настроечные параметры по умолчанию.
  Пример:
  @code 
<MBMaster1 name="MBMaster1" polltime="200" channelTimeout="..." exchangeModeID="..">
     <DeviceList>
         <item addr="0x01" respondSensor="RTU1_Not_Respond_FS" force="0" timeout="2000" invert="1"/>
     <item addr="0x02" respondSensor="RTU2_Respond_FS" timeout="2000" invert="0"/>
     </DeviceList>
     <GateList>
        <item ip="" port="" respond_id="" priority="" force=""/>
        <item ip="" port="" respond_id="" priority="" respond_invert="1"/>
     <GateList>
</MBMaster1>
  \endcode
  - \b channelTimeout - умолчательный timeout для переключения каналов. По умолчанию: берётся общий defaultTimeout.

  Секция <DeviceList> позволяет задать параметры обмена с конкретным RTU-устройством.

  - \b addr -  адрес устройства для которого, задаются параметры
  - \b timeout msec - таймаут, для определения отсутствия связи
  - \b invert - инвертировать логику. По умолчанию датчик выставляется в "1" при \b наличии связи.
  - \b respondSensor - идентификатор датчика связи (DI).
  - \b force [1,0] - "1" - обновлять значение датчика связи в SM принудительно на каждом цикле проверки ("0" - только по изменению).
  - \b exchangeModeID - идентификатор датчика режима работы (см. MBExchange::ExchangeMode).
  - \b ask_every_reg - 1 - опрашивать ВСЕ регистры подряд, не обращая внимания на timeout. По умолчанию - "0" Т.е. опрос устройства (на текущем шаге цикла опроса), прерывается на первом же регистре, при опросе которого возникнет timeout.

  Секция <GateList> позволяет задать несколько каналов связи со Slave-устройством. Это удобно для случая, когда Slave имеет
более одного канала связи с ним (основной и резервный например).

  - \b ip -  ip-адрес
  - \b port - порт
  - \b respond - датчик связи по данному каналу (помимо обобщённого)
  - \b priority - приоритет канала (чем больше число, тем выше приоритет)
  - \b respond_invert - инвертировать датчик связи (DI)
  - \b force [1,0] - "1" - обновлять значение датчика связи в SM принудительно на каждом цикле проверки ("0" - только по изменению).
  - \b timeout - таймаут на определение отсутсвия связи для данного канала. По умолчанию берётся глобальный.
  - \b checkFunc - Номер функции для проверки соединения
  - \b checkAddr - Адрес устройства для проверки соединения
  - \b checkReg - Регистр для проверки соединения

  \par Параметры запуска

При создании объекта в конструкторе передаётся префикс для определения параметров командной строки.
  По умолчанию \b xxx="mbtcp".
  Далее приведены основные параметры:

  \b --xxx-name ID - идентификатор процесса.

  IP-адрес шлюза задаётся параметром в конфигурационном файле \b gateway_iaddr или
  параметром командной строки \b --xxx-gateway-iaddr.

  Порт задаётся в конфигурационном файле параметром \b gateway_port или
  параметром командной строки \b --xxx-gateway-port. По умолчанию используется порт \b 502.

  \b --xxx-recv-timeout или \b recv_timeout msec - таймаут на приём одного сообщения. По умолчанию 100 мсек.

  \b --xxx-timeout или \b timeout msec  - таймаут на определение отсутсвия связи
                                               (после этого идёт попытка реинициализировать соединение)
                                               По умолчанию 5000 мсек.

  \b --xxx-reinit-timeout или \b reinit_timeout msec  - таймаут на реинициализацию канала связи (после потери связи)
                                               По умолчанию timeout мсек.

  \b --xxx-no-query-optimization или \b no_query_optimization   - [1|0] отключить оптимизацию запросов

   Оптимизация заключается в том, что регистры идущие подряд автоматически запрашиваются/записываются одним запросом.
   В связи с чем, функция указанная в качестве \b mbfunc игнорируется и подменяется на работающую с многими регистрами.

  \b --xxx-polltime или \b polltime msec - пауза между опросами. По умолчанию 100 мсек.
  \b --xxx-checktime или \b checktime msec - пауза между проверками связи по разным каналам. По умолчанию 5000 мсек.
    Если задать <=0, то каналы будут просто переключаться по кругу (по timeout-у) в соответсвии с приоритетом (см. <GateList>).
    Если >0, то происходит проверка связи (раз в checktime) по всем каналам (см. <GateList>) и в случае потери связи,
    происходит переключение на следующий канал, по которому связь есть.

  \b --xxx-initPause или \b initPause msec - пауза перед началом работы, после активации. По умолчанию 50 мсек.

  \b --xxx-force или \b force [1|0]
   - 1 - перечитывать значения входов из SharedMemory на каждом цикле
   - 0 - обновлять значения только по изменению

  \b --xxx-persistent-connection или \b persistent_connection - НЕ закрывать соединение после каждого запроса.

  \b --xxx-force-out или \b force_out [1|0]
   - 1 - перечитывать значения выходов из SharedMemory на каждом цикле
   - 0 - обновлять значения только по изменению

  \b --xxx-reg-from-id или \b reg_from_id [1|0]
   - 1 - в качестве регистра использовать идентификатор датчика
   - 0 - регистр брать из поля tcp_mbreg

  \b --xxx-heartbeat-id или \b heartbeat_id ID - идентификатор датчика "сердцебиения" (см. \ref sec_SM_HeartBeat)

  \b --xxx-heartbeat-max или \b heartbeat_max val - сохраняемое значение счётчика "сердцебиения".

  \b --xxx-activate-timeout msec . По умолчанию 2000. - время ожидания готовности SharedMemory к работе.

  \b --xxx-check-func [1,2,3,4]   - Номер функции для проверки соединения
  \b --xxx-check-addr [1..255 ]   - Адрес устройства для проверки соединения
  \b --xxx-check-reg [1..65535]   - Регистр для проверки соединения
  \b --xxx-check-init-from-regmap - Взять адрес, функцию и регистр для проверки связи из списка опроса

  @section sec_MBTCPM_ConfList Конфигурирование списка регистров для ModbusTCP master
  Конфигурационные параметры задаются в секции <sensors> конфигурационного файла.
  Список обрабатываемых регистров задаётся при помощи двух параметров командной строки

  \b --xxx-filter-field  - задаёт фильтрующее поле для датчиков

  \b --xxx-filter-value  - задаёт значение фильтрующего поля. Необязательный параметр.

  \b --xxx-statistic-sec sec - при наличии выведет кол-во посланных запросов за этот промежуток времени.

  \b --xxx-set-prop-prefix [str] - Использовать 'str' в качестве префикса для свойств.
                                  Если не указать 'str' будет использован пустой префикс.

  Если параметры не заданы, будет произведена попытка загрузить все датчики, у которых
  присутствуют необходимые настроечные параметры.

  \warning Если в результате список будет пустым, процесс завершает работу.

  Пример конфигурационных параметров:
<sensors name="Sensors">
...
<item name="MySensor_S" textname="my sesnsor" iotype="DI"
tcp_mbtype="rtu" tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x02" my_tcp="1"
/>
...
</sensors>
Предупреждения
По умолчанию для свойств используется префикс "tcp_". Но если задано поле filter-field, то для свойств будет использован префикс "filter-fileld"_. При этом при помощи –xxx-set-prop-prefix val можно принудительно задать префикс. Если просто указать ключ –xxx-set-prop-prefix - будет использован "пустой" префикс (свойства без префикса). Префикс должен задаваться "полным", т.е. включая _(подчёркивание), если оно используется в свойствах (например для "tcp_mbreg" должен быть задан –xxx-set-prop-prefix tcp_ ).

К основным параметрам относятся следующие (префикс tcp_ - для примера):

Помимо этого можно задавать следующие параметры:

Для инициализации "выходов" (регистров которые пишутся) можно использовать поля:

Если указано tcp_preinit="1", то прежде чем начать писать регистр в устройство, будет произведено его чтение.

По умолчанию все "записываемые" регистры инициализируются значением из SM. Т.е. пока не будет первый раз считано значение из SM, регистры в устройство писатся не будут. Чтобы отключить это поведение, можно указать параметр

При этом будет записывыться значение "default".

Предупреждения
Регистр должен быть уникальным. И может повторятся только если указан параметр nbit или nbyte.

Управление режимом работы MBTCPMultiMaster

В MBTCPMultiMaster заложена возможность управлять режимом работы процесса. Поддерживаются следующие режимы:

Режимы переключаются при помощи датчика, который можно задать либо аргументом командной строки –prefix-exchange-mode-id либо в конф. файле параметром exchangeModeID="". Константы определяющие режимы объявлены в MBTCPMultiMaster::ExchangeMode.

Проверка соединения

Для контроля состояния связи по "резервным" каналам создаётся специальный поток (check_thread), в котором происходит периодическая проверка связи по всем "пассивным"(резервным) в данный момент каналам. Это используется как для общей диагностики в системе, так и при выборе на какой канал переключаться в случае пропажи связи в основном канале. Т.е. будет выбран ближайший приоритетный канал у которого выставлен признак что есть связь. Период проверки связи по "резервным" каналам задаётся при помощи –prefix-checktime или параметром checktime="" в конфигурационном файле. В MBTCPMultiMaster реализовано два механизма проверки связи.

Предупреждения
Способ проверки при помощи "modbus-запроса" имеет ряд проблем: Если фактически производится обмен с несколькими устройствами (несколько mbaddr) через TCP-шлюз, то может быть "ложное" срабатвание, т.к. фактически состояние канала будет определяться только под связи с каким-то одним конкретным устройством. И получается, что если обмен ведётся например с тремя устройствами, но проверка канала происходит только по связи с первым, то если оно перестанет отвечать, это будет считаться сбоем всего канала и этот канал будет исключён из обмена (!). Если ведётся обмен только с одним устройством, такой проблеммы не возникает. Но к плюсам данного способа проверки связи ("modbus-запросом") является то, что соедиенение поддерживается постоянным, в отличие от "первого способа" при котором оно создаётся и сразу рвётся и если проверка настроена достаточно часто ( < TIME_WAIT для сокетов), то при длительной работе могут закончится дескрипторы на создание сокетов.