Профиль должен быть заполнен на русском языке кириллицей. Заполнение профиля заведомо ложными или некорректными данными - причина возможного отказа в регистрации на форуме.

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

RS-485, ProfiBUS, 4-20 mA, Wi-Fi, GSM и так далее
Аватара пользователя

Автор темы
Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

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

Сообщение Exactamente » 06 окт 2013, 16:29

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

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

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

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

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

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

Это всё хорошо, но хочется большего. Если такие штуки существуют,
Последний раз редактировалось Exactamente 06 окт 2013, 16:38, всего редактировалось 1 раз.
«Сразу видно внимание к каждой мелочи, неиспорченным не осталось ничто».

Аватара пользователя

san
преподаватель
преподаватель
Сообщения: 1400
Зарегистрирован: 01 сен 2008, 17:32
Ф.И.О.: Пупена Александр
Откуда: Киев, Украина
Поблагодарили: 1 раз
Контактная информация:

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

Сообщение san » 06 окт 2013, 16:31

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

Аватара пользователя

Автор темы
Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

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

Сообщение Exactamente » 06 окт 2013, 16:37

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

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



san писал(а):Это все должна уметь одна прога?


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

Аватара пользователя

Автор темы
Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

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

Сообщение Exactamente » 06 окт 2013, 18:57

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

Untitled-1.png



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

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

Аватара пользователя

san
преподаватель
преподаватель
Сообщения: 1400
Зарегистрирован: 01 сен 2008, 17:32
Ф.И.О.: Пупена Александр
Откуда: Киев, Украина
Поблагодарили: 1 раз
Контактная информация:

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

Сообщение san » 06 окт 2013, 19:21

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

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

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7908
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

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

Сообщение TEB » 06 окт 2013, 23:49

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

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

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


VaBo
осмотрелся
осмотрелся
Сообщения: 191
Зарегистрирован: 21 июл 2013, 18:32
Ф.И.О.: Вадим
Благодарил (а): 6 раз
Поблагодарили: 2 раза

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

Сообщение VaBo » 07 окт 2013, 06:26

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

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


Romcheg
SCADA+
SCADA+
Сообщения: 521
Зарегистрирован: 05 ноя 2009, 11:18
Ф.И.О.: Бузинов Роман Анатольевич
Благодарил (а): 5 раз
Поблагодарили: 14 раз

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

Сообщение Romcheg » 07 окт 2013, 09:28

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


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

Аватара пользователя

san
преподаватель
преподаватель
Сообщения: 1400
Зарегистрирован: 01 сен 2008, 17:32
Ф.И.О.: Пупена Александр
Откуда: Киев, Украина
Поблагодарили: 1 раз
Контактная информация:

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

Сообщение san » 07 окт 2013, 10:03

Romcheg писал(а):Давно уже пользуемся софтиной Portmon - отлично помогает снифить траффик по СОМ-портам.
Очень полезная софтинка однако. Спасибо за инфу! Иногда приятно ошибаться :ges_up:

Аватара пользователя

Автор темы
Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

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

Сообщение Exactamente » 07 окт 2013, 13:21

san писал(а):
Romcheg писал(а):Давно уже пользуемся софтиной Portmon - отлично помогает снифить траффик по СОМ-портам.
Очень полезная софтинка однако. Спасибо за инфу! Иногда приятно ошибаться :ges_up:

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


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

Аватара пользователя

MuadDib
не первый раз у нас
не первый раз у нас
Сообщения: 359
Зарегистрирован: 31 июл 2010, 08:12
Ф.И.О.: Журавлев Павел Евгеньевич
Поблагодарили: 1 раз

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

Сообщение MuadDib » 07 окт 2013, 19:51

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

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

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

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

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


ANOwen
здесь недавно
здесь недавно
Сообщения: 20
Зарегистрирован: 29 окт 2013, 07:55
Ф.И.О.: Alan Norman Owen

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

Сообщение ANOwen » 30 окт 2013, 19:07

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

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

Аватара пользователя

Автор темы
Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

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

Сообщение Exactamente » 30 окт 2013, 20:03

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



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

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

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


ANOwen
здесь недавно
здесь недавно
Сообщения: 20
Зарегистрирован: 29 окт 2013, 07:55
Ф.И.О.: Alan Norman Owen

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

Сообщение ANOwen » 02 ноя 2013, 20:06

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

Аватара пользователя

san
преподаватель
преподаватель
Сообщения: 1400
Зарегистрирован: 01 сен 2008, 17:32
Ф.И.О.: Пупена Александр
Откуда: Киев, Украина
Поблагодарили: 1 раз
Контактная информация:

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

Сообщение san » 02 ноя 2013, 21:12

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


ANOwen
здесь недавно
здесь недавно
Сообщения: 20
Зарегистрирован: 29 окт 2013, 07:55
Ф.И.О.: Alan Norman Owen

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

Сообщение ANOwen » 03 ноя 2013, 05:52

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

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

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

Аватара пользователя

san
преподаватель
преподаватель
Сообщения: 1400
Зарегистрирован: 01 сен 2008, 17:32
Ф.И.О.: Пупена Александр
Откуда: Киев, Украина
Поблагодарили: 1 раз
Контактная информация:

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

Сообщение san » 03 ноя 2013, 10:15

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

Аватара пользователя

MuadDib
не первый раз у нас
не первый раз у нас
Сообщения: 359
Зарегистрирован: 31 июл 2010, 08:12
Ф.И.О.: Журавлев Павел Евгеньевич
Поблагодарили: 1 раз

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

Сообщение MuadDib » 05 ноя 2013, 08:46

ANOwen писал(а):Обычный 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:
[spoiler=]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.[/spoiler]
Это что касается передачи данных от nport к компьютеру. Но при передаче данных в обратном направлении особых ограничений (тем более, ограничения в 1 байт на соединение) тоже быть не должно.

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

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


ANOwen
здесь недавно
здесь недавно
Сообщения: 20
Зарегистрирован: 29 окт 2013, 07:55
Ф.И.О.: Alan Norman Owen

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

Сообщение ANOwen » 07 ноя 2013, 05:25

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

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


ANOwen
здесь недавно
здесь недавно
Сообщения: 20
Зарегистрирован: 29 окт 2013, 07:55
Ф.И.О.: Alan Norman Owen

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

Сообщение ANOwen » 07 ноя 2013, 17:30

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

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


Вернуться в «Интерфейсы, протоколы, связь»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость