| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблемы с портом
Замученный © (2003-07-15 14:57:00)
Уважаемые граждане, помогите пожалуйста.
Имеется прибор, подключенный к com порту. Прибору посылаются различные команды, он на них реагирует и посылает в ответ определенную информацию.
Проблема в следующем. При посылке ему какой-то команды, перед ответом возникает определенная задержка, которой в принципе быть не должно (смотрел по осциллографу). Задержка где-то около 46 мсек. Это мешает работать.
В работе использовал различные компоненты для работы с портом. Везде тот же результат.
Что можно сделать??? Заранее благодарен.
Замученный (2003-07-21 13:02:00) [1]
>твой девайс выдает что-то типа XOFF после приема пакета от тебя и XON после обработки пакета и ответа на него?
Девайсу отсылается команда вида 01 $90 00 (01 - номер устройства, $90 - команда проверки связи) при приеме данной команды должен вернуться ответ 01 $90 00 (команду принял). Именно ее я и получаю.
К тому же при посылке ему других команд, а их около 5, также получаю результат
AnS (2003-07-20 15:10:00) [2]
Работал я с компонентом ComPort Library (писал программу обмена данными с ЭККА ЭРА-201). Компонент отличный и работает прекрасно.
Вопрос такой: твой девайс выдает что-то типа XOFF после приема пакета от тебя и XON после обработки пакета и ответа на него?
jack128 (2003-07-20 14:21:00) [3]
> API - функцию WaitCommEvent,
ИМХО очень неудобно..Возиться с асинхронными операциями....И потом здесь это не поможет, почитай выше...
CaveDweller (2003-07-20 12:54:00) [4]
Если такая задержка - то это похоже на таймер в компоненте, который каждые 50мс ходит в порт за данными. Я в своё время использовал API - функцию WaitCommEvent, которая возвращает управление сразу по событию в порте. Понятное дело, что функция запускалась в отдельном потоке. Думаю, что стоит попробовать API, тем более, что не так оно и сложно.
Verg (2003-07-20 09:52:00) [5]
> jack128 ©
Если поток будет грамотно работать, то ни к чему плохому не приведет, а если while true do; то энтя умрет вплоть до ресета.
AlexR (2003-07-19 23:05:00) [6]
>Читал, что можно работать с портом напрямую с помощью giveo.sys. Но как это делать не знаю. Может кто знает??
goveio точно не поможет. Может драйвер попробовать? Но это не так-то просто.
jack128 (2003-07-18 21:57:00) [7]
> Verg © (18.07.03 14:42)
> Может поможет, может нет - все зависит от того будут ли
> и сколько будет запущено еще таких же "умников" с REALTIME_PRIORITY_CLASS/THREAD_PRIORITY_TIME_CRITICAL.
Самое смешное что системные процессы работают с меньшим приоритетом и к чему приведет такое положение вещей одному Гейтсу известно..
N169 (2003-07-18 17:15:00) [8]
>с портом напрямую ... giveo...
нет, мужик, тока хуже будет. Ибо теряем буферизацию --> вероятность потери данных увеличивается.
К тому же конфликтность с serial.sys
Замученный (2003-07-18 14:46:00) [9]
Читал, что можно работать с портом напрямую с помощью giveo.sys. Но как это делать не знаю. Может кто знает??
Verg (2003-07-18 14:42:00) [10]
Под NT (2000) можно попробовать задрать приоритет процесса и потока:
SetPriorityClass(GetCurrentProcess(),REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread, THREAD_PRIORITY_TIME_CRITICAL);
Только работать в таком потоке надо крайне аккуратно: для ввода с порта никакого полинга, только overlapped io+waitxxxxxx и т.п., а то повесишь все остальные потоки...
Может поможет, может нет - все зависит от того будут ли и сколько будет запущено еще таких же "умников" с REALTIME_PRIORITY_CLASS/THREAD_PRIORITY_TIME_CRITICAL.
А реально - только модернизацией самого устройства. Время-ориентированные протоколы обмена мало подходят для простых смертных приложений под винды. Либо писать специальный драйвер уровня ядра.
Замученный (2003-07-18 12:57:00) [11]
Пихаю я то, иначе бы он отвечал неправильно
pasha676 (2003-07-18 10:13:00) [12]
Что бы написать такой контроллер в девайсе, как задержка в 50мс и все падает (особенно при записи параметров), надо быть не совсем нормальным (особенно когда идет обмен по схеме "запрос-ответ"). Есть версия, что ты что то не то пихаешь в контроллер.
jack128 (2003-07-18 00:32:00) [13]
> Так что можно что-то сделать или нет, как ты думаешь?
ИМХО, нет (покрайней мере не под Windows). Если есть доступ к разработчикам устройства, то заставь их переписать программу контроллера (или пусть сами приведут пример рабочей программы)
Лёша (2003-07-17 19:58:00) [14]
...да, затянулась ветка!
...а главное без толку...
Замученный (2003-07-17 17:43:00) [15]
jack128 Извиняюсь, облажался :(((
Так что можно что-то сделать или нет, как ты думаешь?
jack128 (2003-07-17 17:25:00) [16]
И все таки по поводу времени, ты учти что эти формулы учитывают только физическую передачу сигнала через канал связи и не учитывают что винда думает, переходные процессы в приемопередатчике (UART - так он на буржуйском завется?)идут, устройство тотже думает, UART устройства тоже тупит ;-) и все это вместе дает твои 50 мс...
jack128 (2003-07-17 17:19:00) [17]
> 33/2400 = 0,00125
Купи колькулятор полудше :-)
Замученный (2003-07-17 16:53:00) [18]
Формат посылки - 11 бит: старт-бит(ноль), 8 бит данных, два стоп бита (единица), контроль по четности отсутствует.
В качестве теста выбрана команда $90 - проверка связи.
После распознавания этой комамнды девайс сразу же(без задержки) передает на ЭВМ трехбайтовое сообщение с кодом ответа $90.
Т.о., если я правильно понимаю имеем:
(8 бит + 2стоп бита + 1 старт бит)*3 байта ответа от устройства/2400 bps = 33/2400 = 0,00125 = 1,25 мс.
Я же имею 47 мс.
jack128 (2003-07-17 16:12:00) [19]
> После записи каждого коэфф. устройство сообщает, что процесс
> записи коэфф. закончился удачно и ждет след., если он не
> приходит (в течение 10 мс.)выскакивает ошибка
> Что касается скорости то она 2400 bps. Посылка 8 байт, 2
> стопа.
.
Предположу, что у тебя dcb.ByteSize := 8; тогда (8 бит + 2стоп бита + 1 старт бит)*8 байт ответа от устройства/2400 bps = 88/2400 = 0,036 = 36 мс, а тебе нужно еще второй коэфициэнт отправить, тебе не кажется, что ты ну никак не успеваешь? 10 мс это уж ОЧЕНЬ мало для таких скоростей
Замученный (2003-07-17 16:11:00) [20]
Так мне надо проверить ответ девайса и если он положительный, то ему посылается новый коэффициент, если нет, то показываем ошибку.
Как же я буду проверять, какой сигнал от него пришел, не используя эвент ComPort1RxChar? Вот я и смотрю, сколько времени требуется, чтобы сигнал дошел до девайса и получен ответ, чтобы его обработать в проге.
Может я и не правильно меряю время, не знаю. Однако коэфф. не пишутся и девайс выдает ошибку, что время ожидания прошло и он прекращает запись.
Эвент ComPort1RxChar возникает, как только в порт приходит символ.
Пробовал не использовать этот этот эвент. Считывал данные постоянно - та же самая ситуация.
| |
Страницы: 