Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Чтение с мультиметра через RS-232C [D6, WinXP]

Страницы: < 1 2
DeepProg © (2004-07-29 11:31:00)
Работа с интерфейсом базируется на на коде, представленном в этой статье:
http://www.delphimaster.ru/articles/comport2/index.html
Задача 1 Чтение по нажатию кнопки на Form:
Нажимаем кнопку(на форме):
WriteFile - посылаю 'd'
(заставляет мультиметр начать однократную передачу данных - текущего содержимого экрана)
ReadFile - считываю данные
а) Если код ReadComm незацикливать в отдельном потоке(мне очень не нравится постоянная загрузка процессора), то
Если нажимать достаточно часто(представьте, что расстреливаете бота из полуавтоматического оружия :) ), то
вместо содержимого экрана мультиметра читается крякозябра. При debug'e, показалось, что это символ #1.
Что это значит? - На момент выполнения ReadFile, буфер пуст?
Касательно времени скажу, что:
Параметры порта такие 600 baud. 7-биное ASCII-кодирование, NoPARITY и 2 stop-bits.
Расчет принять 14 bytes(лучше, конечно, 13 - последний символ всегда #13 - он не несет смысловой нагрузки, но пока будем рассчитвывать на весь буфер):
Один символ физически 1+7+2=10 bits
время на один символ->0.016666667 c =>
ReadTotalTimeoutMultiplier=WriteTotalTimeoutMultiplier=17
интервал м/у символами~0.008333333 с => ReadIntervalTimeout=WriteTotalTimeoutConstant=ReadTotalTimeoutConstant=9
вообще-то вся строка должна считаться за 14*0.017+13*0,0083=0.3416 с
Может в данной ситуации тайм-ауты и не нужны или, хотя бы, не при чем: с ними или без них проблема жива.
b) Если код ReadComm зацикливатьв отдельном потоке(практически без изменений код статьи и без тайм-аутов), то многократное тыканье по кнопке на вывод дает только показания с мультиметра, без всякого там #1, но не по каждому нажатию кнопки.
Я не понимаю, как в этой ситуации удается пропускать и не писать этот символ #1 - никакой проверки на то, что именно считывается нет.Есть мысль о том, что зацикленная в отдельном потоке ReadFile всегда попадает на заполненный буфер.

Задача 2
Очень вероятна. Формулировка: "прочитать показания, как только они изменятся" - это нужно сделать очень быстро, хотели даже читать раз в четверть секунды.
Вопрос: если я правильно оценил время ввода/вывода(выше), то за 250 мс с данным прибором обменяться данными невозможно, это так?К тому же, у меня только одна идея относительно реализации проверки наличия измений - читать и сравнивать, что поступило на вывод в прошлый и в очередной раз.

Если привязать вышеописанную последовательность действий(без зацикливания) I/O таймеру и установить интервал даже в 400 мс, то вместо содержимого экрана мультиметра периодически в строке вывода оказывается неизветсный символ #1.

Дополнительный вопрос:
В модуле Windows в D6 структура DCB не имеет поля fNull: Bool , если преопределить структуру(честно говоря, я этих действий пока побаиваюсь) и внести в нее это поле, то позволит ли это избежать чтения ненужного символа?

GanibalLector (2004-07-30 22:45:00) [21]
запусти PortMon и смотри...приходит,не приходит.Тайм-аут или не он.

Кстати,статья та поганая...Если у тебя девайс посылает нули,то не увидишь ты их.

DeepProg (2004-07-30 18:29:00) [22]
Право же господа, я не о таких уж сложных вещах спрашиваю...
Это больше на игнор смахивает, не пойму только за что.
Я все бьюсь с мультиметром.
В синхронном режиме отсылаю команду.
WriteFile=true и lpNumberOfBytesWritten не Null, а ответа от порта нет.
Команду посылаю как массив символов. Пытался также и #13#10 приписывать - не отвечает.
Сейчас больше всего заботит самый последний вопрос из [1]: Is It Alive? Есть вообще хоть какие-то соображения?

DeepProg (2004-07-29 13:17:00) [23]
Еще один дополнительный вопрос:
Была такая дурость: зациклил отправку команды на device. Убрал эту глупость из кода. На сегодня, в результате тестирования, возникло подозрение, что device больше на команду не отвечает. Как проверить успешность отправки команды и достижение ею цели после WriteFile, если работа асинхронная?
Это в принципе возможно: вывести коммуникационные способности устройства зацикливанием ввода на него?

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »