This is a practical step by step instruction on how to screw up days of board layout with a couple easy to follow steps:
Spend days (preferably weeks) on your board layout in the canvas that actually works (i.e. default)
Switch to OpenGL mode and try to create an array from your board using “Create Array” feature in that canvas
After verifying that the feature is completely useless hit undo and go back to the mode that can actually be used for board design
Save your work - and you are done!!!
For those of you who didn’t notice how the magic is done, I will reveal the secret! When you use the array feature it replaces your normal footprint references with some bogus ones, and when you hit “Undo” it doesn’t bother to change them back. Naturally in a busy board with filled zones you will never notice that, unless you actually switch to the silkscreen layer and turn the contrast mode on. So when you save you design all the references between your components and the net file will be broken. If you try to update your design from the net file it will either ignore all the existing footprints or delete them (if you choose to delete extra footprints) and then pile up the new footprints off to the side of your board. Short of going and manually renaming every single footprint reference in your board there is nothing you can do. Special thanks going to the developer of this amazing feature. Try it so your board can look like this too:
Would netlist forward-annotation based on timestamps (instead of RefDes) be useful to resynchronize layout with schematic? Just a workaround if it does, @ArtG should definitely file a bug.
OpenGL mode in short is an alternate graphical canvas in KiCad 4.0.x Pcbnew where hardware acceleration is used.
This mode speed-up drawing the PCB content and have some features that normal mode does not have. At the moment there are three superb features available in OpenGL mode only: push and shove router (not autorouter), differential pair router and track length tuner.
If your machine has compatible graphics adapter you can switch to OpenGL mode with F11 key. To back to normal mode use F9.
It shouldn’t. Trust me you better off not knowing. Save you some aggravation.
Not exactly. It is a fully independently developed package mascaraing as a graphical canvas. Push and shove ain’t worth it comparing to everything else they got wrong.
+1 on the reference to the superb features available in OpenGL - Push and shove router, differential pair router and track length tuner. I’m not building anything nearly sophisticated enough to require the differential pair router or track length tuners but seeing them demonstrated made me look forward to the day I might use those features. The Push and Shove Router is, by itself, worth my weight in gold (which is CONSIDERABLE).
Well, if you don’t file a bug report the developers won’t know there’s a bug. This is a pretty nasty one so you should file a report. It’s not the first bug found that can really mess up your work; I was bitten by a nasty ratsnest bug but that was fixed within a few days of me reporting it.
I have to admit that I have only dabbled with Kicad and have at least temporarily given up on Git for revision control. But what I do do is to frequently copy my (folder with all of the important files) into an individually dated zip folder so accomplish a backup that way. I am an engineer and normally save multiple dated file versions when I work on anything which is a major effort. The last I was doing anything with Kicad I thought I had stitched some vias and had no problem but that was using version 3.XX last summer. Please let us know if this bug gets fixed in an update. Does this mean that 4.0.1 is not so stable? Will it fall over?
There are always bugs in the code, ‘stable’ just means, they took care of the worst of them (that have been found), didn’t add new broken experimental features to the code of that release so the software doesn’t crap itself when you move the mouse right out of the gable.
In @ArtG’s case there, he’s using a function in the (currently) still developmental OpenGL canvas (*) that is originally from the footprint editor to create repeated arrangements of pads for devices.
The implementation in PCBnew lacks adaption and probably some proper bughunting/testing, thus you get the outcome that @ArtG describes (an unsuspecting user finds this function and runs with it).
*) there is a history to this as ArtG has stumbled upon problems with the Array function before. Can’t find the link after 5mins, so gave up searching. Maybe Art will post it…
The whole story boils down to that the developers of KiCAD will replace the currently working default canvas with the OpenGL canvas (hopefully only after they got the bugs out), as it’s snappier and less coding/maintenance (afaik) and some of the people who worked with KiCAD for a while have (valid) doubts that once this happens the workflows and features they are used to from the default canvas will still work.
Personally I still work in default canvas and don’t really like the OpenGL canvas for usability/workflow reasons, but that’s just me.
For this to happen (unless a dev stumbles upon this himself) one needs to post a bug report + reproducable steps how to get the bug onto the bugtracker for KiCAD:
So, how about it? Will you create one and link back here so the rest of us can chime in and add our vote to the bug if needed?
If you don’t do it and Art doesn’t do it, the devs will probably never know about it and I have to hug more strange people on the internet as a result.
I think everybody I have ever known, who does PCB layout work, follows a similar procedure individually. When the effort gets formally committed to “Revision” status (typically by submitting an official ECO, or sending the board out for procurement, you delete all but one or two of those backup copies.
I think you may be referring to this post
The short of it is that until recently there was only one way to create panelized array of PCBs for manufacturing in KiCad, which is to use Append Board functionality, select grid size slightly bigger than the board and then copy and place all them manually. This approach relies on being able to set large grid size (larger than your individual panels) Jean-Pierre Charras (who happens to be the father of KiCad) decided that an average KiCad user can not be trusted with such freedom and locked the maximum grid size to 50mm. In our discussions he suggested that a better way to create an array would be to use this “Create Array” feature in Open GL canvas.
Which is kind of sad that developers would not be following this forum closely . Yeah, yeah , I know - they are too busy developing, but this forum is not that big so you can’t spare five minutes of your time to browse new posts. In my opinion this showcases the real problem with resent KiCad development. A bunch of guys got together and put something together that they thought looked cool but turned inside out the whole proven work flow of the “old” KiCad. Neither are they willing to listen to any suggestions. When you try to point out the problems with the new “canvas” they either ignore you or say that it is the way it is and it can’t be changed. I think I digress…
Upon further reflection I don’t think version control would be of much help here either. After I did that little magic trick with the array I continued to work with the board making some significant changes in the layout. Lets say I was committing all those changes along the way. To restore all the links for the footprints I would still have to go all the way back to when the board got messed up thus voiding all the changes I made after. At this point manually renaming every single component may be a better option. I’m not advocating against using version control. It is definitely a good practice. I’m just saying that in this case it would have limited usefulness.
Well thank you for this marvelous insight! How didn’t I think about that?
Didn’t I say that you couldn’t really see that it got screwed up UNLESS you switch to the silk screen layer and high contrast mode? I thought I said that. Had I seen that it got screwed up I wouldn’t have saved it in the first place. No need for version control.
Regardless if you commit or don’t commit, you still have to go all the way back in this case, to the point when it got corrupted .
Well, the bug is filed, if anyone wants to test it and add their comments in the bugtracker - you’re welcome to do so. Otherwise this thread will become another “why they’ve done it that way!?” vs “fork it if you don’t like it”
I have faced this bug before in the daily build version post v4.0 which my intention was to make a production panel of the design. But, I’m lucky because I always make a separate file for panel just for clarity purposes during manufacturing submission. A working prototype which are usually in single pieces could be 100% identical to that of a production version (although it is in a panel).
Back to the bug, until today I’m not really sure whether this “create array function” is really for panelizing because it sure looks like it but not behaving properly like one especially on the designator assignment across the whole panel. For me, it sure looks like an unfinished feature (not polished or half way done) on the software.
