| ID: | 3678 |
| From: | ge...@igor2.repo.hu |
| Date: | Tue, 14 Jan 2020 04:45:23 +0100 (CET) |
| Subject: | Re: [pcb-rnd] Bug report: editing padstacks of flipped through-hole |
| in-reply-to: | 3677 from Gabriel Paubert <pa...@iram.es> |
| replies: | 3924 from ge...@igor2.repo.hu |
On Mon, 13 Jan 2020, Gabriel Paubert wrote: > Hi, > >load the attached file and: >- right click on the circular pad and select edit geometry/prototype >- click on the prototype tab >- change for example the top mask >- increase it by say, 0.1mm >- close the the change dialog >- instead of the top mask, it is the bottom mask that has been changed! > >I've seen the same kind of side flip for copper, I've not tried the paste >layer, so I can't tell for sure but it seems likely. > >If, instead of using shrink/grow, you try "derive automatically", the >bottom mask simply disappears and a red line appears in the message >window. > >Note that the editor works fine for SMD padstacks, independently of the >side of the component. > Thanks; it seems like a GUI dialog bug (the data model is not affected, files are not affected). The dialog gets a bit confused about the s-mirror field (you can see that field in the first tab). S-mirror is the side-mirror. Padstacks work like this: we store the padstack prototype once, in neutral transformation. In case of an smd pad, that normally means it has copper shape on the top copper. Then if you flip the part to the other side, the prototype does not really change, it still says copper shape is on the top copper, but the s-mirror field is set to 1, which means "mirror the stack". So at the end, we save the file with top copper shape, it has top coppershape in the memory, and it is only the dialog box that gets confused and for some reason shows it as bottom copper. (Note: this is a common approach, other EDA tools' data model do this too, although with less generic mechanisms. The usual approach is defining the footprint's top side, then if you place the footprint on the other side of the board, it's all upside down - but the footprint itself, internally, still refers to its own top side as top side, even tho it is now the bottom of the board. Our s-mirror for padstacks is really the same thing.) So at the end, the prototype edit dialog will need to show the reality, what's in our data, that is: "top copper" for the smd pad, and if you change top mask of a thru-hole part placed on the bottom of the board, it will really affect the bottom mask of the board (which is the top mask of the part and top mask of the padstack). This is something the user can not avoid to understand with padstacks^1. So there are two bugs: 1. the dialog gets confused about s-mirror and swaps the display sometimes, and addresses the the wrong layer other times^2 2. there should be some indication about the side mirror on the second tab (but only if there's a first tab, i.e. when you are editing a prototype from a real padstack instance; if you edit prototypes from the prototype list, there's no padstack instance and then there's no s-mirror either) However, I do not consider this a critical bug: this must have been in the code for a year or more, unreported, which is a good evidence that it's not something users bump into too often. So it can wait until after the release. Took a note in the TODO. Footnotes: ^1: in these two simple cases, it looks like a good idea to show board layers instead of true padstack layers. There are two reasons why we shouldn't do that: - first, not showing the reality of our data will only make the UI more confusing especially once the user looks into the files or needs to understand what some operations do - second, in a more complex case you will have the same padstack prototype placed on both sides; for example in a card edge connector you have one prototype and half of the padstack instances will be s-mirrored. Which means if you change the top copper shape of the prototype, it will affect all padstacks in your connector, with half of them changing shape on the bottom copper of the board, other half changing shape on the top copper of the board. So our data and this dialog must be in padstack's "relative" layer addressing and can not show how this maps to board layers, because you are really editing the looks of more than one padstacks when you are editing a prototype. ^2: edit your round padstack proto; increase the top copper shape by 10 mil; it will increase the copper shape that ended up on the bottom copper of the board (which is good, because 'top' in the dialog context shall mean 'top' in the padstack prototype context, not in your board's context) - but then look at the table, your change is displayed for the bottom copper! So you click and edit one row of the table and it is then displayed in another -> s-mirror somehow inverted the order of table rows. Best regards, Igor2
Reply subtree:
3678 Re: [pcb-rnd] Bug report: editing padstacks of flipped through-hole from ge...@igor2.repo.hu
3924 Re: [pcb-rnd] Bug report: editing padstacks of flipped through-hole from ge...@igor2.repo.hu
3930 Re: [pcb-rnd] Bug report: editing padstacks of flipped through-hole from Gabriel Paubert <pa...@iram.es>