Problems reading from a file

[Rkll]

Hey,

I have this file that I need to read so i can handle the contents. It was created in MSDOS and as I have very little experience in that topic, I wondered if anyone can point me in the right direction. I tried reading it as a ascii and binary file but neither work, I'm really just guessing though.

The file has no extension. Hence I can't upload it to the forum. Its made up of mostly meaningless strings of characters.

Any help is appreciated,

Regards,

Rkll

[smercurio_fc]

Can't tell you how to parse it without seeing it. You can simply add a .txt extension to it if you want to upload it. That won't change the format (despite the thousands of posters who think changing .bmp to .jpb will automagically change the picture format). Reading the file would have worked. I think by "not work" you mean parsing the data. A "meaningless strings of characters" implies some binary format. Reading the file into memory is trivial. It's interpreting the data that's your responsibility. You must have some idea of the contents. Where did the file come from?

[Rkll]

Ya you're exactly right, its parsing the data that is the problem. I have done what you said and attached it as a .txt file. My inital thought was that it was a collection of binary digits but I was unable to read them with the built in Labview read binary file VI. Although maybe I had a setting wrong or something.

I'm updating an old computer system and it stores all it's previous test results in files like these. Hence I would like to write a program to read each file and store the results in a new format. However, the initial job is to be able to parse the data.

[smercurio_fc]

---

Rkll wrote:

Ya you're exactly right, its parsing the data that is the problem. I have done what you said and attached it as a .txt file. My inital thought was that it was a collection of binary digits but I was unable to read them with the built in Labview read binary file VI. Although maybe I had a setting wrong or something.

---

This has nothing to do with the Read From Binary File VI, or any setting. That functions does not magically know the format of a file, just like any binary file read for any other programming language. Thus, you have to tell it how to interpret the data. You can tell it to read the file as a series of bytes, and it will dutifully return to you an array of U8 integers. Or, you tell it to read it as a series of 16-bit integers and it will dutifully return to you an array of I16. It will give you what you tell it to give you. 

Looking at the file I can see some header information, though it's not clear what all the spaces are being used for. I can't tell whether they're padding for a section, or what. As I noted, do you have any idea as to the format of the file?  You said you're updating an old computer system. Any documentation?

[Rkll]

Thanks, I understand what you mean. I wasn't sure of the complexity of the problem, so i posted this on these forums before i had a chance to search for any real documentation. I had hoped someone would find it straight forward and could easily help! I will look for documentation but in the meantime all I have found is the file attached, which i am told is a parsed version of a similiar file. Hope this helps..

[Rkll]

I recieved some more documentation on this file however I'm still having problems reading it.

Here's what i recieved from the man who wrote the DOS program:

Our standard data files are binary. We don't record the date/time in the file but anyone can get that from the date stamp on the file itself.

The tester number and the station number are stored in the file as follows:

The tester number and the station number are a 4 character alpha-numeric string. The first 3 characters are the tester number (actually could contain any alpha-numeric characters). The 4th character is the station number as an ASCII numeric digit.

the offset in the file for most files is 3306 (decimal). For files made by the new tester the offset is 7402. You can find out which type of file by checking the first 2 bytes in the file. The (Hex) ID for standard MAXX files is CCCC. For MAXX3 files it is 344D.

Anyone help me with this?

[smercurio_fc]

---

@Rkll wrote:

the offset in the file for most files is 3306 (decimal). For files made by the new tester the offset is 7402. You can find out which type of file by checking the first 2 bytes in the file. The (Hex) ID for standard MAXX files is CCCC. For MAXX3 files it is 344D.

---

That will tell you where to start reading to get at the data. But the response you were given doesn't say anything about the type of data that's being read. For example, when I look at the 1223CB01.061.txt file that you posted and I go to offset 0x0CEA (3306 decimal), I see the number 1201, followed by 257 bytes. How are you supposed to interpret these 257 bytes?

[Rkll]

I was in contact with the gentleman who wrote the program and he said that data mining in the binary file is needlessly complicated. We are currently working on a different solution. However, thanks very much for your help smercurio, the forums are always a gr8 place to come to with a problem.

- Rkll

[smercurio_fc]

---

@Rkll wrote:

I was in contact with the gentleman who wrote the program and he said that data mining in the binary file is needlessly complicated.

---

Looking at the file I had a feeling that was the case.

---

We are currently working on a different solution. However, thanks very much for your help smercurio, the forums are always a gr8 place to come to with a problem.

---

OK. Post back if you have further questions. Good luck.