download output format
Closed this issue · 14 comments
Please:
- consider separating output values with TAB characters, rather than white spaces
- add value/column headers
TAB separated values can be imported to Excel and other tools more easily.
Using tabs would allow for treating sample date and time as one field value, rather than two values which, typically, later have to be combined.
A configurable separator may be an idea for future versions but it is not 'must have'.
Done, please check if it's ok.
Configurable separator can be added later.
Which branch/commitment should I check?
master branch. I have removed the others.
I am not showing headers and TAB separators in recordings output of the most recent version.
Am I missing something? File attached
Fluke-J1.txt
.
Wrong version uploaded (too much versions here)...
It should be good now.
Now first line doesn't match this excel format.
What should it contain if kept?
It gets better but:
- I consistently get this error after the 5th data line is read:
Traceback (most recent call last):
File "Fluke289-K.py", line 573, in <module>
switch[sys.argv[2]]()
File "Fluke289-K.py", line 463, in do_recordings
str(measurement['duration']) + '\t',end=' ')
TypeError: must be str, not int
The 6th line contains: 2022-02-16 23:33:17 9.99999999e+37 ADC 9.99999999e+37 ADC 0 ADC 9.99999999e+37 ADC 0 STABLE
2. There is no header line so the user must guess what each column contains
3. As far as the recording header, I would just keep it as it is.
I have made the necessary corrections
Now it looks very good :)
I have a second thought, probably this line could be further improved to be more parser friendly.
Recording 5 (detail) [2022-02-16 23:33:02 - 2022-02-17 19:50:11] : 5444 measurements
I think it should contain the same data in same order recordings list command returns but with field names. E.g.
ordinal 5, name Recording 5, start 2022-02-16 23:33:02, stop 2022-02-17 19:50:11, duration 00:20:17:09, measurements 5444
Note values are comma separated - it simplifies parsing.
It may make sense to return start/stop date and duration. What do you think?
Btw, it is always good to use consistent naming (measurements or samples but not both).
Btw, it is always good to use consistent naming (measurements or samples but not both).
I'm note sure I understand what you mean.
For recordings, first line contains the number of measurements
In the lines that follow (detail), there is the number of samples for each of thesemeasurements
Are you talking about this or something else?
For the first line, here's how Flukeview Forms display it (here in french):
We can therefore consider that it is up to the user to decide how to use them.
So it's ok for the format you mention.
ps: Flukeview Forms displays #samples and # events...
ic, so samples and measurements are not the same thing.
I think it's finished now with this last commit
Do you confirm?
Index 1, name Recording 5, start 2022-02-16 23:33:02, end 2022-02-17 19:50:11, duration 00:20:17:09, measurements 5444
only Index is upper case
Start Time Primary Maximum Average Minimum #samples Description
Only #samples is lower case, Description probably/rather should be Type.
I am wondering if type (e.g. ADC) should be repeated 4x after each value (pri/max/min/avg) but maybe it should.
Besides the above I think this tool is in much greater shape and actually very handy.
One major outstanding issue: stability.
Two possible improvements: 1. configurable list separator, 2. event count retrieval, 3. standardized commands options e.g.
dmm_util --help
dmm_util show --info --port COM1
dmm_util read --measurements --port COM1
in a similar fashion it is handled e.g. by commander
One more recordings defect I just spotted. Measurement line reads:
16-02-16 23:33:02 2.621 ADC 2.6251 ADC 2.6185 ADC 2.5307 ADC 24 STABLE
Note that the date is incorrect.
I must be tired, I'm starting to make stupid things.
It's corrected.