* A pattern when brought into a component library MUST have a "Pad 0" which is disabled, and SOMETIMES must have a "Pad N" (where N is one more than the last pad) which is also disabled, otherwise you will get no pads, or no last pad when it's in the component. )" in a pattern library becomes "(Point.)" in a component library. * We know that components include the pattern, but it's not a direct incorporation, there are some subtle differences, namely in a pattern library each "(Pattern.)" has a "(Value.)" but this does not get brought into the component's Pattern, and more curiously, the "(Points. (Number 1)" except when it's not and you wind up with "(Pad 37 "1". Pad numbers in patterns are similarly afflicted, they for example Pad 1 is "(Pad 1 "1". * Numbering of pads/pins/shapes is all over the show, there's lots of confusing duplication, for example, a component pin has an ID number of some sort (the first number in it's attributes), then sub elements called "Name" which is a number, "StringNumber" which is a number and "Number" which is a number, ideally these are the same number, except when they are not because changing pin numbering in the GUI doesn't necessarily do what you would expect with these numbers.
The first one should be about 81mm long, the second one about 5mm long, but the elements are virtually identical :-/Ĭomponent shapes are somewhat easier to figure out, they appear based around the center point of the bounding box, still very awkward to have to use negative coordinates but at least it makes sense.
Here is a rectangle surrounding a 2x1 in a pattern Here is a rectangle surrounding a 2x31 in a pattern * Positioning of pads/pins/shapes is very confusing, I could never work out what was going on with shape position/dimension in the pattern exports. * Units in most things appear to be in "thirds of a millimeter", if a unit is written as "3" then it means 1 mm * The library export has an extra closing parenthesis, if the export contains 123 opening parenthesis, it has 124 closing ones, the import doesn't care if you omit the extra * The attributes to an element are not named, they are just a space separated list of things, some quoted, some not * Line ending is important, only and always Or it could be when there are no attributes and no child elements. I suspect that these cases are when child elements are possible, but not required. You would imagine that if an element had no arguments and no child elements, that it could be written "(Element )", but no, the ")" must be on it's own line in those cases - so whitespace is sometimes important. It really wouldn't take that much work to accomplish, you could even do it just as an official converter to/from asc, the only thing that is needed to do that is a better knowledge of what each attribute on an element means, and preferably remapping the coordinates system.Īnyway, here are some notes which might help others also trying to generate libraries programatically. Points in pattern patterns ), and a more sane and consistent coordinates system.
I would like to suggest that in future DipTrace move towards an XML format for the library import/export, with proper named attributes, more consistent structure ( Point in component patterns vs. In the end I actually went so far as to write a bare-bones XML conversion to/from asc format so that I could manipulate a little bit easier, but still a lot of guesswork. asc format for Patterns and Components to at least partially generate some sets of custom header patterns in a range of sizes. So for the last while I have been working with the.
0 kommentar(er)
