Встал вопрос научить существующее устройство работать через лок сеть . Сеть может быть индивидуальной для каждого прибора (грубо говоря для каждого прибора из компа выходит свой провод). Кто нибудь сталкивался с такой задачей и на чем рашалась?

http://com0com.sourceforge.net/

"Лок. сеть" имеется в виду Ethernet? Тогда ответ - да, делали. На изделиях фирмы MOXA.

Также использовали Моксу для этих целей. Вполне успешно. И даже не только в "Лок. сети"...
Как-то в одной из систем заменили канал типа "ПК-USB-RS485-Устройства" на цепочку "ПК-USB-WiFi-Ethernet-Internet-Ethernet-MOXA-RS485-Устройства". Ни управляющая программа на ПК, ни конечные устройства "ничего не заметили". Что было даже несколько удивительно.

Возникла необходимость быстро научить прибор работать по локальной сети. Прошу поделиться кто какими модулями виртуальных com портов пользовался.

http://electronix.ru/forum/index.php?s=&am...st&p=733722

Спасибо!

Будем пробовать. Правда на моксах сильно сильно обожглись.

А я и не нашел , думал в песок тема ушла. Спасибо!

Можно подробности?

Замечательные подробности. Пока мы работаем с одним прибором с другой стороны (там где TCP в RS), скорее всего все нормально. Но если на стороне RS появляется несколько приборов, все. Конкретно посмотреть с осциллографом не удалось, но прмерно картина такая: отправляемые запросы со стороны компа доходят до стороны RS вовсе не с теми интервалами, с какими отправляются. Они слипаются. Настроек каких- то у моксы не было, только длина буфера. Ну собственно дальше все понятно, когда до приборов доходят одновременно запросы отправляемые на самом деле через 200-500 миллисекунд, приборы радостно начинают отвечать одновременно. Ну и все.
Там получалось, что чтобы нормально начинало работать, надо разносить отправляемые запросы чуть ли не на пару секунд.
Но так было на одноканальных моксах, на 3 канальных вроде все работало, но там были настройки тайм аутов и что-то можно было подкрутить.

Ну дык нужно было сразу правильно выбирать оборудование под задачу.

Мы использовали сразу две 8-ми канальные Моксы, и действовали по принципу: каждому устройству - свой RS-канал. Таймауты никакие не "подкручивали", ни в Моксах, ни в управляющей программе на ПК, ни в конечных устройствах. Почему-то все сразу заработало. Чел. сидел на другом конце Москвы и отлаживал управляющую программу, а "железо" стояло в оффисе и, через Моксы, было подключено к локальной сети, с выходом в Internet. Скорости устройств были самые разные - от 9600 до 1Мбит/сек. Кстати, большинство устройств использовало modbus rtu.

firstvald
Я конечно, не сильно глубоко вникал в задачу, дал дипломнику. Но наcколько помню, в одноканальной MOXA NPort 5110 туча настроек, включая айпишник и таймауты по TCP и по UDP.
Или у вас на том конце RS485? Тогда на уровне протокола по 485 интерфейсу надо было решать вопросы плавающих задержек в TCP канале. От последнего не избавишься...

Сообщение отредактировал V_G - Mar 26 2010, 05:19

Да я предлагал мужикам использовать один канал на прибор, в этом случае вообще бы не узнали про эту проблему бы никогда. И вообще собирать все на столе прежде чем на объект выходить.
Пытал: собирали на столе? Собирали. Работало? Не-а. Какого юююю . Дык думали в OPC баг, проггеры потом подправят. Ни всем привет.

Потом на объекте смотрели - никаких настроек - только длина буфера и все.

Про modbus rtu - очень интересно. А в устройстве и программах на компах времена принятия решения об окончании посылки стояли честные? Или задранные?

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