10-28-2013 11:01 AM
I'm afraid I know relatively little about DIAdem-DAC, so we'll have to hope someone else answers your question about what changes in the DAC scheme cause different file extensions. I do know that DAC schemes create binary data files with different extensions that correspond to the data type, so perhaps *.S0# files are "single precision" files (32 bit float), but that's just a guess on my part.
The *.DAT file and the *.R64 file you posted load perfectly in my DIAdem-- 111081 points that make a nice square wave. I was expecting you to post the *.S0# files you talkes about, along with the header file. I'm surprised that DIAdem 9.1 still created *.DAT header files instead of the *.TDM header file that debuted in DIAdem 9.0, but both work fine.
DIAdem Product Support Engineer
10-29-2013 01:30 AM
yes it is like you say. W03 holds Word16 values, S04/S03 holds Real32, D04/D03 holds Real64 and R64 means also Real64.
R64 is created by the Diadem data file navigator. If you import i.E. an Excel data file and save it as .DAT then .R64 is created.
Our problem was that we use matlab for data analyzing and the first version of the tools were searching for .S03 files. Then the extension suddenly changes and we thought that something in the data format has changed too. But everything seems to be ok, only the extension changes sometimes. We now use the header file information for opening the binary files and that works for both. But it would be interesting for our understanding of Diadem what are the reason for this new .D04. So if you here something about it let us know. Maybe it is for compatibility with Labview format?
Thank you very much for your help
07-03-2014 12:54 AM
Good morning Brad, Good morning Josef,
I see this is an old topic (last post October 2013); and I just would like to be sure I've understand it well:
0. we have a test bench, it is running autonomously
1. if measuring with a DAC,
2. what has been set up to store each test in "DAT" format automatically
3. then Diadem will decide in what form "DAT" the data will be stored (float; integer; 8 bits; 16 bits; 64 bits; etc.)
4. DD will decide about the file extension of the binary data (the header file is ".DAT"; as selected)
5. and these decisions of DD cannot be influenced at all.
My question would be the last point.
We have such a test bench we are using for ages. Until yesterday all the files were stored in DAT/W16 format. Now we have DAT/D04. We were surprised about this change - however we know that everything works well even on this way. The only problem might be: D04 is a floating point format with 4 bytes(?); W16 is an integer (fix point) format with 2 bytes. The new data are 2-3 times bigger.
Thanks in advance for your respond!
07-03-2014 01:43 AM
just i have seen your message. Yes, that seems to be one of the surprising features of Diadem. What version do you use?
Until now i have no idea what exactly takes influence to the extensions.We use version 9.1.
We only found that changes in .dac file sometimes create different file formats but you write that you have this effect "over night".
Or have you changed something too?
.D04 holds Real64 data so it is normal that the file size grows but why Diadem suddenly creates .D04 - sorry, i have no answer.
We have now a newer version 11 and i will try the three demos from the .zip file i have send to Brad some month ago.
So let's look what happens.
07-03-2014 02:29 AM
Thanks for the rapid answer.
We use Diadem 11.1.
It happend "over night" - but not without any other steps.
I've asked my colleague working with the bench:
- before last wek it was DAT/W16
- last week the bench has been "tuned" (some new HW for testing some new features)
- the DAC has been extended accordingly (new features send new data)
- unfortunately I don't know what has been changed in the DAC; and nobody knows which DD version was used to create the original DAC (we use DD for more than 10 years; 8.1 that time)
- and after this DAC update we have D04.
As I wrote: everything works well, D04 is also OK for us.
The only question was if we may influence the change of data type and resolution?
Yes: we influence it if we change something in the DAC - but no: we cannot define the file format.
07-03-2014 03:33 AM
yes, that is the result. At least if you only use the DAC components for opening a file.
Maybe it is possible to define a format if you use file-commands in a VBS script
but i have never tried this.
We have no trouble with this effect but it is surprising that no one can explain the reason.
07-04-2014 12:49 AM
I record data with scripts, and this is OK from all points of view, even file formats are set up by scripts as I want (TDM, DAT, etc. Even XLS is possible; but I've already forgotten how I did it:( ).
This automatic S03, S04, D04 etc. selection seems to belong to the DAC: on the bench we don't use scripts, but the DAC has been set up to automatic recording with increasing numbers.
I think DD tries to determine "the best" format for the given DAC, and if there are some "complex" boxes, like calculating by function box, floating point will be set up, since the calculation may be done also on R64.
This might be the reason why we cannot influence this behaviour.
PS: I tried to send it yesterday, but I couldn't log in to this site
07-04-2014 05:54 AM
I try to explain how DIAdem-DAC chooses the extension for the binary parts of the DAT-files.
The letter stands for the data type D03, D04... is double precision (R64) and S03, S04... is single precision.
How does DIAdem select the data type?
It's the hardware driver who determines the data type. If no calculations are done in the DAC scheme, this data type stays unchanged.
Changing the measurement hardware can result in a different data type of the stored data files.
With calculations the data type is changed to double (R64).
What about the number in the extension?
The number is the ID of the DIAdem-DAC measurement task which is represented by a system clock block.
The default clock (no connected clock block) has ID=1. The task with first connected clock block gets ID=3, the second connected clock is ID=4 and so on.
If you have different system clock blocks in your DAC scheme and change something, the internal sorting of the tasks can change. The result is a different number in the file extension.
I hope this explains the questions in this thread.