OPC-сервер, Modbus-чудо, COM-утилита

[Exactamente]

Нид ёр хелп, форумчане.

Во-первых. Нужен умный ОРС-сервер. Такой, чтобы не тупо "com error" писал, а рассказывал, что у него за еррор случилась, почему регистр не считался. Порт не смог открыть, таймаут или ещё чего.

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

В-третьих, нужна штука, которая показывала бы занятые ком-порты, показывала кем они заняты, умела их освободить от наглеца (это вообще песня, если даже такое смогёт). Походу, такая утилитка это фантастика, но вдруг?

Первое и второе - нечто подобное умеет клёвая штука, простая и надёжная, как топор, ModbusMat, только она сама себе открывает порт, чужой слушать не умеет (зато можно к нему на шину посадить ещё один конвертер и через него слушать, но ппц изврат), и она не ОРС-сервер. И есть минус - ком-порты умеет только до 10го по номеру.

Третье, для работы (я по минмуму - просмотра, удаления) из установленных устройств типа USB<->RS конвертеров (маленькие юсбишные MOXA, адвантековские ADAM'ы), когда, например, надо его удалить из системы, чтобы переназначить на другой USB-порт или ещё чего, я пользуюсь микрософтовской консольной утилитой devcon.

Это всё хорошо, но хочется большего. Если такие штуки существуют,

[san]

Это все должна уметь одна прога?

[Exactamente]

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

На кусту некоторое оборудование по модбасу по rs485 через моксу 5230 (rs232/422/485 > ethernet), подключенную в циску, потом по радио, потом через циску заведёно на сервер. Если к моксе подцепиться ноутом - всё отлично. Если то же оборудование опрашивать с сервера - всё bad. Мокса с сервака пингуется до 10ms без потерь. На кусту ещё есть контроллеры - с ними всё отлично, а полевые устройства не опрашиваются. Завести их через контроллер не вариант.

Это все должна уметь одна прога?

Нет, совершенно не обязательно. Это не для внедрения, а для рабочей диагностики, поэтому важно суметь это чем-то, а как и чем - вопрос десятый. Идеально, конечно, если последние два пункта - это консольный софт, не требующий инсталляции, запускающийся с флешки. Что-то я замечтался... ^_^

[Exactamente]

Для ясности, картинку нарисовал.

Untitled-1.png

Ноутбуком на кусту опрашивать оборудование через моксу: всё отлично.
От сервера до моксы: линк отличный.
От сервера до оборудования: связи скорее нет, чем есть.

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

[san]

Судя по всему задан очень маленький период опроса, просто Слейвы не успевают отвечать. МОХА наверное стандартный шлюз, без буферизирования? То есть все девайсы в кусте опрашиваются непосредственно с клиента через задания девайс-айди?

На счет прог - исторически пользуюсь Шнейдеровским OFS. У него довольно подробный реал-тайм лог. Можно наверное и в файл лог кидать, но никогда не пользовался. На счет послушать занятый порт - не встречал. Да и как-то сомнение меня гложит, что это возможно. На сколько я помню ресурс "СОМ-порт" в Винде не делимый, и принадлежит одному процессу, первому занявшему этот ресурс. А значит доступ к нему можно получать только разве что хуками через внедрение в процесс. Но я так давно такими темами не занимался, что могу ошибаться.

[Jackson]

на первое и второе есть готовые софтинки. Не скажу пока за названия, но видел в работе у наших программистов. Спрошу.

По-поводу третьего - вряд ли.

Если только OPC не сумеет работать в режиме шлюза. Т.е. с устройством общаться как обычно, но создавать вдобавок виртуальный COM через который позволять сторонним прогам общаться по этому порту в промежутках между собственными запросами (т.е. мультиплексировать трафик). Знаю что наш OPC такое умеет (сам пользуюсь), но по-моему он не поставляется отдельно от ПО. спрошу.

[VaBo]

на первое и второе есть готовые софтинки. Не скажу пока за названия, но видел в работе у наших программистов. Спрошу.

По поводу второго - ищется по тегу comspy. К примеру LGComSpy (бесплатен), но пользовался я им еще лет 7-8 назад...

[Romcheg]

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

Давно уже пользуемся софтиной Portmon - отлично помогает снифить траффик по СОМ-портам.

[san]

Давно уже пользуемся софтиной Portmon - отлично помогает снифить траффик по СОМ-портам.

Очень полезная софтинка однако. Спасибо за инфу! Иногда приятно ошибаться

[Exactamente]

Давно уже пользуемся софтиной Portmon - отлично помогает снифить траффик по СОМ-портам.

Очень полезная софтинка однако. Спасибо за инфу! Иногда приятно ошибаться

+1, отличная вещь И можно смотреть, кто ком-порт пользует. Спасибо!


В версии 3.03 какая-то странность, нет меню Computer) ну оно и по ctrl+R к локалхосту нормально подключается, но всё равно как-то не по-людски. И половину пунктов из меню убрали. За 12 лет прогресс нефиговый такой :D

[MuadDib]

Хотелка №1: OPC с подробной диагностикой. Посмотрите KEPWare KEPServerEx. Выводит достаточно подробную диагностику в собственном окне, может создать ряд специальных диагностических тэгов, позволяющих контролировать связь из СКАДы. Платный, но имеет демо-режим 2 часа без иных ограничений (после перезапуска можно опять запустить на 2 часа, и так до бесконечности). Потестируйте, возможно, вас устроит.

Хотелка №2 - уже ответили

Хотелка №3 - Process Explorer от все того же Марка нашего Руссиновича. http://technet.microsoft.com/en-us/sysi ... 96653.aspx

Find Find handle or DLL... вбиваете Serial и начинаете поиск. Имя последовательного порта будет во внутреннем формате Windows. Обычно COM1 - \Device\Serial0, COM2 - \Device\Serial1 и т.д., но, вероятно, потребуются эксперименты, чтобы в этом убедиться.

Далее находите приложение, захватившее хэндл порта, в основном списке Process Explorer и пытаетесь закрыть хэндл. Включайте нижнюю половину окна (галка View Show Lower Pane, режим должен быть Handles), ищете порт в списке правая кнопка мышки Close Handle. Впрочем, можно не заморачиваться и просто убить процесс, захвативший порт. Принудительное закрытие хэндла все равно может привести к аварийному завершению процесса.

[ANOwen]

В моху через вэбморду/телнет не заходили? Там куча всяких настроек и инфы о сотоянии портов.

А вообще сериал через удаленку - зло, очень большие накладные расходы на передачу по сети (6 IP пакетов на передачу каждого байта в асинхронном режиме) на локальных линках работает нормально, при усложнении маршрута - тормозит. У меня на цепочках комп-беспроводка-моха таймаут порта стоит 10 сек,

[Exactamente]

а, забыл отписаться. Вообще смешно получилось, в ОРС-сервере режим стоял modbus TCP вместо RTU (соответственно, сама мокса в Real COM mode). В любом случае, эксперименты с моксой это часть более глобального проекта, где всё упомянутое в теме очень пригодилось. Всем спасибо



>А вообще сериал через удаленку - зло, очень большие накладные расходы на передачу по сети (6 IP пакетов на передачу каждого байта в асинхронном режиме) на локальных линках работает нормально, при усложнении маршрута - тормозит. У меня на цепочках комп-беспроводка-моха таймаут порта стоит 10 сек,

А поподробнее расскажите, почему 6 пакетов? И в каком режиме моксы? У меня, как написал чуть выше, Real COM mode. Просто так. Можно сделать и по tcp, если это будет предпочтительней.

Пакет модбас РТУ на опрос - это 6 байт, если правильно посчитал. Выходит, это 36 IP пакетов по 32 байта. Тогда опрос регистров по модбас РТУ это 1152 tcpip'шных байта, то есть чуть больше одного Кб?

[ANOwen]

Обычный IP сеанс примерно такой (со стороны клиента, в нашем случае компа) - 1.запросить соединение 2.получить подтверждение, 3.передать данные-4.получить подтверждение, 5.завершить сеанас - 6.получить подтверждение. Это в самом простейшем случае. Так как ком.порт работает в асинхронном режиме, каждый байт передается отдельным сеансом. Утилиткой tcpdump это хорошо видно. Если есть modbus-tcp, лучше используйте его - там за одну IP сессию передается весь modbus пакет.
У меня nport-ы висят на ICP 70xx модулях, да еще через WiFi - поэтому время получения ответа модуля компом может доходить до 7-8сек, хочу изжить это дело, поставив на удаленном конце контроллер с modbus-tcp

[san]

На сериалку TCP/IP пакеты не йдут, там все шлюзуется на Modbus RTU.

[ANOwen]

На сериалку TCP/IP пакеты не йдут.

Где я говорил про TCP по сералу? Естественно, подразумевался контроллер с modbus-tcp
Хотя tcp по сериалу еще как идут, как по Вашему тогда работает инет все остальное на dial-up и gprs модемах? TCP - это транспортный протокол и среда передачи ему по барабану...в том числе и modbus-tcp можно запросто отправить по сериалу, другое дело,что контроллеры на это не рассчитаны...

ЗЫ еще хочу добавить про сериал по сетке - в локале пакеты бегают от хоста к хосту быстро, а при увеличении числа узлов коммутации это время сильно увеличивается. К тому же в удаленке нередки потери пакетов (в GPRS 30% обычное дело...) в этом случае сначала ждем таймаута, потом сессия аннулируется и все начинается снова.

[san]

ANOwen, я Вас наверное не правильно понял. А то, что TCP/IP может работать поверх любого канала, я знаю. Раньше в основном только их и юзали (старые модемы на RS232). Я о шлюзах Modbus/TCP-Modbus RTU говорил.

[MuadDib]

Обычный IP сеанс примерно такой (со стороны клиента, в нашем случае компа) - 1.запросить соединение 2.получить подтверждение, 3.передать данные-4.получить подтверждение, 5.завершить сеанас - 6.получить подтверждение. Это в самом простейшем случае. Так как ком.порт работает в асинхронном режиме, каждый байт передается отдельным сеансом. Утилиткой tcpdump это хорошо видно. Если есть modbus-tcp, лучше используйте его - там за одну IP сессию передается весь modbus пакет.
У меня nport-ы висят на ICP 70xx модулях, да еще через WiFi - поэтому время получения ответа модуля компом может доходить до 7-8сек, хочу изжить это дело, поставив на удаленном конце контроллер с modbus-tcp

Полагаю, под "IP-сеансом" вы имеете в виду TCP-соединение.
По-моему, вы ошибаетесь в отношении устройств nport. Они способны передавать множество байт в одном пакете. Далее - выдержка из документации на nport - описание параметра Force transmit:

[+]

0: Disable the force transmit timeout.
1 to 65535: Forces the NPort 5100’s TCP/IP protocol software to try to pack serial data received during the
specified time into the same data frame.
This parameter defines the time interval during which NPort 5100 fetches the serial data from its internal buffer.
If data is incoming through the serial port, NPort 5100 stores the data in the internal buffer. NPort 5100
transmits data stored in the buffer via TCP/IP, but only if the internal buffer is full or if the Force transmit time
interval reaches the time specified under Force transmit timeout.
The optimal Force transmit timeout depends on your application, but it must be at least larger than one
character interval within the specified baudrate. For example, assume that the serial port is set to 1200 bps, 8
data bits, 1 stop bit, and no parity. In this case, the total number of bits needed to send a character is 10 bits,
and the time required to transfer one character is
(10 (bits) / 1200 (bits/s)) * 1000 (ms/s) = 8.3 ms.
Therefore, you should set Force transmit timeout to be larger than 8.3 ms, so in this case, it must be greater
than or equal to 10 ms.
If the user wants to send a series of characters in the same packet, the serial device attached to NPort 5100
should send that series of characters during a time interval less than the Force transmit timeout for NPort 5100,
and the total length of data must be less than or equal to NPort 5100’s internal buffer size. The serial
communication buffer size for NPort 5100 is 1 KB per port.

Это что касается передачи данных от nport к компьютеру. Но при передаче данных в обратном направлении особых ограничений (тем более, ограничения в 1 байт на соединение) тоже быть не должно.

Описанное вами поведение (установка отдельного TCP-соединения на передачу каждого байта), вероятно, связано с особенностями вашего ПО верхнего уровня. Пожалуйста, укажите, какое ПО вы используете на компьютере, управляющем вашими nport.

Мы используем ряд nport для различных задач, на отдельных участках имеется и wifi. ПО у нас различное. Где-то - виртуальные порты, где-то серверное ПО непосредственно взаимодействует с nport. Используем и pair connection. Но таких длинных таймаутов, как у вас, мы нигде ни разу не наблюдали. Сейчас у меня нет возможности произвести захват обмена между серверным ПО и nport, но не думаю, что там постоянно создаются новые TCP-соединения. Как только будет возможность проверить, отпишусь.

[ANOwen]

Спасибо за инфу, еще раз поковырял в этом направлении. При локальном линке непрерывными пакетам байт именно так и происходит. А вот при удаленном в нашем случае соединение очень часто рвется, связь очень плохая+немалый трафик. И про верхний уровень Вы совершенно правильно заметили - зависит от темпа обмена. Когда передается отдельный байт (телнет того же NPort, например) - на каждый байт отдельное соединение. Именно в таком режиме я и мониторил сетку в свое время.

ЗЫ. в то же время по это этому же беспроводному удаленному линку раз в секунду передается куча данных от других устройств в виде UDP пактов - они идут без потерь, хотя таймаут у них настроен всего на 3сек.
Вывод - для создания надежного обмена через NPort неплохо бы проанализировать трафик и пропускную спосорбность линка.

[ANOwen]

Проблему решил - смоделировал ситуацию на другой машине, все гут, дело было в драйвере...на проблемной машине система крутилась лет 5-7 (linux), после обновления таймаут урезал пока до секунды, потерь нет.

А все равно удаленный сериал через ИП зло, в RT системах это применять не стоит, время отклика не гарантировано.