Добрый день. Имею систему, состоящую из нескольких датчиков, прибора сбора информации и контроля, архиватора данных. Работает это всё дело так, как показано на схеме:



Но иногда сопуствующие личности горят желанием иметь прямой доступ с компьютера (net2) к датчикам из net1. Серая штука по середине является мастером для net1 и ведомым для net2. 

Вопрос - как лучше организовать этот доступ?

Сейчас я на скорую руку сделал возможно самое чудовищное решение. Я воспользовался свободными номерами пользовательских функций. Если серый прибор получает такую функцию извне, то он преобразует её в функццию 03 (чтение регистров хранения), после получения ответа он опять его преобразовывает и отсылает обратно в net2. Такое решение мне не нравится   

Есть какие-нибудь мысли? Кто-нибудь что-то подобное делал?

Это сообщение отредактировал(а) UniBomb - 4.10.2010, 10:24

Вполне нормальное решение
чем?

xvr, даже не знаю чем. Наверное это просто придирка. Сейчас происходит вот так комп посылает команду с номером 68 и телом команды 3. Серый прибор получает её, меняет заголовок с 68 на 3 и пересылает дальше. На время ожидания ответа ничего не делает. В полученном ответе опять меняет заголовок с 3 на 68 и пересылает без изменений компу. Если это в порядке вещей, тогда нет вопросов    Я просто не знаю как это делают другие   

Вполне нормальный метод туннелирования данных. Все proxy так работают (и не только ModBus'овские   )

xvr, спасибо, успокоил   

Я извиняюсь, но почему просто не использовать стандартную 3 функцию, що позволит не городить своих специфических функций.

'Стандартная 3 функция' прочтет регистр из самой 'серой штуки' (в середине), а надо из устройства из подсети NET1

Но тогда еще вопрос: сеть NET1 - работает по протоколу ModbusTCP или ModbusRTU?

Добавлено через 7 минут и 9 секунд


А можно инфу о таких ModBus-прокси
очень интересно

1. обе сети работают по ModbusRTU. Компьютер изображен чисто условно, т.к. на его месте обычно стоять какие-нибудь ПЛК или другие части SCADA системы
2. Я же описал как это работает   

Тогда почему в серой коробке не реализовать поддержку 4-й функции по которой вы будете считывать именно из нее 
а про 3-й функции обращаться напрямую к датчикам
или наоборот - 3-я серая коробка, 4-я датчики?

Прямой связи от компьютера к датчикам нет. Есть 2 независимые MODBUS сети, первая состоит из PC и серой коробки, вторая из серой коробки и датчиков.
В принципе можно сделать серую коробку мостом, и рассматривать оба сегмента как одну MODBUS сеть. В таком случае в серой коробке нужен механизм по трансляции номеров узлов, что бы они не пересекались в полученной объединенной MODBUS сети. 
Такой подход так же имеет право на жизнь, однако трудно сказать, что будет проще реализовать - мост или прокси   

Ув. UniBomb, реализация своих функций - это хорошо для Вас как производителя(разработчика)  :dance3 , но напрочь 
лишает пользователя(заказчика)   :dash1 возможности использовать альтернативные Modbus-устройства
в которых реализован только базовый набор Modbus-функций.

Раз уж нужно реализовывать поддержку пользовательских функций в "серой" коробке, то можно поступить следующим 
образом.

Например:
1. датчики имеют адреса с 1 по 20
2. порт "серой" коробки со стороны ПК имеет адрес 111
3. порт "серой" коробки со стороны ПК имеет адрес 112
Тогда логику в коробке можно реализовать так:
Если ПК обращается к адресу 111 то это значит читает данные из самой "серой" коробки,
Если ПК обращается к адресам с 1 по 20 то "серая"коробка принимает и транслирует запросы на свой второй порт с адресом 112.
После получения ответа от датчика "серая"коробка выполняет его передачу через порта 112 на порт 111 в ПК.
Это позволит избежать использования пользовательских функций.
В случае использования нескольких "серых" коробок в одной RTU сети необходимо правильное планирование адресов, что бы не было накладок.

 :smile 

l2_mik, число разноветных и серых коробок различается от проекта к проекту. В одном проекте может быть 150-170 цветных коробочек, в другом серых нет вообще. В этом случае закрепление адресов скорее будет минусом.