[fen]

Тема: Необходимо преобразовать данные, полученные с COM-порта (с бесконтактной карты EmMarine, поднесенной к proximity-считывателю) в десятичный формат (должны получить числовой идентификатор типа 61281581286128254128696102152254128120128254)

Код:

procedure TMainForm.ReadDataClick(Sender: TObject);
Var
  RCBuf:PChar;        //Буфер данных для приема
  nToRead:Cardinal;   //Число байт для чтения
  nRead:Cardinal;     //Число прочитанных байт
  ComStat:TComStat;   //Состояние порта
  Errs:Dword;
begin
  ClearCommError(POrt,Errs,@ComStat); //Считываем состояние порта
  nToRead:=ComStat.cbInQue;  //Считываем число байт для чтения из структуры
  nToReadLabel.Caption:=IntToStr(nToRead);  //Выводим на форму число байт для чтения
  ReadFile(Port,RCBuf^,nToRead,nRead,nil);  //Считываем данные
  nReadLabel.Caption:=IntToStr(nRead);      //Выводим на форму число прочитанных байт
  RcDataLabel.Caption:=RCBuf; //Выводим на форму считанные данные
end;

proximity-считыватель присоединен к порту COM №1
Порт открывается
Число байт для чтения: 11
Число прочитанных байт: 11
Данные принимаются, но в формате иероглифов (см. скрин)


Как эти данные преобразовать в человеческий вид. Типа в 61281581286128254128696102152254128120128254. Как реализовать это через массив, или другими способами?

[Aristarh Dark]

В hex однако приходит, тебе нужно в 10-чное преобразовать

[cotseec]

Код:

var
  i:integer;
  tmpDec,tmpHex:string;
begin
  tmpHex:='';
  tmpDec:='';
  for i:=0 to nRead-1 do
  begin
    tmpDec:=tmpDec+IntToStr(byte(RCBuf[i]));// для десятичных значений
    tmpHex:= tmpHex+IntToHex(byte(RCBuf[i]),2);// для шестнадцатиричных значений
  end;
    RcDataLabel.Caption:=tmpDec;// то, что вам надо
// или    RcDataLabel.Caption:=tmpHex;
end;

без разницы в чем приходит - ведь приходят значения байтов ... а вот как это дело интерпретировать - в Hex, Integer или ASCII (как вы пытаетесь, но видимо ридер отвечает не в ASCII) - головная боль разработчика обработчика

З.Ы. буфер для приема (у вас RCBuf:PChar) лучше делать как Pointer и перед чтением распределять память, а потом освобождать (PChar - указатель на строку, где конец строки обозначается байтом со значением 0, а если в ответе устройства будет значение нуля, то данные после нуля (да и сам нуль) вы потеряете)
З.Ы.Ы. IntToHex, вроде как, начиная только с Delphi7, если Delphi младше (всякое бывает), то IntToHex писать самому - ну а тут гугл в помощь
З.Ы.Ы.Ы. RFID'ами балуетесь?

[fen]

Сообщение от cotseec

Код:

var
  i:integer;
  tmpDec,tmpHex:string;
begin
  tmpHex:='';
  tmpDec:='';
  for i:=0 to nRead-1 do
  begin
    tmpDec:=tmpDec+IntToStr(byte(RCBuf[i]));// для десятичных значений
    tmpHex:= tmpHex+IntToHex(byte(RCBuf[i]),2);// для шестнадцатиричных значений
  end;
    RcDataLabel.Caption:=tmpDec;// то, что вам надо
// или    RcDataLabel.Caption:=tmpHex;
end;

Благодарю за работающий код.

З.Ы.Ы. IntToHex, вроде как, начиная только с Delphi7, если Delphi младше (всякое бывает), то IntToHex писать самому - ну а тут гугл в помощь

Да,на Delphi 7.

З.Ы.Ы.Ы. RFID'ами балуетесь? :

Переписываю с нуля программу по учету посещений, рабочего времени на предприятии.
Проблема осталась в том, что предыдущая программа интерпретировала данные с RFID-карты как 612815812861289619224825415824815830248 (40 знаков), по твоему алгоритму выдаёт данные 1111160254255160255110147 (26 знаков).
Не хочется 150 карточек сотрудников перезаписывать в базу, но судя по всему придётся.

[cotseec]

Сообщение от fen

Проблема осталась в том, что предыдущая программа интерпретировала данные с RFID-карты как 612815812861289619224825415824815830248 (40 знаков), по твоему алгоритму выдаёт данные 1111160254255160255110147 (26 знаков).
Не хочется 150 карточек сотрудников перезаписывать в базу, но судя по всему придётся.

а сколько за раз приходит байт? по идее как раз 26 (в моем примере цикл идет до значения количества пришедших байт), если так, то попробуйте увеличить системный буфер приема SetupComm, т.к. могут происходить склейки и разрывы данных, то накапливать данные в локальный буфер, а потом парсить. да и стоит попробовать просто посмотреть, что именно принимает переделываемая программа например вот этим и корректность скорости и прочих параметров стурктуры DCB
судя по разительному отличию данных "правильной" программы и вашей - вполне вероятно выставлена неверная скорость приема порта.

еще закрадываются смутные сомнения по поводу правильного понимания смысла приходящих данных т.е. их интерпретации... алгоритм, что я привел, подразумевает, что ридер присылает номер карточки никак "не обернутым" и в одном байте посылки содержится значение одной цифры номера...но это сможет показать уже тот же PortMon небезызвестного Руссиновича (ИМХО: программа хороша, но для коротких посылок/ответов; при размере посылки в 300 байт у меня отображала только первые 24 байта, но зато при отправке/приеме раз в 50-100 мс отлично себя показала), как альтернативу могу предложить Free Serial Port Monitor

[Konrad]

Сообщение от fen

как 612815812861289619224825415824815830248 (40 знаков), по твоему алгоритму выдаёт данные 1111160254255160255110147 (26 знаков).
Не хочется 150 карточек сотрудников перезаписывать в базу, но судя по всему придётся.

Тут проблема в том как ты рассматриваешь данные, ведь
FFFF=65535, а можно FFFF=256256.

Первое что нужно сделать перевести в НЕХ по-байтно и уже смотреть.
Тоесть скажем ты получил
11111000 10101010 01101001
Переводишь в НЕХ:
F8 AA 69
А дальше уже нужно смотреть что именно использует прога.

И как уже заметил Aristarh:
61 28 15 81 28 61 28 - не факт что тут не НЕХ.
Если у тебя постоянно 40 чисел, то тогда тут больше всего что не DEC а НЕХ.

[Konrad]

Так-с...
Дано 11 байт.
Получить 40 чисел.

3,6364 байта на число?

Даже если 3 числа на байт = 33 числа.
Это если преобразовывать 1-байт - его DEC-представление.
На самом деле меньше:
может быть число 0-9 (0,04) 10-99 (0,35) 100-255 (0,61)
тогда
11*0,04*1+11*0,35*2+11*0,61*3= 28,27 +/- разброс[ min 11 - max 33, наиболее вероятно 28, если строить график будет горка с вершиной в 28].
( и было получено 26, что не удивительно).

Если же преобразовать вместе:
256^11=309485009821345068724781056 (max 27 чисел).

Не получается никак

Переписывать базу 150 сотрудников не советую до тех пор, пока не убедишься что данные считываются полностью и правильно.


П.с.: а вообще это должны делать те, кто знает как нужно.

Я бы назвал то чем ты(ТС) сейчас занимаешся(эти пробы и ошибки, поиск алгоритма) аматорство и раздолбайство. Которое зачастую вылазит боком.

[fen]

Сообщение от cotseec

еще закрадываются смутные сомнения по поводу правильного понимания смысла приходящих данных т.е. их интерпретации... алгоритм, что я привел, подразумевает, что ридер присылает номер карточки никак "не обернутым" и в одном байте посылки содержится значение одной цифры номера...но это сможет показать уже тот же PortMon небезызвестного Руссиновича (ИМХО: программа хороша, но для коротких посылок/ответов; при размере посылки в 300 байт у меня отображала только первые 24 байта, но зато при отправке/приеме раз в 50-100 мс отлично себя показала), как альтернативу могу предложить Free Serial Port Monitor

большое спасибо тебе, уже разбираюсь.

Сообщение от Konrad

Переписывать базу 150 сотрудников не советую до тех пор, пока не убедишься что данные считываются полностью и правильно.

П.с.: а вообще это должны делать те, кто знает как нужно.

Я бы назвал то чем ты(ТС) сейчас занимаешся(эти пробы и ошибки, поиск алгоритма) аматорство и раздолбайство. Которое зачастую вылазит боком.

Благодарю за подсказки.
Действительно я не программист, а техник. Поверхностные знания по работе с COM-портом, и алгоритмами перевода систем счислений.Но опыт работы в delphi есть, программу почти закончил, остался последний момент с RFID-картами.Программа пишется по ходу свободного времени. Боков по ходу тестирования не наблюдал, вроде. Еще раз спасибо за направления, как закончу отпишусь.