Проблема с записью данных в порт [Nport 5150 ]

[FataLL]

Есть некая программа, которая работает с оборудованием, подключённым к COM-портам. При работе с физическими COM-портами всё нормально, никаких проблем нет. Когда используется 5150 и настраиваются виртуальные порты с помощью Nport WDM, то с некоторой не прослеживаемой периодичностью происходит зависание. Отладка показывает, что зависание происходит при попытке записать данные в порт:

 

WriteFile( Handle, Buffer, BufferSize, &NumWritten, 0 );

 

Т.е., возврата из WinAPI функции не происходит [что уже как-то удивительно], соответственно, поток обмена останавливается. Не исключены проблемы с сетью, т.е., на момент записи в COM-порт устройство недоступно. Перезапуск приложения обмен восстанавливает, однако, это неприемлемо. Хотелось бы знать, с чем связано такое поведение? Может, надо провести какие-то дополнительные настройки Nport или драйвера? Какие шаги следует предпринять, чтобы избежать подобного?

[Timoshuk]

Вы используете последнюю версию NPort Windows Driver Manager? Попробуйте обновить его, последняя версия доступна по следующей ссылке:

http://www.moxa.com/support/download.aspx?d_id=1359

Исправило ли обновление драйвера проблему с зависанием?

[FataLL]

Спасибо за отклик. Да, обновились до последней версии. На настоящий момент ждём результатов, так как проблема может не выявиться в течение суток-полутора. Скорее всего завтра будет что-то известно.

[FataLL]

Зависон всё же проявился...

 

Наряду с 5150, используются ещё 5130. Так вот с ними проблемы не наблюдаются. Драйвер различает их как-то? Или он один для всех универсальный?

Ещё момент. Есть конфигурация, где 5150 всего 8 (там где зависает, их порядка 40). Тут тоже всё работает, даже на старом драйвере. Количество устройств может как-то негативно влиять?

[Agibalov]

Драйвер не различает устройства по их моделям - протокол для всех одинаков. Как вариант решения проблемы - попробуйте в разделе Operating Mode установить параметр Max Connection равным 2, и установить галочки Ignore Jammed IP и Allow driver control.

[FataLL]

Спасибо за совет, будем пробовать. Max Connections если стоит 4, надо уменьшать до 2?

[Agibalov]

Нет, уменьшать не нужно.

[FataLL]

Как вариант решения проблемы - попробуйте в разделе Operating Mode установить параметр Max Connection равным 2, и установить галочки Ignore Jammed IP и Allow driver control.

Сделали, проблема осталась. Может ли какая-либо неисправность самого Nport приводить к такому? Сейчас пробуем поймать момент зависания и при этом зафиксировать какое именно устройство участвовало в обмене. К понедельнику наберём больше информации.

[FataLL]

Странно. За два дня проблема не проявилась. Хотелось бы уточнить, нет ли возможных проблем, если устройство фактически отключено, а обращение к COM-порту происходит?

[FataLL]

Проблема выявилась аж дважды. Второй раз даже через 24 минуты после перезапуска [видимо, компенсация за долгую работу на выходных ]. Обращение идёт по разным портам, т.е. устройства разные. Есть предположение, что дело всё-таки в драйвере, так как почему-то нет возврата из APIшной функции. Что может негативно влиять на работу драйвера? Есть ли какие-то ограничения по аппаратной или программной конфигурации системы [Win7-64]? Что можно ещё попробовать для устранения ошибки?

[Komantsev]

Добрый день,

Да нет, ограничений по аппаратным/программным платформам нет, поддерживается любая Windows (серверная и не серверная, x86 и x64), вплоть до Windows 8.

У нас есть заказчики, которые и с сотней COM-портов работают в режиме 24/7, всё работает корректно.

 

Есть у меня подозрение на нестабильность в сети. Попробуйте при создании виртуальных COM-портов использовать опцию "Always Accept Open Request" (позволяет приложению посылать команды на NPort даже если NPort в данный момент Offline). Изменится ли что-то?

[FataLL]

Добрый день. Спасибо, будем пробовать. Нестабильность сети действительно присутствует...

У нас есть заказчики, которые и с сотней COM-портов работают в режиме 24/7, всё работает корректно.

Мы именно и есть такие заказчики И вот впервые столкнулись с такой проблемой

[FataLL]

Встречный вопрос. Может быть для нашего случая было бы правильнее установить "Return error If Network Is Unavailable"? В нашем случае, нет необходимости ждать обязательной отправки одного пакета, в то время как остальные устройства не опрашиваются. Как раз критичнее является потеря входящей информации.

[Komantsev]

Да, попробуйте так.

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

Но смотрите сами по своей задаче!

[FataLL]

В общем, всё как-то само-собой всё утряслось. Работа была стабильна несколько дней. Галочку на "Always Accept Open Request" всё же поставили на всякий случай. Ещё несколько дней поработало, и опять норма. Чудеса. К тому же, всё это совпало с окончанием монтажно-строительных работ... Оставляем пока всё как есть. Всем спасибо ещё раз за советы.