При поставках заказчику собственного программного обеспечения наблюдалась ситуация: иногда при непредвиденном изъятие конвертера USB/RS485 из системы Windows XP (часто ситуация возникает из-за человеческого фактора, а также м.также возникнуть в результате воздействия сильной электромагнитной помехи при коммутациях со стороны высоковольтной линии 6кВ на конвертер при непосредственной близости обоих) происходит зависание программного обеспечения (разработчик данного ПО не я). По словам программиста зависание происходит где-то в api-шных функциях винды. При этом программа не отзывается и никаким образом не убивается, только перезагрузка помогает, хотя винда остается работоспособной,
Если какие-либо способы решить данную проблему при возникновении описанной выше проблемы.
Заранее большое спасибо.

решение может быть только одно - не использовать венду. у клиента случайно не N-ядерник ? венда имеет проблемы на N ядерных системах - так называемые race conditions между различными компонентами. как вариант, можно попробовать оставить одно ядро, путем замены hal.

Так сейчас везде N-ядерные системы - мы заказчику поставляем ноут с нашим ПО

А на чем конвертер сделан ? Не FTDI часом ?

Обычно используем I-7561 от ICPDAS

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

Если есть ХОРОШИЙ контакт с программистом, то можно из ситуации выкрутиться. Надо мониторить события PnP в винде. Может даже прийдется ставить программный Hook. После срабатывания Hook проверять, наш ли порт отвалился и заканчивать принудительно последнюю операцию и осовбождать порт. Проблема в том, что надо иметь исходники компонента, через который коммуникация с портом идет (никто же обычно не работает с портом через API) а применяют сторонние модуля, вот его прийдется править.

Не помогает. Освобождения порта не хватает - надо УСБ перевтыкать. Грустно.

Мы работатаем на уровне api-ных функций - юзаем их в C#. Хук то посадать можно - иногда он помогает, но вот если в момент выпадания конвертера программа обращается к апишными функциям, то происходит где-то зависание в этой апишной функции

Оказался глючный экземпляр конвертера. На столе без подключенной линии выдает дикие таймауты. Но вопрос "что использовать для уверенной работы" остается.

Вы далеко не первый с такой проблемой.
На данный момент решения нет. Самое разнообразное usb оборудование с той или иной периодичностью подвисает или отваливается. Проблема софтверно не лечится, так как для развешивания обязательно нужно переткнуть usb устройство.
Хотите уверенно работать - не используйте usb! Вот ethernet например вполне надежно работает, гальваническую развязку имеет по определению и его никто пока не объявил "устаревшим".

было такое с изолированным программатором АВР910 на СР2102 и длинным 5-метровым кабелем (мертво вис USB при включении/выключении питания программируемой платы, программа не снималась из диспетчера задач).
проблема решилась заменой кабеля на более качественный (толстый с хорошей экранировкой) и подключением прямо на задний разъем мат.платы (сначала подключились на переднюю панель компа)
перетыкание не помогало, программа продолжала висеть, СОМ-порт был занят. помогала только полная перезагрузка

Сообщение отредактировал ukpyr - Nov 29 2008, 14:23

А может дело в драйвере на шнурок

Мы после долгих и тщательных разбирательств пришли к тому же выводу. Т.е. проблему у некоторых драйверов и микросхем есть, но есть дырка и в самих виндовых драйверах. Если помеха приходит в "неудачный" момент (или отключение), USB отваливаются навсегда и никакие переделки в драйверах от этого не спасают. Где-то они забыли предусмотреть отсутствие ответа с таймаутом.

А с разными переходниками USB-COM - это отдельный вопрос. Там похоже еще и драйвер так раскорячен, что до синего экрана доходит. Но это похоже уже проблема драйвера.

Сообщение отредактировал rudy_b - Dec 23 2008, 12:19

Лучше использовать дэвайс для работы с RS 232 по Ethernet. 2 года использую, пока ни каких проблем не было.