Вход

Просмотр полной версии : Много разных устройств на RS-485



Boris_K
27.10.2014, 12:20
Вынужден вешать на RS-485 много разных устройств различных производителей, большинство из которых работают по собственным протоколам (так что всё приходится опрашивать программно), при этом настройки связи у многих совпадают (9600-8-n-1 - самая распространённая). Устройства опрашиваются по очереди (то есть ПЛК посылает запрос в сеть, ждёт нужный таймаут и затем читает ответ, после чего опрашивает следующее устройство).

Получается, запросы и ответы "слышат" все устройства, и отвечает на них одно нужное устройство только потому, что формат запроса для него не понятен для других устройств, и они молчат. Но что делать если попадётся девайс с таким протоколом, запросы или ответы по которому будут выглядеть корректными ещё каким-то устройствам в сети, в результате они начнут что-то отвечать одновременно с другим устройством, и в сети получится мусор. Как в общем случае избежать этого?

Приходит на ум некий "разветвитель" сети RS-485, который бы имел один входной модуль RS-485 (подключаемый к ПЛК), и много выходных, не связанных друг с другом сетей RS-485, для подключения устройств. ПЛК бы направлял во входной модуль, в соответствии с некими правилами, набор запросов, которые нужно отослать в каждую из выходных сетей, разветвитель бы их рассылал, принимал бы ответы в каждой сети, затем весь этот набор ответов (разделённый в соответствии с некими правилами) отправлял бы в ПЛК. Почему нет ничего подобного? Это же общая проблема, возникающая при автоматизации?

melky
27.10.2014, 12:22
адресов у устройств нет чтоли ?

Boris_K
27.10.2014, 12:26
У кого есть, у кого нет, они все разных производителей, с собственными протоколами.

melky
27.10.2014, 12:52
Есть Ethernet - несколько портов 232 или 485, но будет ли оно работать с ПЛК ?

Поизучайте документацию на 7513 - http://insat.ru/prices/info.php?pid=795

Boris_K
27.10.2014, 14:14
Поизучал, вроде то что нужно, но нигде не написано в какой конкретно форме он должен принимать запросы, собирать данные и формировать ответ, какова вообще его логика работы и протокол обмена. Не написано нигде, в том числе на оф.сайте (http://www.icpdas.com/index.php)

melky
27.10.2014, 14:25
Тут только запрос в техподдержку поможет. Указано, что может работать в 2-х режимах, хаб и повторитель.
Попробуйте инсат помучать по данному вопросу.

Boris_K
27.10.2014, 14:32
Странно что такую, самую необходимую информацию, они не представили. Без неё просто непонятно, как эта хрень вообще работает. Остаётся техподдержку мучать.

melky
27.10.2014, 15:03
Ну например может работать так как предусматривает Modbus, до 247 устройств с указанием адресации на каждой ветке хаба. Типа вы не сможете опрашивать устройство без адреса.
А может и иначе.

Yegor
27.10.2014, 15:46
Почему нет ничего подобного? Это же общая проблема, возникающая при автоматизации?В RS-сетях нет задела для различения протоколов верхнего уровня как, например, в IP-стеке. Если в гирлянде больше одного протокола, то каждый колхозит под свою ответственность.

capzap
27.10.2014, 16:06
мало того что во всю разбрасываетесь ссылками конкурентов, так еще и нелепа сама идея, кроме совпадения первых байт, есть еще размер запроса и контрольная сумма, вероятность совпадения минимальна

Boris_K
27.10.2014, 16:34
Да, всё зависит от конкретного девайса и его протокола. Мне попадались те у которых нет никакого контроля по контр. суммам. Конечно, почти все имеют спецсимволы, обозначающие начало и конец запроса, это сильно помогает. В целом соглашусь, вероятность конфликта ничтожна, но саму проблему не стоит игнорировать. Насколько приятнее было бы работать, если бы всё это связывалось по IP-сетям, надеюсь скоро на них перейдут почти все вендоры.

Boris_K
30.10.2014, 12:33
Поизучал, вроде то что нужно, но нигде не написано в какой конкретно форме он должен принимать запросы, собирать данные и формировать ответ, какова вообще его логика работы и протокол обмена. Не написано нигде, в том числе на оф.сайте
Всё, нашёл одну единственную фразу, из которой понятно как в общем они работают. Просто до дебильности. Запрос принимается от мастера и рассылается во все слейв-сети, а затем ответ от слейва (который ответил) отправляется в сеть мастера. Непонятно что будет если ответят одновременно 2 и более слейвов. То есть эта хрень лишь отчасти может решить проблему конфликтов, а именно: слейвы не слышат ответы друг друга, поэтому исключается возможность того, что какой-то слейв воспримет ответ (или кусок ответа) другого за корректный запрос и ответит на него.

vodav
10.11.2014, 13:44
Имел в своей практике конфликт протокола DCON с протоколом частотников Mitsubishi (FR-A500). Последний воспринимал формат DCON неверным запросом и тут же сообщал в сеть о своем "открытии", чем делал невозможным любую связь по протоколу DCON.