Drawing of sheet entries

grypho commented 7 years ago

Added drawing of sheet entries. Actually all signal flow directions (in, out, bidi, unspecified) and all symbol directions (upper, lower, left, right edge) are supported. Also added more documentation for sheet entries.

grypho commented 7 years ago

Hi Martin,

@VADMIUM commented on this pull request.

Thanks for you work. I have a few questions, the major one being about an inconsistency with the _FRAC1 units.

In altium.py [1]:

@@ -385,7 +388,7 @@ def main(): parser.add_argument("--renderer", choices={"svg", "tk"}, default="svg", help=render.init.annotations["Renderer"]) args = parser.parse_args()

renderer = import_module("." + args.renderer, "vector")

renderer = import_module(".svg" , "vector")

Is it okay to drop this change?

OOps, yes. Please drop it, it was for testing purposes

In format.md [2]:

@@ -391,7 +391,10 @@ circ_angle = atan2( RADIUS sin(angle), SECONDARYRADIUS cos(angle) )

|SYMBOLTYPE=Normal: Optional

Sheet entry

-Child of Sheet symbol +Child of Sheet symbol. In SchDoc files you will first see a RECORD=15 which defines a sheet symbol. +That record is directly followed by multiple RECORD=16 entries which define the sheet entries for the previously defined sheet symbol. +Actually there is no other way to determine the parent-child relation.

Isn’t there an OWNERINDEX property that you can use to determine the parent? From memory if you give all the other records except the first (header) indexes starting from zero, the OWNERINDEX always points back to the parent.

No, neither the OWNERINDEX nor the other indices work for determining the direct parent. First I thought I could use it but after examining some SchDoc files, I had to drop the idea. At least in Altium 14, 16 and 17 (which I have installed on my work computer) it does not work.

In altium.py [3]:
     ):
obj.check(name, value)

obj.get("HARNESSTYPE")

obj.check("SIDE", None, b"1")

obj.get_int("INDEXINSHEET")

obj.get_int("DISTANCEFROMTOP")

obj.get_int("STYLE")

obj.get_int("IOTYPE")

obj.get("NAME")

obj.get(property)

if self.last_sheet_symbol:

with self.renderer.view(offset=get_location(self.last_sheet_symbol)) as view:
I wonder if you can get automatic access to the parent sheet symbol as objects.properties, i.e. you could call get_location(objects.properties) etc. I think “objects” was meant to be the parent or owner object. I could probably use a better name :)

Yes, you could reverse-search the objects list for the last sheet symbol. BUT in all cases I examined, the sheet symbol was defined directly prior to the sheet symbol entries. Using the child relation in the objects works for most types.....but sadly not for sheet entries:

In this example you can see a RECORD=15 which defines a sheet symbol with INDEXINSHEET=1. Directly afterwards some sheet entries are being defined, all with OWNERINDEX=37.

In altium.py [4]:

@@ -259,6 +259,7 @@ def get_int_frac(obj, property): '''Return full value of a field with separate integer and fraction''' value = obj.get_int(property) value += obj.get_int(property + "_FRAC") / FRAC_DENOM

value += obj.get_int(property + "_FRAC1") / FRAC_DENOM #sometimes FRAC1 is used instead of FRAC.

Your code below has get_int_frac(obj, "DISTANCEFROMTOP")*10. Suppose there is DISTANCEFROMTOP=10 and DISTANCEFROMTOP_FRAC1=500000 (500 thousand). According to format.md, this should give a final result of 105 in the usual units. But according to my reading of the code, you are returning value = 10 + 500,000/100,000 = 15, and the caller will multiply that by ten to get 150. Something’s not right.

You could be right, this is strange. I will check it. Can you please reject my pull request, I will clarify this and send another request.

In altium.py [5]:
     ):
obj.check(name, value)

obj.get("HARNESSTYPE")

obj.check("SIDE", None, b"1")

obj.get_int("INDEXINSHEET")

obj.get_int("DISTANCEFROMTOP")

obj.get_int("STYLE")

obj.get_int("IOTYPE")

obj.get("NAME")

obj.get(property)

if self.last_sheet_symbol:
It looks like last_sheet_symbol is only set inside “handle_sheet_symbol”, so I think this would give an exception rather than be false, right?

You are right. If you have a valid SchDoc file handle_sheet_symbol will always be called prior to the sheet entry drawing routine. I will rework this part. Maybe this results from the fact that I am learning python for three days now. Normally I am working with other languages. ;-)

vadmium commented 7 years ago

About "objects.properties" versus "last_sheet_symbol", I was assuming that you could rely on OWNERINDEX working. So if the index isn't working, ignore that suggestion.

But I am skeptical. The indexes that OWNERINDEX refers to are implicit. I think INDEXINSHEET is irrelevant for the parent-child relationship. (Perhaps it is related to deciding which objects are drawn over the top of other objects; I dunno.)

You may be able to use the dump.py program to print out the indexes. If the indexes are working to my understanding of the file format, you should see something like

$ python dump.py schematic.SchDoc
Header: |HEADER=b'Protel for Windows - Schematic Capture Binary File Version 5.0'|[. . .]
0: [. . .]|RECORD=b'31'|[. . .]
. . .
37: [. . .]|RECORD=15|INDEXINSHEET=1|[. . .]
38: [. . .]|RECORD=16|OWNERINDEX=37|[. . .]
39: [. . .]|RECORD=16|OWNERINDEX=37|[. . .]
40: [. . .]|RECORD=16|OWNERINDEX=37|[. . .]

Closing this as requested, but I am happy for a new pull request or reopening this one, whichever you prefer.

grypho commented 7 years ago

Martin,

Thanks for your explanation. I thought, there was a relation between OWNERINDEX and INDEXINSHEET but if you just count the records as your dump.py does, the OWNERINDEX makes sense again.

I'll change my code to use that relation.

Carsten

Am 2017-02-24 01:20, schrieb Martin Panter:

About "objects.properties" versus "last_sheet_symbol", I was assuming that you could rely on OWNERINDEX working. So if the index isn't working, ignore that suggestion.

But I am skeptical. The indexes that OWNERINDEX refers to are implicit. I think INDEXINSHEET is irrelevant for the parent-child relationship. (Perhaps it is related to deciding which objects are drawn over the top of other objects; I dunno.)

You may be able to use the dump.py program to print out the indexes. If the indexes are working to my understanding of the file format, you should see something like

$ python dump.py schematic.SchDoc Header: |HEADER=b'Protel for Windows - Schematic Capture Binary File Version 5.0'|[. . .] 0: [. . .]|RECORD=b'31'|[. . .] . . . 37: [. . .]|RECORD=15|INDEXINSHEET=1|[. . .] 38: [. . .]|RECORD=16|OWNERINDEX=37|[. . .] 39: [. . .]|RECORD=16|OWNERINDEX=37|[. . .] 40: [. . .]|RECORD=16|OWNERINDEX=37|[. . .]

Closing this as requested, but I am happy for a new pull request or reopening this one, whichever you prefer.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

*

Links:

[1] https://github.com/vadmium/python-altium/pull/5#issuecomment-282165098 [2] https://github.com/notifications/unsubscribe-auth/AI4gSHVqpedxWpbx9gkOTsAaGTR_0-HKks5rfiJMgaJpZM4MJrTZ

vadmium / python-altium

Drawing of sheet entries #5

Thanks for you work. I have a few questions, the major one being about an inconsistency with the _FRAC1 units.

Sheet entry

Links: