Релиз библиотеки OwenModbusSlave для CODESYS v2.3

[Осинский Алексей]

Добрый день!
Спасибо за хорошие вопросы и предложения по модернизации.

1. В каких ситуациях поднимаются/опускаются флаги xDone и xBusy?

Действительно не раскрыл этого в описании библиотеки:
xBusy = TRUE до тех пор, пока xEnable = TRUE;
xDone = not xBusy.

4. Можно ли рассчитывать на появление в обозримом будущем подобного ФБ для TCP Slave?

На текущий момент в планах такого нет.
Уточните пожалуйста, почему использование Modbus-TCP через конфигурацию не подходит?
Нужно дублировать данные для нескольких мастер-устройств?

Вероятнее всего, в вашем ФБ в том цикле ПЛК, когда вы получаете признак того, что чтение запроса завершено, сперва производится предварительная обработка (свой ли адрес устройства, проверка CRC), и если запрос по адресу, то включается таймер задержки ответа, выполняется запрос, формируется ответ. Предлагаю сделать следующее.

1. Сделать видимой снаружи структуру типа <OMB_SlaveRecievedFrameDescription> (сделать её выходной переменной).
2. Добавить выходную переменную, например, <xReqReady : BOOL>.
3. Добавить входную переменную, например, <eCustomErr : OMB_Slave_SLAVE_BLOCK_ERROR>, которая по-умолчанию имеет значение <NO_FRAME_ERROR>.
4. После того, как сформирована структура (1), выставить флаг (2) и уйти в следующий цикл ПЛК.
5. В следующем цикле ПЛК сбросить флаг (2), проверить значение (3) и в зависимости от него выполнять/не выполнять запрос, формировать ответ.

Такой механизм позволит пользовательской программе, по признаку (2) проверить, возможно ли выполнение поступившего запроса в её частном случае, а также выполнить необходимые действия в буфере Slave непосредственно перед формированием ответа. При этом, если в данных действиях нет необходимости, то вышеуказанные переменные просто не будут им использованы при обращении к ФБ. Никаких изменений в уже написанных программах не потребуется.

Если я правильно понял идею, то цель следующая: сделать некое подобие "событий" (ниже буду называть так), обработку которого пользователь сможет запретить.
Идея мне нравится. Но есть несколько уточняющих вопросов:

2. Добавить выходную переменную, например, <xReqReady : BOOL>.

Я правильно понимаю, что эту переменную мы должны взводить только в случае, если получен корректный запрос (корректный CRC, адрес совпадает и т.д.)?
А в остальных случаях ФБ сам отвечает мастеру об ошибке (или не сообщает, если адрес не тот) не уведомляя об этом пользователя.

1. Сделать видимой снаружи структуру типа <OMB_SlaveRecievedFrameDescription> (сделать её выходной переменной).

Если я прав с вопросом о <xReqReady : BOOL>, то эта структура содержит "лишние" данные (адрес устройства мы и так знаем, CRC проверен и корректен, количество байт в запросе для обработки события пользователем не нужно).
Итого получим структуру

usiFunctionNumber			: USINT;			(* Номер функции *)
udiFirstAddress				: UDINT;			(* Номер первого регистра или бита (в зависимости от функции) *)
uiDataCount				: UINT;				(* Количество регистров или бит (в зависимости от функции) *)

Upd: хотя адрес в этой структуре может быть нужен, например, в случае, если мы хотим написать универсальную функцию реакции на запрос для всех SLAVE'ов проекта.

На сколько я понимаю при обработке события записи нам бы хотелось иметь возможность проверить данные, которые пытаются нам записать (например если диапазон корректных значений ограничен 0-3, а пытаются записать значение 4), поэтому в ту же структуру добавим

awWrittenData				: ARRAY [1..125] OF WORD;	(* Записываемые данные, если запрос на чтение - заполнено нулями *)

Но, на сколько мне известно, стандартной ошибки Modbus для такого случая нет (ILLEGAL_DATA_VALUE возвращается в случае, если № первого регистра в диапазоне допустимых значений, а № последнего - выходит за него).
Как Вы считаете, как себя должен повести Slave в таком случае?
Пока что в голову приходит 2 варианта:

1. Вернуть ответ "запрос обработан", но не записывать данные в буфер SLAVE'а (в таком случае пользователь может быть обескуражен тем, что запросы проходят, но данные не меняются);
2. Вернуть код ошибки (например, тот же ILLEGAL_DATA_VALUE), а в документации на библиотеку указать в каком случае может возникнуть эта ошибка (в таком случае пользователь опять же может быть удивлен тем, что запрашивает явно корректные регистры, но ошибка указывает, что нет).

Я запланировал эту доработку на следующую версию библиотеки.
Но, думаю, это будет отдельный ФБ:

• MB_RTU_SLAVE останется для тех, кому нужно "попроще",
• новый ФБ - для тех, кому нужна гибкость.