NPort 5110 и радиомодем DataRadio

[murz]

Столкнулся с такой вот проблемой:

Есть NPort 5110 в режиме RealCOM, радиомодем DataRadio T-96 и свое приложение (WinAPI). Связь с радиомодемом осуществляется с использованием управляющих сигналов RTS/CTS. C реальными портами (которые на шине) все работает. А с энпортом - не хочет. На модеме вижу постоянную передачу, осциллографом вижу что RTS от энпорта постоянно поднят. Не могу понять в чем может быть косяк - по документации RealCOM вроде должен передавать все сигналы. Есть какие-нибудь мысли как это можно побороть?

[Komantsev]

Добрый день!

Посмотрите, пожалуйста, что говорит раздел "Мониторинг" утилиты NPort Administrator? См. наши рекомендации по мониторингу.

[murz]

Мониторинг не особо помог. Байты ходят, соединение есть, параметры порта устанавливаются, но это и так было видно.

 

Дальнейшее изучение показало следующее:

1. Не работают вызовы WinAPI:

EscapeCommFunction (h,SETRTS); - ошибка "недопустимый аргумент"

EscapeCommFunction (h,CLRRTS);

 

2. dcb.fRtsControl = RTS_CONTROL_TOGGLE;

SetCommState (h,&dcb);

RTS всегда в высоком уровне, а не обрамляет передачу данных

 

Операционки - XP SP3 х32 и 7 SP1 x64, версия драйвера 1.12. Драйвера пробовались и admin utility, и windows driver manager.

[Komantsev]

Добрый день!

 

Сможете сделать протоколирование передачи данных утилитой Portmon?

 

Осуществите обмен данными через обычный COM-порт компьютера и запротоколируйте этот обмен. Как я понимаю, этот обмен должен быть успешным. Затем такую же процедуру с теми же данными проделайте через NPort и также запротоколируйте.

 

И пришлите получившиеся LOG-файлы для сравнения.

 

P.S. Portmon на Windows 7 не работает. Так что надо будет его запустить на машине с XP.

[murz]

Вот, пожалуйста:

 

Реальный COM1 и Moxa NPort. Там же картинки с осциллографа для наглядности. Канал А (красная линия) - RTS, канал B (синяя линия) - Tx.

[murz]

И можно заодно описание протокола IPSerial получить в почту?

[Komantsev]

И можно заодно описание протокола IPSerial получить в почту?

Можно :-)

 

По поводу управления RTS/CTS - сейчас программисты выясняют, в чем может быть дело.

[murz]

Спасибо за протокол.

И подождем что скажут программисты

[_ebe_]

Драйвер версии 1.17 от 17.01.13 г. Режим RealCom. Скорость 9600 бит/сек.

Управление RTS через Device Control Block dcb.fRtsControl = RTS_CONTROL_TOGGLE и вызов Win API “EscapeCommFunction” по-прежнему не работают.

Управлять RTS можно используя вызовы "GetCommState/SetCommState". Псевдокод, ниже. Некрасиво, но работает.

 

GetCommState (h,&dcb);

if (rts == SETRTS)

dcb.fRtsControl = RTS_CONTROL_ENABLE;

else

if (rts == CLRRTS)

dcb.fRtsControl = RTS_CONTROL_DISABLE;

SetCommState (h,&dcb);

 

Столкнулся с дугой проблемой. На приеме теряются байты. Передача запроса осуществляется одним вызовом WriteFile. Чтение ответного пакета выполняется 1-мя вызовами ReadFile:

1. 1 байт – синхрослово

2. 2 байта – заголовок содержащий длину ответа

3. «длина ответа» + 2 байта. «длина ответа» может быть от 1-го до 240 байт

Первые два чтения заканчиваются успешно. Третье чтение, с высокой вероятность заканчивается тайм-аутом, прочитано на один байт меньше, чем требовалось. Подключил к последовательному каналу между модемом DataRadio и Moxa NPort 5110 анализатор протоколов. Вижу, что от модема в NPort ответный пакет передается полностью. Теряется 4..6 по счету байт ответного пакета. Значения байта самые разные, но место одно. Анализируя тайминги заметил, что перед потерявшимся байтом в потоке есть разрыв 0.2…0.4 мсек.

 

Фрагмент трассировки, в квадратных скобках потерянный байт.

 

АВГ 19 2013 17:09:05.43 CComDevice::ttywrite: <02 02 00 00 00 60 78 11 >

АВГ 19 2013 17:09:05.50 CComDevice::ttyread: <02 >

CComDevice::ttyread: requested 1 bytes, read 1 bytes

CComDevice::ttyread: receive time: 0 sec 000005 usec

АВГ 19 2013 17:09:05.56 CComDevice::ttyread: <02 0C >

CComDevice::ttyread: requested 2 bytes, read 2 bytes

CComDevice::ttyread: receive time: 0 sec 000005 usec

АВГ 19 2013 17:09:07.87 CComDevice::ttyread: <A1 [E1] 9C C8 4C 4C FF FF FF FF FF 7F 85 84 >

CComDevice::ttyread: requested 14 bytes, read 13 bytes

CComDevice::ttyread: receive time-out: 2 sec 159351 usec

 

Настройка драйвера сделана «игнорировать интервальный тайм-аут». См. фрагмент псевдокода.

 

COMMTIMEOUTS to;

to.ReadIntervalTimeout = 0; // 0 - interval timeout not used

SetCommTimeouts (h,&to);

 

Пробовал устанавливать «интервальный тайм-аут» в заведомо большое значение (4…6 мсек) картина не меняется, байт в начале 3-го чтения пропадает.

Кто-нибудь сталкивался с такой проблемой? Что подскажите…

[Agibalov]

Здравствуйте!

 

Какие данные при этом идут по сети? Посмотрите, пожалуйста, например, с помощью анализатора Wireshark, чтобы точно знать, теряются ли данные в NPort или на компьютере?

[_ebe_]

Здравствуйте, установил WireShark. Настроил фильтр на IP адрес NPort и порты 950 и 966. Работает, вижу дампы пакетов в hex. Подскажите, как подстроить фильтр, чтобы анализировать данные приходящие с COM порта. Нет опыта, WireShark использую впервые. Внутри пакетов TCP не понимаю, где транспортитуемые данные, а где служебные протокола Moxa NPort.

 

М.б. опубликуете рекомендуемую строку-настройку фильтра WireShark.

 

Для сведения. Переписал программу на прием за 2 чтения.

1. запрос 3 байта (синхро + заголовок с длиной)

2. данные по длине пакета

 

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

 

Жду помощь в настройке WireShark. Спасибо.

[Agibalov]

Чтобы посмотреть, какие данные передаются в TCP-пакете, надо в среднем окне раскрыть Transmission Control Protocol и выбрать TCP Segment data. После этого, в нижнем окне подсветится содержимое пакета.