Modbus RTU и АРМ

[vinnipux]

Доброе время суток.
Используется протокол Modbus RTU
Подскажите правильно ли я думаю что для того что бы АРМ был Slave и по Ethernet-у передавал данные мастеру у которого 485 интерфейс, можно использовать любой преобразователь у которого есть виртуальный порт?

[vinnipux]

Ну вот навскидку сразу 2 примера:
http://www.multi-port.ru/catalog/Moxa/M ... teway.html

http://www.acomputer.ru/site/Site2.asp?id=66009

спасибо.
а устройство с виртуальным портом, справится с данной задачей?

[vinnipux]

например вот это устройство: http://www.moxa.ru/good/show/14883/10244/

[vinnipux]

вот порылся, нашел такой девайс http://www.moxa.ru/good/show/15801/17029/
6110 оказывается снят с производства.
Надеюсь будет работать нормально.
Если у кто работал с этим устройство, поделитесь опытом.
а так всем спасибо. Думаю тему можно закрывать.

[Наймарк Юрий]

Добрый день! У меня следующий вопрос по Modbus RTU. Есть два мастера (АРМы) и группа датчиков. Возможен ли параллельный опрос двумя мастерами этой группы слейвов?

[Jackson]

Если не будет коллизий на физическом уровне, и если драйвер связи Вы готовы затачивать руками под это дело, то возможно. Первый АРМ шлёт запрос слейву, второй АРМ этот запрос должен услышать, затем он должен услышать ответ слейва и принять данные себе.
Только Вам ещё придется как-то обеспечить взаимодействие двух АРМов, чтобы они между собой договаривались чтобы запрос слал кто-то один, а слушали оба. Причём взаимодействие это должно быть, видимо, по какому-то физически другому интерфейсу, потому что на общем для АРМов и слейвов интерфейсе АРМы будут иметь одинаковые адреса и договориться не смогут: АРМ, посылая сообщение другому АРМу, будет посылать его фактически сам себе.
В общем, проще по-моему пересмотреть структуру сети и назначит один из АРМов OPC-сервером, а второй АРМ пусть с этого сервера считывает данные.

[andrmur]

оригинальный протокол Modbus не предусматривает двух мастеров на одной линии, соответственно в протоколе нет средств разрешения коллизий.

Есть способ физического деления линии связи - ставить коммутатор портов, который блокирует один порт, пока активен другой порт. Но это кривая схема.

Лучше использовать протокол, который изначально рассчитан на режимы multi-master или produce-consume.

[Наймарк Юрий]

genelectric, спасибо за ответ.
Насчет перекрестного обмена по ОРС у меня была аналогичная мысль. В этом случае придется организовать такую же конфигурацию на втором АРМе, чтобы в случае неисправности первого АРМа, второй продолжил обмен со слэйвами.

andrmur, спасибо за ответ.

[Jackson]

Не во что.
Т.е. у Вас оба АРМа равнозначные? А тогда встречный вопрос: если Ваши АРМы обеспечивают не только сбор данных со слейвов, но еще и управление, то ведь придётся ещё и реализовать механизм передачи управления: из множества постов управления в каждый момент времени управление должно осуществляться только с одного, и должно быть понятное и простое операторам переключение между постами управления - например при помощи обычного пакетного переключателя или средствами АРМов, но по тому же принципу. Иначе с разных АРМов два разных оператора смогут послать две взаимоисключающие по техпроцессу команды. Организовывая взаимодействие между АРМами - не забыть про этот момент.
В этом смысле структура с аппаратно независимым OPC-сервером и двумя аппаратно независимыми АРМами не только более надежна, но и проста и понятна в эксплуатации, и при последующей модернизации (например если количество АРМов в будущем увеличится) не возникнет больших проблем.