Здравствуйте!
Реализую обмен по Modbus RTU посредством ФБ OCL.COM_Control и OCL.MB_SerialSlave.
Подскажите, пожалуйста, каким образом организовать работу 2-х экземпляров MB_SerialSlave с разными адресами usiSlaveId на одном порту COM_Control?
Вид для печати
Здравствуйте!
Реализую обмен по Modbus RTU посредством ФБ OCL.COM_Control и OCL.MB_SerialSlave.
Подскажите, пожалуйста, каким образом организовать работу 2-х экземпляров MB_SerialSlave с разными адресами usiSlaveId на одном порту COM_Control?
Добрый день.Цитата:
Сообщение от RamesIV
Два экземпляра не нужны.
Достаточно одного экземпляра с usiSlaveId = 255. Он будет отвечать на запросы с любым адресом.
Организовать "эмуляцию" именно двух конкретных устройств - возможности нет.
Ясно. Спасибо!
Я сейчас уже успешно организовал эмуляцию работы двух модулей - дискретного ввода на 16 каналов и дискретного вывода на 16 каналов.Цитата:
Сообщение от Евгений Кислов
Благо - у них не пересекается адресация регистров. Я не имитировал всю информацию. Только состояние самих вводов и выводов, без счётчиков и прочего.
Работает.
На данный момент думаю, как можно всё же запихнуть в имитатор два устройства с одинаковой адресацией регистров. Пока что в голову приходит только банить все Айдишники кроме одного, ждать, пока от запросит инфу, скормить ему заранее подготовленный буфер данных, и дальше переходить к следующему айдишнику, баня все остальные.
Да, работать будет с задержками, но для небольшого количества устройств может проканать, мне кажется.
В идеале, конечно, было бы неплохо доработать блок OCL.MB_SerialSlave таким образом, чтоб он самостоятельно по АйДи запроса переключался на нужную область памяти.
Эту опцию, например, можно сделать отключаемой, но кому надо - смогут организовать имитацию работы реальных устройств для удобной отладки на виртуальном контролере.
Кому надо - могут все сделать самостоятельно, как вы и упомянули.Цитата:
но кому надо
У блока есть выход stRequestInfo.
В рамках имитатора - порядок запросов от мастера должен быть предсказуем.
Поэтому получив информацию о текущем запросе - можно понять, какой будет следующим, и своевременно записать в регистры слэйва нужные значения.
Никаких задержек это не должно создавать.
Добавлять в библиотеку крайне специфический функционал ради пары человек, которые по каким-то причинам не используют для имитации слэйвов готовое ПО типа MasterOPC Universal Modbus Server - не выглядит перспективной задачей.
Я успел обратить внимание на то, что при попытке записать в общую область памяти данные для конкретного fbModbusSerialSlave.stRequestInfo.usiSlaveId по триггеру xNewRequest - я получаю смещение ровно на один адрес.Цитата:
Сообщение от Евгений Кислов
То есть - прибор с адресом 21 получает инфу, предназначенную для прибора с адресом 20. И так далее. Я понимаю, что это происходит так:
ФБ получил запрос от адреса 20, отдал ему данные, обновил переменную Id на 20, вернул управление основному циклу.
А уже основной цикл, увидев число 20 радостно записал в общий буфер данные для 20 адреса, хотя уже поздно это делать.
И на следующем вызове эти данные достались прибору с адресом 21.
Но вот предположить, что запросы от мастера всегда будут приходить в строгом порядке, я почему-то не мог. Раз так - это полностью решает проблему имитации нужного количества модулей :)
Конечно же, я в первую очередь для имитации попытался использовать MasterOPC Universal Modbus Server. Вы неоднократно его упоминаете в видео и тут на форуме. Но.Цитата:
Сообщение от Евгений Кислов
Чтоб сымитировать событие на вводе нужно:
1) щёлкнуть по нужному тегу,
2) щёлкнуть для открытия диалога ввода нового значения,
3) ввести новое значение
4) подтвердить ввод
Очень много действий для такой маленькой операции. И это не самое главное в целом, хоть и очень неудобно.
Вот конкретно мой пример:
У меня есть 7 компонентов и весы. Контролер должен включать поочерёдно шнеки, чтоб насыпать в весы нужную дозу по рецепту.
Весовой модуль уже находится в работе. Я написал в Кодесис его имитатор, который по нажатию кнопки транслирует в сом порт постепенно увеличивающийся вес.
И вот для имитации работы всего проекта мне нужно:
Открыть кодесис1, запустить отладку проекта
Открыть кодесис2, запустить имитацию работы весового модуля
Открыть Мастеор ОПС для имитации модулей ввода вывода.
Далее в Кодесис1 я нажимаю "взвесить",
мне срочно нужно кинуться в ОПС, чтоб сымитировать ответную реакцию первого контактора,
потом метнуться в Кодесис2, чтоб запустить имитацию набора веса
Когда в Кодесис1 вес подойдёт к переключению на следующий шнек - мне нужно снова побежать в ОПС, остановить первый контактор
Потом в Кодесис2 остановить набор веса,
потом в ОПС сымитировать ответ второго контактора
и снова в Кодесис2 запустить набор веса.
И при всём при этом мне одним глазом нужно следить, собственно, за отладочными параметрами :))))
Ну у меня же всего же две руки же же. Я посидел так пару вечеров, и нервы мои иссякли, потому что я постоянно либо путал, что там надо включить и получал ошибку, либо не успевал в тайминги.
Плюс, у меня начинают уплывать в космос все измеряемые скорости насыпания... В общем, отладка в динамике меня сильно вымотала.
Отныне у меня будет так:
В кодесис1 крутится проект с отладкой,
в кодесис2 крутятся сразу и имитатор весового модуля, и оба модуля ввода-вывода.
Так как они находятся в одном проекте - весовой модуль сможет совершенно автоматически заупускаться и останавливаться в зависимости от состояния выходов модуля выводов.
И я наконец-то смогу сконцентрироваться на отладке, не мороча голову лишними телодвижениями :)
А, и бонусом - я могу расположить все кнопки визуально так, как они расположены на заводе, а не просто в столбик, чтоб не искать их глазами каждый раз.
В общем - может, тех, кому надо, и мало, но мы в тельняшках :)
И большое спасибо за вчерашнюю наводку про общее адресное пространство и за сегодняшнюю про строгий порядок опроса. Очень ценная информация :)
Нидвораич, если ваш отладчик написан на ST, можете прислать код посмотреть?
на St. Сейчас, немного причешу описание и пришлю
F7 и производные позволяют создать динамику?