Ожидание события порта открытого в режиме синхронного доступа

← →
Balkon (2006-07-11 13:17) [0]

Здраствуйте.
Подскажите пожалуйста каким образом для порта, открытого в режиме синхронного доступа, ожидать событие EV_RXCHAR до истечения некоторого таймаута?

В синхронном режиме WaitCommEvent не возвращается до возникновения заданных событий и если, например, устройство от которого ожидается ответ молчит, то поток, в котором происходит все действо, останавливается.

Спасибо за внимание.

← →
Reindeer Moss Eater © (2006-07-11 13:24) [1]

В синхронном режиме ничего ждать не надо.

← →
Сергей М. © (2006-07-11 13:25) [2]

> В синхронном режиме WaitCommEvent не возвращается до возникновения
> заданных событий

Тебя кто-то заставляет использовать именно синхронный режим ?
WaitCommEvent не поддерживает в этом режиме на таймайты..

← →
Reindeer Moss Eater © (2006-07-11 13:29) [3]

Тебя кто-то заставляет использовать именно синхронный режим ?

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

← →
tesseract © (2006-07-11 13:30) [4]

> В синхронном режиме WaitCommEvent не возвращается до возникновения
> заданных событий и если, например, устройство от которого
> ожидается ответ молчит, то поток, в котором происходит все
> действо, останавливается.

WaitCommEvent вообще-то реагирует только после waitCommMask.

После него рекомендуется вызвать WaitForSingleObject;

← →
medved_68 © (2006-07-11 13:34) [5]

> Подскажите пожалуйста каким образом для порта, открытого
> в режиме синхронного доступа, ожидать событие EV_RXCHAR
> до истечения некоторого таймаута?

Никаким. Либо более точная установка таймаута, либо OVERLAPPED. Вообще то вся эта лабуда и была придумана для асинхрона, что бы выяснить что там у нас с портом происходит.

← →
Сергей М. © (2006-07-11 13:40) [6]

> Reindeer Moss Eater © (11.07.06 13:29) [3]

Не соглашусь.

В любом случае выбор режима д.б. осознан... А не от балды сделан ..

← →
Balkon (2006-07-11 13:41) [7]

Спасибо.

Работа с портом идет во вторичном потоке. Вот часть его кода:
if WriteAKRComand then Try SetCommMask(FPortHandle,EV_RXCHAR); while (not Terminated) do begin WaitCommEvent(FPortHandle, Mask, nil); if Mask = EV_RXCHAR then begin ...
Протокол обмена с девайсом таков, что на каждую команду должен прийти ответ. Команды и ответы размером всего 12 байт, ответы приходят довольно быстро (доли секунды). Поэтому мне кажется ессно использовать синхронный режим. Однако, все хорошо до тех пор пока устройство есть на линии и отвечает. Если же ответа нет, то вторичный поток "висит" в ожидании события EV_RXCHAR. Как это исправить?

← →
Reindeer Moss Eater © (2006-07-11 13:46) [8]

В любом случае выбор режима д.б. осознан... А не от балды сделан ..

С этим я согласен. Только мой вариант не от балды сделан.

← →
Сергей М. © (2006-07-11 13:54) [9]

> Reindeer Moss Eater © (11.07.06 13:46) [8]

Надеюсь что так.

← →
tesseract © (2006-07-11 13:55) [10]

> Если же ответа нет, то вторичный поток "висит" в ожидании
> события EV_RXCHAR. Как это исправить?

В твоём случае огород с WaitComEvent городить-то и не нужно. Достаточно открыть порт в режиме асинхронного доступа. Посылаем сигнал ждём ответа 200 мс - по моему опыту это максимальное время ответа девайса на команду.

← →
Сергей М. © (2006-07-11 13:56) [11]

> Balkon (11.07.06 13:41) [7]

> Как это исправить?

Никак, если файл не открыт в overlapped-режиме.

← →
Balkon (2006-07-11 14:09) [12]

> Никак, если файл не открыт в overlapped-режиме.
Спасибо! Это и требовалось доказать.

← →
medved_68 © (2006-07-11 14:11) [13]

> Однако, все хорошо до тех пор пока устройство есть на линии
> и отвечает. Если же ответа нет, то вторичный поток "висит"
> в ожидании события EV_RXCHAR. Как это исправить?

Если девайс поддерживает DSR (готовность) то почему бы для начала не проверить этот сигнал на активность и только потом лезть в дебри

> события EV_RXCHAR.

← →
Balkon (2006-07-11 14:25) [14]

>Если девайс поддерживает DSR
Спасибо за совет, но не поддерживает (

← →
Сергей М. © (2006-07-11 17:36) [15]

> Balkon

Предположим, у тебя есть возможность прервать работу блок.ф-ции WaitCommEvent() по таймауту.

Что дальше должно происходить при этом ?

← →
tesseract © (2006-07-11 17:44) [16]

> Предположим, у тебя есть возможность прервать работу блок.ф-
> ции WaitCommEvent() по таймауту.

CancelIO поможет это сделать.

Опять- же почему не использовать отложенное чтение + GetOverlappedResult?
ИМХО для такого девайса (уж не весы ли? ) самое оно.

← →
Balkon (2006-07-12 06:48) [17]

Привет всем.

:) Если интересно. Девайс - автоматический компрессионный релаксометр (пресс для испытаний несущей способности грунтов) - весьма забавный прибор. К ПК подключенено до 30 шт. в послед через конвертер rs232 в rs485.

Написал управляющую программу с базой данных и отчетами использую для работы с портом компоненту CPortLib. Отлавливая различные глюки решил переписать работу с портом самостоятельно. Вот... разбираюсь.

К настоящему моменту переписал работу с портом в режиме асинхронного доступа. Несколько позже открою новую ветку где спрошу пару вопросов по реализации.

> tesseract © (11.07.06 17:44) [16]
> CancelIO поможет это сделать

Не поможет.

Цитата из MSDN:

The CancelIo function cancels all pending input and output (I/O) operations that are issued by the calling thread for a specified file handle. The function does not cancel I/O operations that other threads issue for a file handle
...
Calling the CancelIo function with a file handle that is not opened with FILE_FLAG_OVERLAPPED does nothing.

> tesseract © (12.07.06 12:52) [19]

> Интересный факт

Причем старый как мир Win9x)

А вот "новый мир" в виде Vista/LongHorn предлагает предлагает, кстати, CancelIOEx - тяпку, обрубающую в т.ч. и блокирующие операции

Опять же согласно MSDN - куда уж казалось бы более достоверного источника факта)

> PortMon другого мнения

И какого же ?

>
> И какого же ?

Обрубает!!!!!

Ржать будешь, но обрубает!(Не WaitCommEvent само собой), но вот асинхронный вроде рубит.

> tesseract © (12.07.06 18:25) [21]

> асинхронный вроде рубит

CancelIO как раз и предназначен для "обрубания" асинхронных операций ввода-вывода, выполняющихся в фоне.

> Не WaitCommEvent само собой

И не только WaitCommEvent - никакой блокирующий вызов не м.б. прерван с пом. CancelIO.

Не путай блокирующий вызов с незаконченной операцией ввода-вывода)

WaitCommEvent - НЕ блокирующий.
после него надо ждать WaitForSingleobject;

> tesseract © (13.07.06 10:00) [23]

Это за висит от режима открытия файла.

Цитата из справки:

If hFile handle was not opened with FILE_FLAG_OVERLAPPED, WaitCommEvent does not return until one of the specified events or an error occurs.

Ожидание события порта открытого в режиме синхронного доступа Найти похожие ветки