Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
This is DATA 1
RE00002200050046\00 0.00 0.1 0.125.9\0#####-  14    0##### \0   0#####   141.0\004.00 0: 00.000.0\00 4: 011:27 0: 015:27#\0###########2.00.0\0
 

Another data that i have is
This is DATA 2
RE000022601\0500460 0.00 0.1\0 0.236.8####\0#   57-   2#####-   3#####\0-  601.004.0\00 4: 00.000.\000 4: 013:37 0\0: 017:37#####\0#######2.00.\00
 
The above data is the response i get from an hospital machine,i have to parse the above values and fill it according to given format:-
BYTEs  2         2         4             128            2         2
   +---------+--------+------------+-----------------+--------+-------+
   |  RE     |  00    |  machine no|   Data part     |  Check | CRC   |
   |         |        |            |                 |   sum  |       |
   +---------+--------+------------+-----------------+--------+-------+ 
As you can see from DATA 1 My data part begins from "000500.."
and DATA 2 My data part begins from "601\0500..."
While doing parsing i got into a problem that there is field named "Blood pump flow" whose length is 3 bytes from the "DATA 1" we get its value as "46" while from the
"DATA 2" i got its value as "460".
In actual its value should be "460"
If i get a data like DATA 1 my whole parsing logic suffers as because as "Blood pump flow" is "3 bytes" i get a value "46\0" and "0" is added to another field while "Blood pump flow" should be "460".
The above is just one case i get it many times for some other fields too.
How to resolve this problem.
Posted 3-Oct-12 23:17pm
Comments
CPallini at 4-Oct-12 4:37am
   
I suppose those NULL characters are spurious. How do you get the packets?
Tarun Batra at 4-Oct-12 5:19am
   
I send the command to machine then i get the response through socket programming
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

It looks like you're getting your records in multiple packets, and appending a '\0' to each packet.
 
Don't do that. You have fixed length records. Append the packets according to the exact number of bytes that the recv statement returns to you.
 
You should not be inserting extra characters.
 
If you have no control over this, you may be able to simply pre-scan the string and remove the '\0' characters. Fixed length ASCII records normally don't contain null padding, so this is probably safe.
 
Refer to the manufacturer's documentation to be certain.
  Permalink  
Comments
CPallini at 4-Oct-12 15:33pm
   
Yes, makes sense.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

struct record
{
    // other fixed fields here

    char blood[5];
    char flow[3];
    char time[6];
    // remainder of structure fields ...
} data;
char buff[16];
int value;
 
strncpy_s(buff, data.blood, sizeof(data.blood));
int value = atoi(buff);
cout << value << endl;
strncpy_s(buff, data.flow, sizeof(data.flow));
value = atoi(buff);
cout << value << endl;
strncpy_s(buff, data.time, sizeof(data.time));
value = atoi(buff);
cout << value << endl;
//
// ... and so on
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

You resolve this problem by getting the details of these pumps from the manufacturer, and finding out the exact format of all the data that they produce. Continually asking questions here when we have no details of these machines is not going to help you. This project sounds to me to be far too important (people's lives depend on it) to be created based on a lot of guesswork and your lack of programming experience.
  Permalink  
Comments
Tarun Batra at 4-Oct-12 4:28am
   
Thanks for the reply but the packet that i have i have shown you and i have details of the field such as there name and length which all combine to form the data part.Should i write that and i can't get the details from the manufacturer.
Richard MacCutchan at 4-Oct-12 4:44am
   
But you are still guessing the content of the data part, which is the most important part. Unless you can get the exact detail of this data then you are never going to have a working program. Someone must be able to provide this information for you. Why can you not get this information from the manufacturer? Who is asking you to write this code? You really need to take a different approach to this project and get the important details before writing any code.
Tarun Batra at 4-Oct-12 5:53am
   
i know the data part details you can see the the fields that data part has on the following link http://stackoverflow.com/questions/12723177/my-whole-parsing-logic-suffers-because-of-null-character-how-to-resolve-this it contains a pic that contains the data part fields and its length
Richard MacCutchan at 4-Oct-12 6:04am
   
So you have the actual layout of the data and from that you can define the structure of each record. If you know that a field contains only 5 bytes then you can parse or extract that quite easily. If the actual value in that field is only 4 bytes long and the last byte is a null byte then the conversion routines will accept that. If you really do not understand how to approach this problem then you should spend some time looking at struct types and the various conversion routines available.
Tarun Batra at 4-Oct-12 6:18am
   
i have made the parsing logic you can see that too at http://codereview.stackexchange.com/questions/16194/my-whole-parsing-logic-suffers-because-of-null-character-how-to-resolve-this
Richard MacCutchan at 4-Oct-12 6:29am
   
And your parsing logic is wrong because it does not handle the situation when a field is less than the maximum number of characters. You need to extract the fixed number of characters from each field into a separate buffer, add a null byte to ensure it is correctly terminated and then convert the resulting string into its appropriate value. I will add some code below to make it clearer.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 575
1 Kornfeld Eliyahu Peter 409
2 Maciej Los 369
3 DamithSL 196
4 OriginalGriff 188
0 OriginalGriff 6,353
1 DamithSL 4,854
2 Maciej Los 4,466
3 Kornfeld Eliyahu Peter 4,058
4 Sergey Alexandrovich Kryukov 3,897


Advertise | Privacy | Mobile
Web04 | 2.8.141220.1 | Last Updated 4 Oct 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100