Чтение с мультиметра через RS-232C

← →
DeepProg (2004-07-29 11:31) [0]

Работа с интерфейсом базируется на на коде, представленном в этой статье:
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 , если преопределить структуру(честно говоря, я этих действий пока побаиваюсь) и внести в нее это поле, то позволит ли это избежать чтения ненужного символа?

← →
DeepProg (2004-07-29 13:17) [1]

Еще один дополнительный вопрос:
Была такая дурость: зациклил отправку команды на device. Убрал эту глупость из кода. На сегодня, в результате тестирования, возникло подозрение, что device больше на команду не отвечает. Как проверить успешность отправки команды и достижение ею цели после WriteFile, если работа асинхронная?
Это в принципе возможно: вывести коммуникационные способности устройства зацикливанием ввода на него?

← →
DeepProg (2004-07-30 18:29) [2]

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

← →
GanibalLector © (2004-07-30 22:45) [3]

запусти PortMon и смотри...приходит,не приходит.Тайм-аут или не он.

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

← →
DeepProg (2004-08-01 15:48) [4]

За утилиту большое спасибо. Она позволила выяснить, что разработчики неправильно указали параметры порта своего устройства(XonChar, XoffChar, StopBits, XoffLim). Поэтому, device still Alive.

Теперь мне хотелось бы прояснить такие моменты:
1. Если не использовать структуру Overlapped и задавать даже очень большие тайм-ауты(например оба Multiplier=1000), то не считывается ни одного байта и операция чтения всегда завершается по тайм-ауту(тоже самое PortMon пишет и без использования тайм-аутов). Кроме того запись проходит всегда нормально, при любых тайм-аутах, а на чтение их установка кроме как в плане задержки не влияет.

2. Если использовать Overlapped(просто использовать даже не включая ожижание события или GetOverlappedResult), то чтение проходит нормально, но имеет место вышеупомянутая проблема пустого буфера. Непонятно с чем она связана. Требуется совет опытного человека, занимавшегося программированием разных устройств.
Так как с новыми данными о параметрах порта(600 baud, 7 bit, 1 stop, parity=none) обмен должен осуществляться еще быстрее ~307 мс, а по результатам тестирования при интервале(I/O обрабатывается в OnTime) уже и в 500 мс данные читаются скачками. Т.е. бывает что пару тиков счивается подряд, либо через тик(причем когда ничего не считывается, PortMon пишет success и Length 0).
Мне нужно знать хотя бы причинe: в кривости кода или в специфике device(т.е. ничего тут не изменить, или нужно к разрабочтикам обращаться)?
Кстати о коде - я свел его до примитива, т.е
Инициализация и настройка
1.CreateFile
2.Get/SetCommState
3.Get/SetCommTimeOuts
Ввод/вывод
1.WriteFile
2.ReadFile
Закрытие
CloseHandle

← →
GanibalLector © (2004-08-01 21:54) [5]

>Теперь мне хотелось бы прояснить такие моменты
Не нужны нам моменты...нам код подавай.Как инициализируешь,как читаешь,как пишешь???

← →
DeepProg (2004-08-02 02:00) [6]

Значит полагаете, что в кривости кода. Только кривости там нет, разве чт опримитивность.
Я не шучу - код действительно предсталяет собой указанную последовательность функций в самой стандартной реализации и ничего более - никакой специфики.
Что вы там хотите увидеть. Я скорее спрашиваю вас об этой специфике, которую нужно учесть в коде.

Давайте тогда так. Предлагаю задачу: вам даны параметры порта
BaudRate=600, Parity=NONE, ByteSize: 7, XON:1, XOFF:13, Shake=1, XonLim=0, XoffLim=1536
что не указано, то считать =0.
Какое время понадобится на однократное считывание данных с устройства если для этого нужно послать 2 байта и принять 14.
Ваше решение...

← →
DeepProg (2004-08-02 21:23) [7]

Ну так что? Возможно такой device опрашивать с частотой 4Гц или нет?

← →
N170 (2004-08-02 22:31) [8]

А у мультиметра разве 600 бод скорость?
Дома лежит такой, там 1200... Может, в скорости ошибочка...

← →
GanibalLector © (2004-08-02 22:40) [9]

DeepProg
Мой тебе совет...считывай для начала по одному.Поставь тайм-ауты.
И вообще ДАВАЙ на КОД посмотрим

← →
DeepProg (2004-08-02 23:34) [10]

Решения никто не дал.

N170
Я не говорил какой именно мультиметр у меня. Это раз. В мануале написано 600. Это два. Фирменный софт устанавливает 600. Это три.
Вопрос стоит так: почему расчет не совпадает с действительностью аж на 215 мс.

GanibalLector
Совет не понял, что значит по одному?
Code...
There is really nothing special.
Вот процедуры обработки порта. InitPort и ReleaseAll на своих кнопках, QueryPort вызывается в OnTime.

procedure InitPort; procedure QueryPort; procedure ReleaseAll; procedure SendComm; var Dev: THandle; DCB: TDCB; CT : TCommTimeOuts; ByteSent, ByteRead: dword; sValue: string; Ovr:TOverlapped; implementation procedure SendComm; var Send: array[0..1] of Char; begin FillChar(Send, SizeOf(Send), #0); Send[0]:="D"; Send[1]:=#13; WriteFile(Dev, Send, SizeOf(Send), ByteSent, @Ovr); end; procedure InitPort; begin Dev:=CreateFile(PChar("COM2"), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED, 0); PurgeComm(Dev, PURGE_TXCLEAR or PURGE_RXCLEAR); SetupComm(dev, 2048, 2048); GetCommState(Dev, DCB); with DCB do begin BaudRate:=CBR_600; Parity:=NOPARITY; ByteSize:=7; StopBits:=0; XonChar:=chr(1); XoffChar:=chr($D); XonLim:=0; XoffLim:=1536; end; //если дальше фигурные скобочки убрать, то вообще никогда ничего прочитано // не будет,а потом можно даже секундные тайм-ауты ставить - // тишина. И так пока фирменный софт не запустишь(см. конец поста). {SetCommState(Dev, DCB); CT.ReadIntervalTimeout:=1; CT.ReadTotalTimeoutMultiplier:=15; CT.ReadTotalTimeoutConstant:=10; CT.WriteTotalTimeoutMultiplier:=15; CT.WriteTotalTimeoutConstant:=2; SetCommTimeOuts(Dev, CT);} SendComm; end; procedure QueryPort; var Receive: array[0..13] of Char; begin SendComm; FillChar(Receive, SizeOf(Receive), #0); ReadFile(Dev, Receive, 14, ByteRead, @Ovr); sValue:=string(Receive); end; procedure ReleaseAll; begin CloseHandle(Dev); end; end.
Без Overlapped нужно использовать тайм-ауты - иначе прога повиснет(сами знаете), а к чему приводит их использование - см. коммент в коде.
Еще я "подсмотрел"(еще раз спасибо за PortMon) за фирменным софтом, который имеет свойство возвращать дар речи device"y после использования тайм-аутов.

Вот что я увидел:
1. Сначала выставляются такие настройки для порта(только измененные параметры)
BaudRate=9600, Parity=EVEN, ByteSize: 7, XON:11, XOFF:13, Replace=40, X<on/off>Lim=10
2. И только потом родные
BaudRate=600, Parity=NONE, ByteSize: 7, XON:1, XOFF:13, Replace=0, XonLim=0, XoffLim=1536
3. SetCommMask выставляет все возможные события.
4. Посылается предварительная команда "D", но ответ на нее не обрабатывается(мой код в этом случае всегда читает один символ #1, поэтому предварительную запись в файл я включил у себя в InitPort);
5. Пять раз вызывается комбинация WaitCommEvent и GetCommModemStatus
6. Выполняется посылка команды D и чтение с устройства, предваряемое троекратным вызовом комбинации ожидания события(см. 5)(полагаю, что отлавливаются DSR и CTS). - как вы уже заметили, у себя я не использую WaitCommEvent вовсе.
Ну и самое главное, почему готовой программой мы недовольны - ОНА НЕ ЧИТАЕТ БЫСТРЕЕ, ЧЕМ РАЗ В СЕКУНДУ.

Может будут какие-нибудь мысли по поводу вышеприведенной последовательности.

Ну все-таки что вы там насчитали со скоростью опроса?

← →
GanibalLector © (2004-08-03 00:57) [11]

1. Сначала выставляются такие настройки для порта(только измененные параметры)
BaudRate=9600, Parity=EVEN, ByteSize: 7, XON:11, XOFF:13, Replace=40, X<on/off>Lim=10
2. И только потом родные
BaudRate=600, Parity=NONE, ByteSize: 7, XON:1, XOFF:13, Replace=0, XonLim=0, XoffLim=1536

Дык этож самое главное!!! Таким вот образом девайс инициализируется.Кстати,после первой инициализации обычно посылается никий байт.

Имхо,попробуй тоже инициализировать дважды и получится.
И еще...ты запускал монитор в какой ОС???Очень рекомендую в XP.

← →
GanibalLector © (2004-08-03 01:15) [12]

>Ну и самое главное, почему готовой программой мы недовольны - ОНА НЕ ЧИТАЕТ БЫСТРЕЕ, ЧЕМ РАЗ В СЕКУНДУ.

Я вот вообще не пойму...зачем мультиметр цеплять к компу???У меня вот их несколько...и работаю с ним довольно таки часто,но нужды в подключении к компу не чувствую.
З.Ы. Лукавым тут пахнет.

← →
DeepProg (2004-08-03 17:56) [13]

ThanX за просвещение. Во всех имеющихся у меня manual"s ничего подобного сказано не было. О том, что оживляющий эффект дается этой "левой" настройкой я тоже думал, рад, что не обманулся.
И некий байт тоже уже посылается - SendComm в InitPort.

Еще: тайм-ауты фирменным софтом не используются(оно и ясно - режим асинхронный). Не думаю, что мне их тоже надо использовать, но поробую.

Теперь про ОСь - она указана в subj, равно как и версия Delphi. Только не понимаю, что значит "рекомендую"? Что это даст?

> Лукавым тут пахнет.

Попробуйте пройти этак 150 км исследуемой линии с IPAQ(мечта) или с notebook(реальность) и успевать записывать значения с частотой 4Гц в базу данных для последующего анализа. Если удастся сделать это без компа, то имеете право на патент.
Итак
МОЖНО ЭТОТ DEVICE ОПРАШИВАТЬ С ЧАСТОТОЙ 4Гц ИЛИ НЕТ?
С КАКОЙ МАКСИМАЛЬНОЙ СКОРОСТЬЮ МОЖНО ЭТО СДЕЛАТЬ?
ПРИВЕДИТЕ СВОЙ РАСЧЕТ PLS. ЭТО СЕЙЧАС ОЧЕНЬ ВАЖНО.

← →
GanibalLector © (2004-08-03 20:05) [14]

2 DeepProg
Так ШО,заработало???

>Только не понимаю, что значит "рекомендую"? Что это даст?
Ну...ты просто не видел что твориться в 9х с портмонитором.Ужас.Так что,все правильно - ХР навсегда.

МОЖНО ЭТОТ DEVICE ОПРАШИВАТЬ С ЧАСТОТОЙ 4Гц ИЛИ НЕТ?
Теоритически можно.Все зависит от твоего девайса.

С КАКОЙ МАКСИМАЛЬНОЙ СКОРОСТЬЮ МОЖНО ЭТО СДЕЛАТЬ?
Читать инструкцию по DEVICE,а не у нас спрашивать.

ПРИВЕДИТЕ СВОЙ РАСЧЕТ PLS. ЭТО СЕЙЧАС ОЧЕНЬ ВАЖНО.
А что ты имеешь ввиду под словом PLS ???

← →
GanibalLector © (2004-08-03 20:09) [15]

И еще...обычно настраивается так:
-первая инициализация Parity=EVEN
-посылка байта(в инструкции сказано какого именно)
-закрытие порта
-вторая инициализация Parity=SPACE // вот тут обрати внимание!!!Ну не видел я такого,чтобы вторая инициализация была NONE.Может у тя девайс какой-то навороченный???Но обычно SPACE
-стандартная работа по протоколу

← →
DeepProg (2004-08-04 00:40) [16]

сначала отвечу на [14]
Я кое о чем умолчал.
Developers of device устанавливают тайм-ауты так, чтобы передача немедленно прекращалась с возвратом уже принятого символа независимо от того есть он или нет(RI=MAXDWROD, RC=0, RM=0 и WI=0, WC=65000).
Теперь работает.
И самое удивительное, что считывается вся строка, а не один байт. У Титова написано:[I]"Значение MAXDWORD, вместе с нулевыми значениями полей ReadTotalTimeoutConstant и ReadTotalTimeoutMultiplier, означает немедленный возврат из операции чтения с передачей уже принятого символа, даже если ни одного символа не было получено из линии."[/I]).
Т.е. картина прямо противоположная тому, что мы имели при наличии нормальных или гнгантских тайм-аутов. 8/ Там не считывалось ничего и завершалось(по показаниям PortMon) именно по тайм-ауту. Сейчас же сплошной SUCCESS.
Кто-нибудь в состоянии объяснить почему так? Ответы типа -"особенность конкретного девайса", желательно раскрыть или послать туда, где могут раскрыть подобные особенности (только не к разработчикам!). Есть на земле разум, который клепал мозги подобным девайсам и способен донести до меня смысл такого странного поведения?

> Теоритически можно

Вы упорно уклоняететь от приведения этого тероретического расчета. Почему?
На чем вообще основано суждение о таковой возможности? ПРИВЕДИТЕ ЦИФРЫ

> Читать инструкцию

В документации устройства этого нет - только параметры порта. За кого вы меня, в конце концов, держите?
> PLS
Всю жизнь имелось ввиду "please". А вы что подумали?

Теперь касательно [15]
Обычно... Это, наверное, только у опытных такое выражние в ходу. Может где описаны всякие "обычные" ситуациии, чтобы мне на форуме воздух не сотрясать... Я понятия не имел даже о том, что нужно проводить несколько инициализаций.
Поэтому вопрос: сколько должно быть инициализаций?
насчет Paity. NONE- это уже "работа по протоколу", если я вообще правильно понимаю смысл этого выражения.
Device: METEX ME-32.

Наконец, может, все-таки, вернемся к вопросу о скорости?
1. Насколько достоверен обычно расчет скорости на основе неоднократно приведенных коммуникационных параметров устройства?
2. В чем обычно кроется причина несповпадения расчета с действительностью?
3. Есть ли возможность(прием, методика и т.п.) устранить несоответсвие?

Кто-нибудь в состоянии объяснить почему так? Ответы типа -"особенность конкретного девайса", желательно раскрыть или послать туда, где могут раскрыть подобные особенности (только не к разработчикам!). Есть на земле разум, который клепал мозги подобным девайсам и способен донести до меня смысл такого странного поведения?

Можно попытаться...только вышли лог портмонитора.

Вы упорно уклоняететь от приведения этого тероретического расчета. Почему?
А ты наверно думаешь,что я профессор и все могу и умею.Ошибаешся.Я не волшебник,а только учусь.
Ну да ладно.Моё ИМХО:
насколько я понял,ты сразу ждешь прихода 14 байт и все.Если так,то вот:
14*(7+1)=112
600\112=5,3571428571428571428571428571429
Но...ввиду того,что непонятно как ты работаешь с девайсом точно сказать невозможно.Почему???Да потому,что только одному тебе известно что должно входить в эту частоту(постоянная переинициализация девайса при каждом считывании или нет.)
Да и вообще,что тебе мешает попробовать считывать через 5..4..3 Гц и т.д.Попробуй посмотри.Или у тя девайса этого нет???В чем сложность???

Поэтому вопрос: сколько должно быть инициализаций?

Обычно одной хватает.Бывают случаи,что две(1 в самом начале,и сразу же переинициализация и нормальная работа).В твоем случаи...ты наверное уже догадался - две.

Наконец, может, все-таки, вернемся к вопросу о скорости?
1. Насколько достоверен обычно расчет скорости на основе неоднократно приведенных коммуникационных параметров устройства?
I>
Следует обратиться к литературе.Я обычно никогда ничего не считал и считать не собираюсь.Оно или работает или не работает.В конце концов метод проб и ошибок.
Отвечать на оставшиеся вопросы не имеет смысла.

Раз уж так необходим расчет, то приведу свои доводы.
Итак время одного цикла "запрос-ответ" состоит из:
1. Время посылки запроса (B*N/S - объяснения ниже).
2. ТО1 (объяснения ниже)
3. Время посылки ответа ((B/S+TO2)*(N-1) - объяснения ниже)
4. ТО3 (обяснения ниже).
Считаешь все четыре пункта, складываешь и смотришь, сколько раз за секунду сможешь это сделать. Быстрее, увы, никак.
Используемые обозначения:
B - количество бит, необходимых для передачи одного байта на физическом уровне (включая биты данных, стартовый бит, стоповый бит(ы), бит четности - если есть).
N - количество байт в пакете запроса или ответа
S - скорость работы порта (бит/сек)
ТО1 - максимальный промежуток времени между тем, как устройство приняло последний бит запроса и тем, как устройство начало отвечать.
ТО2 - максимальный промежуток времени между отдельными байтами в пакете ответа.
ТО3 - промежуток времени между тем, как устройство передало последний бит ответа, и тем, когда оно готово получать следующий запрос.
Все эти параметры должны быть указаны в документацию на устройство. Если что-то не указано - вычисляется опытным путем, либо (обычно проще) связываешся с разработчиками и уточняешь.

С уважением.

Кстати, ТО2 в некоторых особо специфичных протоколах может в обязательном порядке присутствовать и в пакете запроса, но звучит несколько иначе - МИНИМАЛЬНЫЙ промежуток времени между посылкой байт в запросе.

С уважением.

> 3. Время посылки ответа ((B/S+TO2)*(N-1) - объяснения ниже)

Еще одна поправка
3. Время посылки ответа (B*N/S)+TO2*(N-1)

C уважением.

← →
DeepProg (2004-08-05 11:24) [21]

Лог PortmMon для фирменного софта.(за форматирование не отвечаю)
14:08:55 ntvdm.exe IRP_MJ_CREATE Serial1 SUCCESS Options: Open
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_QUEUE_SIZE Serial1 SUCCESS InSize: 2048 OutSize: 2048
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_TIMEOUTS Serial1 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:65000
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_CHARS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_HANDFLOW Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_BAUD_RATE Serial1 SUCCESS Rate: 9600
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_RTS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_DTR Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial1 SUCCESS StopBits: 1 Parity: EVEN WordLength: 7
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_CHAR Serial1 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_HANDFLOW Serial1 SUCCESS Shake:1 Replace:40 XonLimit:10 XoffLimit:10
14:08:55 ntvdm.exe IOCTL_SERIAL_PURGE Serial1 SUCCESS Purge: TXCLEAR
14:08:55 ntvdm.exe IOCTL_SERIAL_PURGE Serial1 SUCCESS Purge: RXCLEAR
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_CHARS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_HANDFLOW Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_BAUD_RATE Serial1 SUCCESS Rate: 600
14:08:55 ntvdm.exe IOCTL_SERIAL_CLR_RTS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_DTR Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial1 SUCCESS StopBits: 1 Parity: NONE WordLength: 7
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_CHAR Serial1 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:1 XOFF:13
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_HANDFLOW Serial1 SUCCESS Shake:1 Replace:0 XonLimit:0 XoffLimit:1536
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial1 SUCCESS Mask: RXCHAR RXFLAG TXEMPTY CTS DSR RLSD BRK ERR RING
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:55 ntvdm.exe IRP_MJ_WRITE Serial1 SUCCESS Length 2: D.
14:08:55 ntvdm.exe IRP_MJ_WRITE Serial1 SUCCESS Length 2: D.
14:08:55 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:55 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:56 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:56 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:56 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:56 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:56 ntvdm.exe IRP_MJ_READ Serial1 SUCCESS Length 14: CA 0.002 nF.
14:08:56 ntvdm.exe IRP_MJ_WRITE Serial1 SUCCESS Length 2: D.
14:08:56 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:56 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:57 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:57 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:57 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:57 ntvdm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial1 SUCCESS
14:08:57 ntvdm.exe IOCTL_SERIAL_PURGE Serial1 SUCCESS Purge: TXCLEAR
14:08:57 ntvdm.exe IOCTL_SERIAL_PURGE Serial1 SUCCESS Purge: RXCLEAR
14:08:57 ntvdm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial1 SUCCESS Mask:
14:08:57 ntvdm.exe IOCTL_SERIAL_GET_MODEMSTATUS Serial1 SUCCESS
14:08:57 ntvdm.exe IRP_MJ_CLEANUP Serial1 SUCCESS
14:08:57 ntvdm.exe IRP_MJ_CLOSE Serial1 SUCCESS

GanibalLector
1. Раз учишься значит есть учебник. Какой?("литература" - понятие растяжимое)
2. Почему не считатся стратовый бит - тогда частота 4,76 Гц.(это я уже просто из вредности :))

wal
Я бы к вам еще с большим уважением, если б сказали, где вы эти доводы почерпнули?

GanibalLector
> В чем сложность???
Сложность была - вытянуть из вас этот расчет.
Теперь результат опыта: без тайм-аутов и ожидания события порта удается читать значения подряд с частотой 1,93 Гц(518 мс).

Теперь так. TO1-TO3 я попытаюсь выяснить. Если удастся - доложусь.
По предварительнм расчетам, принимая TO1=TO3=0, TO2=B/(2*S) имеем время уже в 450 мс - это похоже на правду...

> wal
> Я бы к вам еще с большим уважением, если б сказали, где
> вы эти доводы почерпнули?

Логика + математика + нехилый опыт работы со всевозможными девайсами и протоколами.
Кстати ТО1 ты зря за 0 принял, скорее уж ТО2=0 (ну не может устройство моментально начать отвечать, а вот без промежутков между байтами вполне может).

С уважением.

← →
DeepProg (2004-08-06 20:10) [23]

wal УВАЖАЮ опыт.
Даже если мой рачет ошибочен, боюсь, что вряд ли смогу заставить device разговаривать быстрее, чем он это делает при "заводских" установках см. [16] Или все-таки возможно?
All
Давайте теперь дальше про инициализацию.
Все-таки после перезагрузки мое творение не способно получить ответ от device до запуска фирменного софта. :(
SPACEPARITY пробовал - ничего не изменилось.
Может дело в тех нескольких IOCTL_SERIAL_WAIT_ON_MASK и IOCTL_SERIAL_GET_MODEMSTATUS, предшествующих, собственно, обмену полезной информацией?
Вопрос к опытным: каких сигналов(DSR,CTS...) рекомендуется дождаться прежде чем начинать опрос?
Что за параметр Replace? см.[21].
Моя первая инициализация его устанавливает в 0, как и вторая.
Фирменная же, напротив, выставляет его сначала в 40, потом в 0.

Чтение с мультиметра через RS-232C Найти похожие ветки