Много разных устройств на RS-485

[Boris_K]

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

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

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

[Jackson]

Как в общем случае избежать этого?

В общем случае - не городить такой зоопарк.

По крайней мере разделить однотипные устройства, повесим на разные интерфейсы RS-485 - так они друг друга точно не услышат.

[Boris_K]

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

[DonArchibaldos]

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

На рынке достаточно много подобных устройств, особенно применительно к системам телемеханики для энергетики. Называются шлюзами телемеханики или коммуникационными контроллерами.
Могу порекомендовать девайс, с которым лично работаю более двух лет - контроллер КП TSP-200 краснодарской конторы "Телесофт". У контроллера 4 последовательных порта и один порт Ethernet. Классическая схема работы - к последовательным портам подключаете устройства с выпендрёжными протоколами (счетчики, преобразователи, терминалы РЗА), на выходе через Ethernet получаете МЭК-104 или Modbus TCP. Стоит девайс что-то около 40к, но учитывая огромную работу, которую проделали его разработчики, это на самом деле не так уж и дорого.

[pike]

Задача специфическая (вакуумное напыление тонких плёнок), производителей оборудования мало, выбор небольшой (заказываем из-за бугра в основном), поэтому без "зоопарка" обойтись крайне трудно.

Как то странно, недавно возился с вакуумно-термическим оборудованием - там у всех регуляторов/индикаторов/регуляторов мощности/генераторов ModBus RTU был или Profibus. В следующим году грозились начать на Modbus TCP переходить.
А вот наши производители, действительно радуют самопальными ASCII протоколами на скорости 4800 бит/с - замучались с одним расходомером.

У ПЛК всего один 485 интерфейс, видел ПЛК с двумя, но это принципиально не решит проблему, тем более переносить проект на новый ПЛК сейчас уже не радует...

А может лучше другой ПЛК посмотреть: мне попадались плк (модульные) и с 22 серийными портами, и думаю что это не предел.

[rwg]

Почему нет ничего подобного? Это же общая проблема, возникающая при автоматизации?

На практике очень редко бывает более 2 несовместимых по протоколам устройств, подключенных к одному ПЛК по RS485.
В Вашем случае, если хотите оставить один ПЛК с одним RS485 и большое количество рядом расположенных устройств с несовместимыми протоколами, и если Вас устраивает темп опроса раз в несколько секунд, можете попробовать подключать устройства к RS485 контактами реле на время опроса. Герконовые реле выдерживают миллионы срабатываний, коммутируют слаботочные сигналы и преключаются за десятки миллисекунд. Если, конечно, не окажется, что дискретных выходов у Вашего ПЛК для коммутации реле тоже не хватает. Если на каждом входе будут резисторы растяжки по питанию и Ваша программа ПЛК будет уметь бороться с неустойчивой связью с устройствами, то решение может оказаться более-менее работоспособным.

[alex_ugrumov]

Задача специфическая (вакуумное напыление тонких плёнок),

Совсем и не специфическая. Производителей таких серийных машин на вскидку в РФ штуки 3 назову. И у всех решена эта задача. Но по разному.

У ПЛК всего один 485 интерфейс, видел ПЛК с двумя, но это принципиально не решит проблему, тем более переносить проект на новый ПЛК сейчас уже не радует...

Ой, и на строите вы там. И толщиномер у вас по USB, и тут не пойми какой контроллер взяли....

[Boris_K]

Совсем и не специфическая. Производителей таких серийных машин на вскидку в РФ штуки 3 назову.

Было бы интересно, можете в личку написать. Если не специфичная, то приведите пример, кто ещё делает измерители (мониторы) скорости напыления, кроме Inficon/Sycon ?

Контроллер - ПЛК100 (брал не я, а то что было), переносить проект на другой ПЛК сейчас уже не радует.

Касательно толщиномера - проблему уже почти решили на другом форуме, связь будет по RS-485.

Вообще, пока проблем со связью не испытываю, описанный конфликт протоколов очень маловероятен, тема просто принципиальная. В IP-сетях таких проблем нет, жаль что производители пока по-прежнему оборудуют приборы устаревшими RS-интерфейсами.

[pike]

Контроллер - ПЛК100 (брал не я, а то что было), переносить проект на другой ПЛК сейчас уже не радует.

О, да контроллеров на Codesys с кучей портов как собак {гринпис}. Перенос программы по сравнению с написанием протокола плевое дело.

Вообще, пока проблем со связью не испытываю, описанный конфликт протоколов очень маловероятен, тема просто принципиальная. В IP-сетях таких проблем нет, жаль что производители пока по-прежнему оборудуют приборы устаревшими RS-интерфейсами.

Стоимость разработки и производства прибора с Ethernet и поддержкой промышленного протокола, обходится пока дороже оснащения серийным портом с Modbus RTU.

[rwg]

контроллеров на Codesys с кучей портов как собак {гринпис}.

А что оптимальнее - такой контроллер или персоналка со SCADA?

[Looker]

контроллеров на Codesys с кучей портов как собак {гринпис}.

А что оптимальнее - такой контроллер или персоналка со SCADA?

Если управления нет, тогда SCADA. Про порты RS-485 в Ethernet - Moxa N-Port и будет каждому свое.

[pike]

А что оптимальнее - такой контроллер или персоналка со SCADA?

Автономные приборы - регуляторы сразу на HMI (панели оператора, SCADA). Датчики/исполнительные (регуляторы мощности, генераторы и т.п.) - в ПЛК, по возможности без промежуточных элементов (задержки, внутренние "фишки").
Ни чего нового - старая схема.

[Boris_K]

Перенос программы по сравнению с написанием протокола плевое дело.

Это легко говорить, но на практике всё бывает иначе.