Altium slow and funny behaviour with polygons - Page 1
Forum section: electronics / general

author: dmg
author_rank: Regular Contributor
timestamp: January 18, 2016, 10:44:32 pm
content: Hi,I'm not new to Altium, I've already done several relatively complex layouts with it and I'm fairly happy, it's a pretty efficient package. However, there's always this time when I'm about to finish routing and start reviewing the job so I pour all polygons and do a DRC and such things and almost always Altium screws things up with polygons.It either:-Gets slow as hell to generate and pour them (about 2-3 minutes on a core i7)-Doesn't abide by the pouring order and pours whatever polygon it wants first, normally screwing things up-A combination of bothNormally this happens when I have local polygons surrounded by a large ground polygon or similar things.I'm on Altium 14. Does anyone experience the same issues? It's an efficiency killer in the last stages of design... I usually have to pour polygons manually...

author: dmg
author_rank: Regular Contributor
timestamp: January 19, 2016, 12:57:28 am
content: Quote from: blueskull on January 19, 2016, 12:21:47 amI'm talking about 6-8 layer designs with relatively complex geometry. The problem is that all this slowness starts at some point, and I can make it much much faster by just cutting and repasting all polygons. Then, they'll pour fine 3-5 times and after that slowness and random pouring again. It's damn frustrating sometimes... thankfully it only affects me during the very final stages and in very specific points, so not so much time lost there...

author: dmg
author_rank: Regular Contributor
timestamp: January 19, 2016, 01:22:34 am
content: Quote from: blueskull on January 19, 2016, 01:05:15 amI've searched and seems like I'm the only one out there with this problem (or I can't express my problem well enough for google to understand), so I'm thinking this might be my fault, maybe I'm doing something I shouldn't...Apart from that, I've found quite some bugs in Altium, I know of about 6 ways to crash it if I want, and I've experienced funny random behaviours but they are sporadic enough not to cause any trouble, about 90% of the time things are fluent and I can work pretty well. I love many things in altium. But well, for some reason I'm a bug magnet and prone to breaking software... last time some friends launched an Android app to the wild after quite extensive testing and I learned how to crash it on demand in about 5 minutes and in less than 10 I found a convoluted bug that allowed you to spam other app uses with notifications and even crash their phones, and that without even trying...I should get my altium updated soon and should stay up to date from there, so I'll be able to report bugs.

author: DerekG
author_rank: Frequent Contributor
timestamp: January 19, 2016, 01:42:38 am
content: Quote from: dmg on January 19, 2016, 12:57:28 amYou are running low on RAM. Altium allows for multiple undo/redo & it stores all of these changes in RAM.Adjust the number of undo/redo held in memory or do a save & close Altium to flush the memory.

author: dmg
author_rank: Regular Contributor
timestamp: January 19, 2016, 02:12:43 am
content: Quote from: DerekG on January 19, 2016, 01:42:38 amWhen you think 16 GB of RAM would be enough... darn it, thank you very much.Hopefully that also explains why at some point it stops following the pouring order and pours in whatever order it feels like, usually the worst possible one.

author: free_electron
author_rank: Super Contributor
timestamp: January 19, 2016, 02:13:43 am
content: 15 and 16 have massive speed improvements on polygon pours.Polygon order is set in the polygon manager.If your machine is slow you have either memory or graphics problems.shelve the polygons while working. Then unshelve. Do a flash repour using T-G-V ( make sure your design rules are set up right. way too many people write very bad design rules grinding the software to a halt.

author: free_electron
author_rank: Super Contributor
timestamp: January 19, 2016, 02:16:26 am
content: Quote from: dmg on January 19, 2016, 02:12:43 am

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 19, 2016, 06:13:18 am
content: Pour order:T, G, M (Polygon Manager).Polygons are poured in the order you place them, first most recently. So if the last thing you did was place a huge ground poly, say goodbye to everything else when you repour, until you sort things out there!Polygons do take quite some time to crank on complex boards, but I don't spend even 10 seconds repouring all on a complex (600 components, 4 layer board, ~40 polys?) design.Tim

author: Psi
author_rank: Super Contributor
timestamp: January 19, 2016, 06:20:32 am
content: Quote from: free_electron on January 19, 2016, 02:13:43 amYeah, i noticed that.I'm using Altium 10 at home and it takes maybe 2 seconds for one plane.Compare that to Altium 16 at work where it takes under a second to repour all polygons at once on a small 4 layer board.

author: dmg
author_rank: Regular Contributor
timestamp: January 19, 2016, 11:17:57 am
content: Quote from: T3sl4co1l on January 19, 2016, 06:13:18 amMy current board is 1500 components, 8 layers and about 40 polys too. When things are fresh polys get poured in less than 10 seconds. My problem is that peroformance starts degrading until it gets unusable. Then I cut all polygons, paste them with "keep net name", repour and everything is fine again.I do use the polygon manager and set the order I want. It pours the polygons and everything's fine, they pour as they should... but when things start getting slow it also starts pouring them the way it wants. If I set some poly to pour the last it sometimes pours it first, or in whatever order it wants, messing it all. Again, cut, paste, repour, all fine.Quote from: free_electron on January 19, 2016, 02:13:43 amThat's how I work, all polys shelved till last stages, that's why it affects me during those stages and not during normal routing which is fine and fast, even with online DRC on and such. Do you have any tutorial on how to setup proper rules? I normally work with netclasses and diff pair classes in a superclass-subclass way (i.e. a class for 100 ohm pairs and and within that class PCIE pairs, LVDS and such) and then setup rules from general to specific.The PC has a fairly recent dedicated nVidia graphics card (a GT 800 something) and a 4th generation core i5 (not i7 sorry). Will check specs.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 19, 2016, 03:23:37 pm
content: Yeah, sounds like a bug then. Call 'em and see if they have anything to say about it.Tim