I started analyzing ECLab.exe, here are my first results

[ilka-schulz]

I started looking at the installed EClab.exe (version 11.36) and found some interesting data. Apparently, all column names are stored in a sorted array at 0x143E56D and continuing:

# Maps from colID to a tuple defining a numpy dtype
# names can be read from installed EClab.exe (version 11.36 from 0x143E56D)
VMPdata_colID_dtype_map = {
    #TODO: ('ox/red', TODO),
    #TODO: ('error', TODO),
    4: ('time/s', '<f8'),
    5: ('control/V/mA', '<f4'),
    6: ('Ewe/V', '<f4'),
    7: ('dQ/mA.h', '<f8'),
    8: ('I/mA', '<f4'),  # 8 is either I or <I> ??  --> it is I/mA
    9: ('Ece/V', '<f4'),
    # 10: ('Aux/V', TODO),
    11: ('I/mA', '<f8'),
    # 12: ('log(|<I>/A|)', TODO),
    13: ('(Q-Qo)/mA.h', '<f8'),
    # 14: does not exist?
    # 15: does not exist?
    16: ('Analog IN 1/V', '<f4'),
    # 17: ('Analog IN 2/V', '<f4'),
    # 18: ('Analog IN 3/V', '<f4'),
    19: ('control/V', '<f4'),
    20: ('control/mA', '<f4'),
    # 21: ('control changes', TODO),
    # 22: ('log(|I/A|)', TODO),
    23: ('dQ/mA.h', '<f8'),  # Same as 7?
    24: ('cycle number', '<f8'),
    # 25: ('DQ/mA.h', TODO),
# ...
}

There are some bytes of variable length between the column names and it looks like they might contain type information. Anyways, I will work on this with low priority but I will share my findings as soon as I have more.

[ilka-schulz]

It looks like the bytes between the labels do not hold type information. They seem to be:

1. length of the unit string in bytes
2. unit string (e.g. V or mA)
3. one null byte
4. length of the label string
5. label string (e.g. time/s or control/V/mA)
6. 0..3 null bytes

At least I can now read all column labels and units. I think I will look further into this and try and find the type information.

[chatcannon]

Thanks @ilka-schulz , this looks very helpful. I will look at it in more detail next week when I have some vacation.

[ilka-schulz]

There is also an experimental way to find out all columns:

I think we could try to synthesize our own MPR files and add columns with different colIDs. For each colID, we could try different column widths (2, 4 or 8 bytes). We could then try to convert these MPR files to MPT files using the EC-Lab GUI.

@chatcannon If you could write the code to synthesize MPR files, I would manually do the work of converting them with EC-Lab. Judging from the strings found in the EClab.exe, there are around 250 different column IDs (some IDs are not used in the production EC-Lab software).

Anyways, I will probably start to work my way into disassembling. That might be the cleaner way and maybe that skill will be useful in the future ;)

[ilka-schulz]

I have been playing around with radare2 and ghidra but I was not able to retrieve the type information of those columns. I will now try to synthesize MPR files and let EC-Lab convert them to MPT files. I bet I can automate the process and let my program handle the EC-Lab GUI.

Anyways, I will be on holiday at the end of the year, so do not expect results for another month.

[fg-personal]

@ilka-schulz, did you see any change in EC-Lab 11.50? The galvani code isn't working for newer versions, but hopefully some small fixes in the "MPTfileCSV" function might be a temporary solution.

If you didn't, sorry for the dumb question, but which software did you use to check the exe file? (just to be sure I am not missing anything, I wasn't able to find this info with objdump)

[JhonFlash3008]

@fg-personal galvani has been updated and should work fine now with EC-Lab v11.50

[fg-personal]

I followed up the discussion in the other issue, looking forward for the new release (the one after 0.3.0) including the changes