Имеется денситометр Brumagic 30-летней давности, который свои измерения передает по протоколу RS-232 (300 бод, 8 разрядов без бита чётности, 1 стоп бит). Судя по описанию, он шлёт текстовую строка вида "Фильтр (Символ), пробел, цифра, точка, цифра, цифра, пробел". К нему в давние годы была написана программа под DOS, которая в принципе ещё работает. Но есть проблемы её использования на современных компьютерах, в т.ч. из-за жесткой привязки к COM1. Я настроил в Delphi 6 компонент CommPortDriver на указанные параметры и получаю от прибора строчки по 8 байт на каждое измерение. Проблема в том, что они совершенно не похожи на ожидаемый формат. Например, измерению c ожидаемым результатом "B 1.14 " соответствует массив байтов "42 AF 41 20 B1 0D B1 B4". Вероятно, существует какая-то разница в организации приема по COM от прибора, ориентированного на 16 разрядные компьютеры и современными моделями 32 и 64 разрядности под Windows... Прошу совета, как преодолеть данное затруднение.
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
02-03-2024 09:50 | Комментарий к предыдущим ответам
>>>принимать на веру то что - "B 1.14 " соответствует массив байтов "42 AF 41 20 B1 0D B1 B4" я бы не стал.
Ну как бы - 42 AF 41 20 B1 0D B1 B4
Несколько таких строк надо для проверки, а так всё правильно. Прибор древний, микроконтроллер в нем маленький, шлет данные свой программе и не обязан соблюдать кодировку если это ведет к упрощению прошивки.
Автор похоже на него забил, а разобраться было бы интересно.
В свое время очень даже помогал Microsoft Word. Непрерывную последовательность байт в HEX открываешь и при равномерном заполнении абзаца с непропорциональным (символы одинаковой длины в пикселях) начинаешь увеличивать/уменьшать правую границу абзаца. Визуально четко просматривается периодичность.
Предположу, что, и денситометр, и компонент CommPortDriver на выходе выдают уже преобразованные данные. Поэтому не стоит разрабатывать программу, без знания того, что в действительности приходит на com-порт.
Посмотрель какие данные приходят на com-порт в действительности можно с помощью "программ просмотра RS-232 и com-портов". Например, там: http://www.softelectro.ru/rs232.html
приведено описание работы с com-портом на низком уровне и программа, отражающая состояние приходящих на com-порт данных.
Поддержу замечание W0lt. Действительно, данных предоставленных вами маловато. Желательно, для их анализа, увидеть несколько "показаний денситометр" и соответствующих им, "полученным данным".
Данных предостваленных вами маловато, кроме того, принимать на веру то что - "B 1.14 " соответствует массив байтов "42 AF 41 20 B1 0D B1 B4" я бы не стал. Сходу я так не вижу решения. Но есть общие рассуждения, которые вам возможно помогут.
1. Почти наверняка должен быть какой то разделительный символ, чтобы можно было определять начало и конец посылки. Если передавались чисто строковые данные, то логичны два варианта, либо последний бай равен нулю, либо символу конца строки.В приведенном вами примере строковая последовательность длиной в 7 байт, тогда как байтовая последовательность длиной 8, что вобщем то как раз соответствует той логике, что должен быть символ конца посылки. Причем в байтовой последовательности присутствует байт 0D, который как раз и мог бы являтся таким разделительным символом, но он расположен внутри последовальности , а не в конце, и тут уже тоже ветвление возможностей: может вы не правильно определили, что ожидаемой строке соответсвует именно эта последовательность (как вы там данные из компорта читаете неизвестно), либо это не разделительный символ. В байтовой последовательност есть байт 20 который как раз соответсвует пробелу, но он один такой, так что тут тоже не понятно. Надо также иметь ввиду, что для кодирования строковой последовательности существует несколько возможных вариантов кодировок, и уж во времена DOS совершенно точно кодировка была не та, что используется Windows сейчас, кстати символ "B" - это латинская буква или кирилица? Пока слишком много неопределенностей, но возможно поставленные вопросы и попытка ответить вам самому на них вам поможет.
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
