[SergeyMak 0]

речь идет о поддержки TCP до самого устройства ? а дальше однонаправленная передача ?

между OPC и шлюзом односторонняя. Просто отправляем данные на com-порт.

 

 

как можно сделать однонаправленную передачу с подтверждением ? (а вдруг подтверждения хакнут ? :-D )

через COM отправляем данные. На этом канале откусываем ногу Тх ))

 

Вот режимы работы устройства:

Виртуальный COM-порт

TCP Server

TCP Client

UDP Server/Client

 

Я понимаю, что преобразователь реализует TCP/IP на своём CPU и таким образом мы получаем желаемое.

 

 

[SFx 0]

Я понимаю, что преобразователь реализует TCP/IP на своём CPU и таким образом мы получаем желаемое.

Дерзайте.

[vvs157 0]

если взять сетевуху оптическую - то признает.

Ну тогда берется 2-волоконный медиаконвертер с оптики на медь и не подключается приемный разъем.

[SFx 0]

Ну тогда берется 2-волоконный медиаконвертер с оптики на медь и не подключается приемный разъем.

нуда типа того)

[vadimp61 0]

Итак, еще раз.

 

Соединяем OPC-сервер (4 шт.) с базой данных по локальной сети. Требуется шлюз с однонаправленной передачей данных. Он должен быть на стороне OPC и обеспечивать передачу в БД. В компах обычные АТХ матери, соответственно

доступные интерфейсы: COM, LPT, USB, Ethernet, PCI, PCIex.

OC: WinXP.

Сеть: Медь-оптика-медь (полный список оборудования выяснить тяжело)

Шифрование не требуется.

Нужна гальваническая развязка, скорость не менее 40 Кбит/с, поддержка TCP, возможность написания собственного прикладного ПО.

Цена. Думаю 2-3 тр за шт найдем без проблем. Если потребуется разработка и цена перевалит за 50тр – тоже можно.

 

Осталось добавить, что в это описание можно внести обоснованные изменения по некоторым позициям.

 

 

Всё таки я склоняюсь к протоколу с подтверждением. Делать, так сразу нормально.

Ну так постройте ОТДЕЛЬНУЮ локалку от 4-х серверов и компа с БД. Или к БД обращаются из другого города по Internet? Если нет, то кто тогда может ее хакнуть непонятно?

[SergeyMak 0]

Дерзайте.

Одобряете? :)

 

Ну тогда берется 2-волоконный медиаконвертер с оптики на медь и не подключается приемный разъем.

Попробуем с com-портом для начала.

 

Ну так постройте ОТДЕЛЬНУЮ локалку от 4-х серверов и компа с БД.

Да, локалкой не обойдешься. К тому же расстояния. Не зря между ними оптика.

Изменено 26 апреля, 2011 пользователем SergeyMak

[SergeyMak 0]

Спасибо всем, принявшим участие в обсуждении! Столько людей откликнулось.

 

Устройство должно было реализовать шлюз внутри себя. А так возникает вопрос в электрической части com-порта =) Похожа ли она на транзисторную или если перебрать драйвер этого порта, то можно писать данные на любую линию?

Может быть новую тему открыть?

Изменено 27 апреля, 2011 пользователем SergeyMak

[vvs157 0]

Попробуем с com-портом для начала.

Трудозатраты на реализацию выше, чем с одним отрезанным оптическим линком

[SergeyMak 0]

Снова здравствуйте!

Покритикуйте схему в том же контексте.

 

Eth -> МК -> SPI ->(Опторазвязка только на 3 линии:MOSI,SCLK,SS)-> SPI -> МК -> Eth.

 

Минимум действий: всё, что прилетело в Ethernet отправилось на Ethernet c другой стороны. В каждом МК обработка протоколов верхнего уровня, TCP/IP работает, связь между сетками в одну сторону.

 

PS. Медиаконвертеры не хотят работать без Rx. Если только карточку с FlowControl, но у меня такой не нашлось.

[DrGluck 0]

http://www.altx-soft.ru/groups/page-269.htm

 

 

P.S. Цена вопроса 50 т.р.

[Rst7 5]

Мда. Безумству храбрых, как говорится.

 

Берем карту (свич), отключаем на ней функцию Auto-MDIX (так же неплохо смотрится какая-нибудь древняя карта без этой фичи) и переводим ее в 10МБит. Пару TX на стороне приемника, естественно отрываем, а в линию в направлении к внешнему миру, дабы на другой стороне был Link, подаем импульсы Link Pulse, которые генерируются любым удобным способом

Autonegotiation is based on pulses similar to those used by 10BASE-T devices to detect the presence of a connection to another device. These pulses are sent by a device when it is not sending or receiving any data. They are unipolar positive-only electrical pulses of a duration of 100 ns nominally, with a maximum pulse width of 200 ns,[2] generated at intervals of 16 ms (with a tolerance of 8 ms).

 

 

Все :)

[SergeyMak 0]

http://www.altx-soft.ru/groups/page-269.htm

 

 

P.S. Цена вопроса 50 т.р.

Спасибо, но работает этот комплекс только с файлами и директрориями. И это UDP протокол.

 

 

 

Мда. Безумству храбрых, как говорится.

 

Берем карту (свич), отключаем на ней функцию Auto-MDIX (так же неплохо смотрится какая-нибудь древняя карта без этой фичи) и переводим ее в 10МБит. Пару TX на стороне приемника, естественно отрываем, а в линию в направлении к внешнему миру, дабы на другой стороне был Link, подаем импульсы Link Pulse, которые генерируются любым удобным способом

 

Все :)

 

И это UDP получится. Хотя суровое решение. Главное, что бы карточка не поменяла направление случайным образом при обновлении драйвера, например.

 

[Rst7 5]

И это UDP получится.

 

А других с односторонней передачей не получится.

 

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

 

Можно карту с отдельным PHY (очень часто в современных матерях) и обрезать TXD на уровне PHY-EMAC.

 

Если уж очень хочется что-то разработать, то возьмите две микросхемы PHY KSZ8041TL и включите их в режиме жопка-к-жопке (Back-To-Back) с разрывом одной из связи TXD-RXD. Подробности в даташите.

[SergeyMak 0]

Если уж очень хочется что-то разработать, то возьмите две микросхемы PHY KSZ8041TL и включите их в режиме жопка-к-жопке (Back-To-Back) с разрывом одной из связи TXD-RXD. Подробности в даташите.

 

Чем вам не нравится тоже самое, только с двумя контроллерами?

 

[Rst7 5]

Чем вам не нравится тоже самое, только с двумя контроллерами?

 

Деталей много :) Опять же, много лишнего софта, вряд ли Вы его нормально напишите. А ведь Вы хотите

получить простое (в т.ч в дальнейшем обслуживании) и надежное устройство.