Для R485 и R232 добавить возможность подключения нескольких клиентов к серверу

[san]

Для окончаний R485 и R232 требуется добавить возможность подключения в режиме "шины", когда к одному серверу подключены одновременно несколько клиентов, как это когда-то было сделано в MC04-WL.
Сервер передаёт данные из медного порта всем клиентам, а полученные любого клиента данные передаёт в медный порт.
Подразумевается что у R232 в этой схеме не используются сигналы управления и в один момент времени передавать данные может только один из клиентов.

[alx]

Replying to san:

Для окончаний R485 и R232 требуется добавить возможность подключения в режиме "шины", когда к одному серверу подключены одновременно несколько клиентов, как это когда-то было сделано в MC04-WL.

Для чего такая возможность требуется?

Подразумевается что у R232 в этой схеме не используются сигналы управления

Какие "сигналы управления"? Если сигналы управления потоком, то почему так подразумевается?

У окончания R232 уже есть конфигурационный параметр, запрещающий использование сигналов управления потоком (для работы с устройствами, которые эти сигналы не поддерживают). Этого недостаточно?

и в один момент времени передавать данные может только один из клиентов.

Каким образом предлагается выбирать такого клиента?

[san]

Для чего такая возможность требуется?

У нас есть клиенты, которые через спутниковый ethernet с помощью VE-02 прокидывают много каналов RS-232 по схеме звезда, для мониторинга и управления удалённого оборудования. Опрос и управление каждым удалённым объектом происходит по очереди через общую шину, устройства идентифицируются по адресу передаваемому в пакете данных. Сейчас мы устанавливаем в блок на стороне сервера много плат VE-02, а пользователь организует их соединение проводами, хочется оптимизировать эту схему.
A RS-485 в принципе шинный интерфейс, и для него поддержка такой возможности может быть востребована.

Какие "сигналы управления"? Если сигналы управления потоком, то почему так подразумевается?

Т.к. непонятно что делать с сигналами управления потоком при организации "шины". Да и пользователи при таком нестандартном использовании RS-232 используют только три провода RxD, TxD, GND.

Каким образом предлагается выбирать такого клиента?

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

[alx]

Replying to san:

У нас есть клиенты, которые через спутниковый ethernet

Через что??? :-() По-моему таких длинных ethernet'ов не бывает. :)

с помощью VE-02 прокидывают много каналов RS-232 по схеме звезда,

Как это "по схеме "звезда""? Интерфейс RS-232 может соединять только два устройства между собой, то есть это всегда "точка-точка". Он не может быть звездой. Или ты не про RS-232?

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

Какой пакетный протокол используется поверх RS-232?

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

Что именно в этой схеме хочется оптимизировать? Ведь если у пользователя, допустим, 10 устройств, то, как ни крути, для их подключения потребуется пять плат VE-02...

Тут по-моему напрашивается мысль о разработке специальной платы, на которой будет действительно много RS-232 (скажем, 10 или еще больше). Во-первых, она будет стоить наверное на порядок меньше чем VE-02 (в которой большая часть стоимости приходится на ненужный в данном случае медиапроцессор), а во-вторых, ее будет достаточно одной, что еще больше увеличивает экономию...

A RS-485 в принципе шинный интерфейс, и для него поддержка такой возможности может быть востребована.

Для чего (если он и так шинный)? Для подключения всей шины требуется один порт (и, соответственно, достаточно одной платы VE-02)...

Какие "сигналы управления"? Если сигналы управления потоком, то почему так подразумевается?

Т.к. непонятно что делать с сигналами управления потоком при организации "шины".

Что делать с сигналами управления потоком, лично мне совершено понятно: при отрицательном напряжении на RTS DCE приостанавливает передачу, а при отрицательном напряжении на CTS - DTE приостанавливает передачу.

В RS-485, который может соединять более двух устройств, сигналов управления потоком нет.

Да и пользователи при таком нестандартном использовании RS-232 используют только три провода RxD, TxD, GND.

Нестандартном? Что ты имеешь в виду? Как они его используют?

Я имел в виду, что устройства пользователя должны отвечать строго по очереди, не одновременно, а мы можем просто выдавать все данные, что были приняты от любого клиента в медный порт сервера.

Понял, спасибо за уточнение.

[san]

Начну с RS-485, с ним проще:

A RS-485 в принципе шинный интерфейс, и для него поддержка такой возможности может быть востребована.

Для чего (если он и так шинный)? Для подключения всей шины требуется один порт (и, соответственно, достаточно одной платы VE-02)...

Дело в том устройства-слейвы обычно разнесены географически, и пользователю нужно объединить их в виртуальную шину. Это я по опыту применения у клиентов плат PD-04, там пользователи организуют шину с помощью групповых каналов.

Что именно в этой схеме хочется оптимизировать? Ведь если у пользователя, допустим, 10 устройств, то, как ни крути, для их подключения потребуется пять плат VE-02...

Со стороны клиента, у пользователя как-правило одно устройство, но клиентов этих много, они в разных точках находятся. Сейчас мы стороны сервера вынуждены ставить N портов чтобы организовать N подключений к клиентам, а пользователю требуется всего один порт, т.к. устройство-мастер физически одно и общается со всеми клиентами по очерели.
Из того же опыта применения у клиентов плат PD-04: пользователям удобно подключать к одной и той-же шине(групповому каналу TDM) слейвов, как по интерфейсу RS-485 так и по RS-232(трёхпроводному).

Нестандартном? Что ты имеешь в виду? Как они его используют?

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

Какой пакетный протокол используется поверх RS-232?

Модбас RTU

Такую же возможность организации программной шины мы уже реализовывали в MC04-WL

[alx]

Replying to san:

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

Что-то я совсем запутался... По-моему у тебя клиенты и серверы путаются между собой. Что значит "подключений к клиентам"? Клиент - это и есть тот, кто подключается...

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

Как странно... А почему они не используют вместо этого RS-485, который как раз предназначен для такого подключения?

Какой пакетный протокол используется поверх RS-232?

Модбас RTU

Так с этого и надо было начинать!!! :)

Насколько я теперь понимаю, потребителям нужен modbus-bridge (мост) и опционально modbus-конвертеры. Мне видится следующий вариант решения данной задачи.

1. Организуются конвертеры modbus-RTU в modbus-TCP (и обратно) с физическими интерфейсами RS-232 и/или RS-485. Для простоты можно сделать один с RS-232 и один с RS-485. Конвертеру при конфигурации назначается пара (адрес, порт) сервера modbus-tcp. Принимаемые запросы modbus-RTU (или modbus-ASCII - это еще один вариант протокола) передаются сконфигурированному серверу TCP. Запросы, принимаемые от клиента modbus-TCP, передаются в последовательный порт.

2. Организуется мост, работающий только с modbus-TCP. Мосту при конфигурации задаются пары (адрес, порт) серверов, которым он должен передавать запросы. Работать он может по принципу моста ethernet: - для каждой сконфигурированной пары (адрес, порт) запоминать ID серверов, от которых получен валидный ответ, и последующие запросы этому ID передавать только туда. Если запрос адресовать неизвестному ID, он передается каждому из сконфигурированных серверов (это похоже на то, как сервер SIP разветвляет вызов сразу нескольким UA)...

Это если очень коротко, в самых общих чертах.

Ну и я думаю, что это надо делать, конечно, не на базе VE-02, так как будет явный overprice. Это задача для какой-нибудь 10-долларовой Orange Pi Zero...