Общее описание ModbusTCPMultiMaster

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

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

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

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

  \par Секция с настройками
  При своём старте, в конфигурационном файле ищётся секция с названием объекта,
  в которой указываются настроечные параметры по умолчанию.
  Пример:

<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>

channelTimeout - умолчательный timeout для переключения каналов. По умолчанию: берётся общий defaultTimeout.

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация заключается в том, что регистры идущие подряд автоматически запрашиваются/записываются одним запросом. В связи с чем, функция указанная в качестве 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 - Взять адрес, функцию и регистр для проверки связи из списка опроса

Конфигурирование списка регистров для ModbusTCP master

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

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

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

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

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

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

Предупреждения: Если в результате список будет пустым, процесс завершает работу.

Пример конфигурационных параметров:

<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_mbtype - [rtu] - пока едиственный разрешённый тип.
tcp_mbaddr - адрес RTU-устройства.
tcp_mbreg - запрашиваемый/записываемый регистр.
tcp_mbfunc - [0x1,0x2,0x3,...] функция опроса/записи. Разрешённые см. ModbusRTU::SlaveFunctionCode.

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

tcp_vtype - тип переменной. см VTypes::VType.
tcp_rawdata - [0|1] - игнорировать или нет параметры калибровки
tcp_iotype - [DI,DO,AI,AO] - переназначить тип датчика. По умолчанию используется поле iotype.
tcp_nbit - номер бита в слове. Используется для DI,DO в случае когда для опроса используется функция читающая слова (03
tcp_nbyte - [1|2] номер байта. Используется если tcp_vtype="byte".
tcp_mboffset - "сдвиг"(может быть отрицательным) при опросе/записи. Т.е. фактически будет опрошен/записан регистр "mbreg+mboffset".
tcp_pollfactor - [0...n] Частота опроса. n задаёт "часоту" опроса. т.е. опрос каждые 1...n циклов (зависит от общего polltime)

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

tcp_preinit - [0|1] считать регистр перед использованием (при запуске процесса)
tcp_init_mbfunc - Номер функции для инициализации. Если не указана, будет определена автоматически исходя из tcp_mbfunc.
tcp_init_mbreg - Номер регистра откуда считывать значение для инициализации. Если это поле не указано используется tcp_mbreg.

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

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

tcp_sm_initOK - [0|1] Игнорировать начальную инициализацию из SM (сразу писать в устройство)

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

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

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

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

emNone - нормальная работа (по умолчанию)
emWriteOnly - "только посылка данных" (работают только write-функции)
emReadOnly - "только чтение" (работают только read-функции)
emSkipSaveToSM - "не записывать данные в SM", это особый режим, похожий на emWriteOnly, но отличие в том, что при этом режиме ведётся полноценый обмен (и read и write), только реально данные не записываются в SharedMemory(SM).
emSkipExchnage - отключить обмен (при этом данные "из SM" обновляются).

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

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

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

По умолчанию используется простая установка соединения и тут же его разрыв. Т.е. данные никакие не посылаются, но проверяется что host и port доступны для подключения.
Второй способ: это проверка соединения с посылкой modbus-запроса. Для этого имеется два способа указать адрес устройства, регистр и функция опроса для проверки. Либо в секции <GateList> для каждого канала можно указать:
- адрес устройства checkAddr=""
- функцию проверки checkFunc="" - функция может быть только 01,02,03,04.
- регистр checkReg Либо в командной строке задать параметры –prefix-check-addr, –prefix-check-func, –prefix-check-reg, которые будут одинаковыми для ВСЕХ КАНАЛОВ. Помимо этого если указать в командной строке аргумент –prefix-check-init-from-regmap, то для тестирования соединения будет взят первый попавшийся регистр из списка обмена.

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