Как объединить две RS-485 сети по дуплексному каналу? Опции

[NeoN]

Вот такая проблема: есть дуплексный канал связи в составе оптического оборудования, который грубо можно представить как две сигнальные линии в противоположных направлениях с вносимой задержкой до
1мс. Надо объединить две сети RS-485 через этот канал. Т.е. на каждом конце канала стоят двунаправленные RS-485 трансиверы, передача данных осуществима тривиально, а вот как управлять направлением передачи в трансивере? У кого-нибудь есть опыт?

[zltigo]

Это следует понимать, как сопряжение fulldupleх канала с simplex моноканалом при отсутствии
доступа master(ам) работающим в моноканале? Тогда только разбирая в протоколе RS485
запросы master(ов).

[GrayCat]

Посмотри схемотехнику преобразователей RS232<->RS-485 -- практически ОНО. Варианты самые разные, начиная от грязных трюков типа "открытый коллектор" до микроконтроллеров с 2-мя UART.

[torik]

Я не очень врубился в вопрос, но есть два варианта:
- полудуплекс - это один 485 приемопередатчик типа ADM485, у него есть сигнал управления прием/передача. Линия связи - витая пара.
- дуплекс - таже база, но два приемопередатчика - один всегда на передачу, другой на прием. Линия связи - две витые пары.

[rezident]

Кроме переключения направления нужно еще решить задачу подавления эха. Но не в этом суть. Нужно выбрать способ арбитража и захвата линии. Исходно оба драйвера RS485 стоят в режиме приема. Здесь желательна "растяжка" линий, чтобы по возможности исключить ложные срабатывания схемы захвата линии. В зависимости от того, с которой стороны раньше началась активность (при наличии растяжки это первый переход из лог 1 в лог 0), тот драйвер RS485 устанавливается (точнее остается и блокирется в этом состоянии) на прием, захватывает дуплексный канал для передачи на определенное время, а второй драйвер RS485 переключается на передачу. Время захвата канала продлевается каждый раз при переходе сигнала из лог 1 в лог 0. Как закончились перепады уровней (закончилась передача), так канал разблокируется и оба драйвера RS485 снова встают в режим приема. Способ детектирования перехода уровней и генерации времени захвата канала отдаю на ваше усмотрение.
У нас на подобном алгоритме работы выпускаются конверторы/репитеры RS485-RS232-RS485. Все три направления коммутируются автоматически (логический автомат). Кроме этого применение двух таких конверторов (соединяются два через нульмодемный переходник посредством RS232) возможна организация соединения линий RS485 "звездой" (четыре луча), с автоматическим переключением линий прием/передача - один передает, остальные принимают.

[zltigo]

Исходно оба драйвера RS485 стоят в режиме приема.
...
В зависимости от того, с которой стороны раньше началась активность ...

Вопрос конечно задан размазано, но по крайней мере ясно что там две СЕТИ.
Таким образом задача не соединения точка точка и не звезда объединенная на каком-то
устройстве :-(
Полагаю, что имеется точка подключения к моноканалу в котором общаются (в том числе и между собой), ну например дюжина устройств. Теперь нужно подсоединить через дуплексный канал еще одну такую группу. При этом в канале имеется изрядная задержка 1 ms а устройства на сети скорее работают много шустрее :-(. Про пропускную способность канала тоже ничего не сказано в вопросе -
из вредности - пусть будет ниже :-). Ну не решается это жесткой логикой c тупым слежением за импульсами в канале. Нужен 'роутер' разбирающий и буферизирующий информацию.
А вообще, хотелось бы автора вопроса услышать :-)

[NeoN]

Нужно объединять именно две сети, т.е. в каждой из них на паре сидит несколько устройств. Практически, я сейчас и собираюсь делать, то что описал rezident, ему - респект. Но остается проблема "одновременной", т.е. в пределах той самой задержки канала активности на обоих концах канала и как следствие, "коллизии". В настоящий момент все это разрабатывается для системы, где есть только один мастер, по этому подобная ситуация исключена на уровне протоколов обмена, но хочется решить эту задачу как можно более универсально.

[rezident]

Но остается проблема "одновременной", т.е. в пределах той самой задержки канала активности на обоих концах канала и как следствие, "коллизии".

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

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

Мультимастерный режим в RS485 это скорее исключение, чем правило. Это же не CAN, если уж на то пошло. Разрабатывайте систему с одним мастером.
Для достоверной передачи данных в протоколе должен быть предусмотрен формат запрос-ответ. Раз запрос не дошел (пропал в канале связи) , то и ответа не будет. Однако, в связи с весьма значительной задержкой в самом канале, не исключен вариант, что оба источника данных могут засинхронизироваться по времени и лупить запросы с двух сторон до посинения. Но это опять проблемы мультимастера и решать их пришлось бы даже без наличия этого промежуточного канала связи.