PTR record changes even when just reading and writing under a different filename

[itshakefraimov]

Tasks/Steps/Elements

Took a stdf file and just written it under test2.stdf

with open('test2.stdf', 'wb') as new_stdf: for REC in STDF.records_from_file(f): new_stdf.write(REC.__repr__())

I generated SORT Parametric Data from the stdf and some PTR coords changed to PASS when they were FAIL.

When comparing even in sizes. test2.stdf is now 2x the original stdf.

Versions checklist

• Spyder version: >= 5
• Python version: 3.7, 3.8
• Qt version: all
• PyQt version: all
• Operating System name/version:
  • client : Windows/Linux/macOS

[Bagyidaw]

Can you verify reading of PTR records produce expected values?
and can you share what are you trying to solve?

[Bagyidaw]

I have submitted pull request. please test this version

#66

[itshakefraimov]

I have submitted pull request. please test this version

#66

TEST.1.std.zip
Still doesn't work. Here's a stdf file I'm using.

My end-goal is to change fields in the STDF file.
However, just doing a simple read ALL records and then write ALL records under a different name using this library makes the new STDF file 2x the original size and it also doesn't write all PRR records correctly.

Try this code to see yourself.
with open('test2.stdf', 'wb') as new_stdf: for REC in STDF.records_from_file(f): new_stdf.write(REC.__repr__())

[Bagyidaw]

writer will always write optional fields for PTR/MPR/FTR even if original file omit them. that's the reason file size is bigger.

it's documented in STDR.py repr method
# Optional Fields and Missing/Invalid Data at page 13 is not fully
# implemented as it is stated :

[itshakefraimov]

writer will always write optional fields for PTR/MPR/FTR even if original file omit them. that's the reason file size is bigger.

it's documented in STDR.py repr method # Optional Fields and Missing/Invalid Data at page 13 is not fully # implemented as it is stated :

Oh I see, I missed it.. thanks

In regards to your PR #66 - can you explain what exactly did you fix? does current pack method is incorrect and can cause incorrect bits to be packed into a record?

[Bagyidaw]

It's not that it's incorrect in unpack,
the code for unpack translates B*1 in ascending order (2 ^ 0, 2^1, .. 2 ^ n etc in list) but in pack it's reverse.

so i fixed unpack to use the same order as in pack.

e.g byte value 0x01 in unpack return ['1', '0', '0', '0', '0', '0', '0', '0']
if you're to pack but the same value using pack method, it would be wrong value 128 (not 0x01)

unpack

                        for Byte in range(len(temp)):
                            for Bit in range(8):
                                mask = pow(2, Bit)
                                if (temp[Byte] & mask) == mask :
                                    result[(Byte * 8) + Bit] = '1'

pack

                    for Byte in range(bytes_to_pack):
                        byte = 0
                        for Bit in range(8):
                            if ValueMask[i][(Byte * 8) + Bit] == '1':
                                byte+= pow(2, 7-Bit)

relevant discussion here #52