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

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 канале. От последнего не избавишься...

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

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

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

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

Вот есть везучие люди!
А тут, что бы ни с делал , все какие могли бы быть спецэффекты - все всплывают!

Я пробовал NPort 5150 - всё отлично. Настраивается и таймаут, и длина пакета (если фиксированная) и многое другое.
И вообще, нечего подряд запросы слать, пока ответ не получили

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

Угу. А вот скада. Времени ждать некогда. Послали запрос - нет ответа, пошли дальше и как правило за секунду порой надо пройти десяток приборов. На той системе, что сейчас смонтирована придется OPC сервер писать заново, как я называю - с поведеньицем, чтбы определял, что упал обмен и начать его восстанавливать. Пока честные порты были - все нормально. Я не смотрел какие моксы стоят, вернее смотрел, но пусть проектанты системы разбираются, как оно у них работает. (найду что там стояло - напишу). А как в канале что -то появилось, такой подход оказывается неприемлимым (и вообще говоря, оказывается, что никакая скада не будет работать по такому каналу). Более того на неделе общался с одним из разработчиком известной-преизвестной нашей скады. Так он мне говорит, а у нас один параметр по тайм ауту - общий для всех приборов на линии. Я ему - ай яй яй. Вот не знаю чем дело кончится, лепят они свое добро давно , стали наше железо подключать , а тут начало выясняться что не все гуд, как у нас (вернее у нас не гуд, потому что у софта все настраивается по самому медленному), но что страшнее - у них. Софт-то на объектах уже крутится по всей стране.


Пы Сы: Программистов, кто пишет без паяльника и осциллографа, поубивал бы.

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