Здравствуйте.
Цитата Сообщение от Осинский Алексей Посмотреть сообщение
На текущий момент в планах такого нет.
Уточните пожалуйста, почему использование Modbus-TCP через конфигурацию не подходит?
Нужно дублировать данные для нескольких мастер-устройств?
С дублированием данных для разных Master в Modbus-TCP как раз проблем нет: Достаточно добавить в Modbus[FIX] ещё один подмодуль TCP и указать в параметрах другой порт. Я пару лет назад так делал, у меня работало. Проблемы в другом:
1. Необходимо запретить выполнение команд записи в определённые адреса (регионы адресов).
2. Необходима проверка (кастомная) записываемых величин на корректность. Например, целое по адресу 444 может быть исключительно в диапазоне, определяемом значениями в адресах 222 и 223.
3. Бывают ситуации, когда данные, выставляемые в Slave могут быть результатом достаточно тяжёлых вычислений (например, сумма медленносходящегося ряда). В таких случаях готовить их каждый цикл не слишком здорово, хотелось бы выполнять подобные операции только тогда, когда на них есть запрос от Master.
Цитата Сообщение от Осинский Алексей Посмотреть сообщение
Если я правильно понял идею, то цель следующая: сделать некое подобие "событий" (ниже буду называть так), обработку которого пользователь сможет запретить.
Идея мне нравится. Но есть несколько уточняющих вопросов:
В принципе, можно это назвать обработкой события. Смысл в том, чтобы дать возможность пользовательской программе сделать дополнительные действия непосредственно перед выполнением запроса вашим ФБ.
Цитата Сообщение от Осинский Алексей Посмотреть сообщение
Я правильно понимаю, что эту переменную мы должны взводить только в случае, если получен корректный запрос (корректный CRC, адрес совпадает и т.д.)?
А в остальных случаях ФБ сам отвечает мастеру об ошибке (или не сообщает, если адрес не тот) не уведомляя об этом пользователя.
Да.
Цитата Сообщение от Осинский Алексей Посмотреть сообщение
Если я прав с вопросом о <xReqReady : BOOL>, то эта структура содержит "лишние" данные
Я предложил сделать видимой структуру <OMB_SlaveRecievedFrameDescription> потому что это упрощает как вашу задачу, так и работу модернизированного ФБ, нет необходимости создавать новые структуры и в них что-то копировать. Если же вы решите создать отдельную структуру, то перечисленного вами достаточно.
Кстати, в вашей структуре <pRequestData> это указатель на буфер целиком или же только на данные запроса?
Цитата Сообщение от Осинский Алексей Посмотреть сообщение
Но, на сколько мне известно, стандартной ошибки Modbus для такого случая нет (ILLEGAL_DATA_VALUE возвращается в случае, если № первого регистра в диапазоне допустимых значений, а № последнего - выходит за него).
Как Вы считаете, как себя должен повести Slave в таком случае?
Пока что в голову приходит 2 варианта:

Вернуть ответ "запрос обработан", но не записывать данные в буфер SLAVE'а (в таком случае пользователь может быть обескуражен тем, что запросы проходят, но данные не меняются);
Вернуть код ошибки (например, тот же ILLEGAL_DATA_VALUE), а в документации на библиотеку указать в каком случае может возникнуть эта ошибка (в таком случае пользователь опять же может быть удивлен тем, что запрашивает явно корректные регистры, но ошибка указывает, что нет).
Я предложил добавить входную переменную <eCustomErr : OMB_Slave_SLAVE_BLOCK_ERROR> для того, чтобы пользователь сам решил, какой код ошибки должен быть передан, если запрашиваемая операция по его мнению невозможна (естесственно, в пределах значений от 0..3). Ваш ФБ получает данное значение в следующем цикле ПЛК и продолжает как ни в чём не бывало (0) или же формирует ответ об ошибке (1..3). Всё остальное исключительно на совести пользователя. Если значение за пределами (0..3) то можно поступить на ваше усмотрение: либо считать это (0), либо просто не отвечать мастеру. Мне же встречались устройства, которые на попытку записать в адреса, предназначенные только для чтения возвращали как ILLEGAL_FUNCTION так и ILLEGAL_DATA_ADDRESS.
Спасибо, что откликнулись на предложение.