That would be more powerful, but need database changes and is more editing/create work.
My suggestion to use the already there Anchor Pad XYD uses existing database ok, and the movement of the anchor pad gives some control over the spokes (it becomes spoke origin)
Spokes to a quite small pad seem to be ok, which gives more choice in placing anchor pad, to remain still inside the custom shape.
Version 5 will definitely not get this feature added. (It would be a new feature. New features are never added with bugfix releases)
As we are discussing how this might be done in v6 we can also consider solutions that require file format changes if they give us a more general solution. (This is at least my take on such things.)
I hope enhancement priority above total change to the point 5.x version force the be throw away.
I have no idea what you want to tell us here.
Are you worried that any update to v5 will update the file format? I can assure you that this will not happen. (The earliest something like this can be added is with version 6 which is still at least two years away.) And this is with or without changes to the file format. (No new features will be included in bugfix updates.)
I agree, lines are more flexible, but they also come with downsides…
They need more user time to create them, and then what to do about display.
They should clearly show in the editor, but what about on the board ?
They are not actual thermals yet, merely suggested axes, so users probably prefer to not see them ?
Or maybe they toggle, so when thermals are visible, the suggestions vanish & vice versa ?
If you create a line, you now must support ‘any angle’ thermals.
An expectation would be Line width is going to be thermal width, but users have menu-control now, over thermal spokes. Maybe that needs another menu choice - GUI or Footprint spoke widths ?
Most users are like my example - they just want some thermals created, like other CAD pgms can do.
Anchor Pad thermals should have minimal code impact, as thermal-to-pad already works fine.
ie to me, it needs some decision cleanups, not completely new algorithms.
Anything that can avoid a database change, is easier to get done 
My idea would have been to use the lines only for pads where the automatic way you suggest does not give nice results.
Thermal spoke with is controlled by the zone settings. No need to use the line width here. I would see these lines more like construction lines (or axis)
On the board one would see the thermals as they are generated. No need to show these axis. But maybe they can be useful anyways so a way to show them might be an idea.
Not always. If you hack on too many things without wanting to change the file format then you might end up with a hack like having invisible power pins double as global labels.
As stated above: I think most cases where thermals are easily added will be covered by chamfered pads. Leaving extremely complex pad shapes for polygon pads. I doubt the devs would be conferrable to ship an algorithm which will break easily.
So they either need to invest a considerable amount of time into an algorithm which can handle nearly every conceivable polygon, or they give the user a way to correct the behavior of a much simpler algorithm. (My suggestion would be to go towards the later. But maybe there is a simple algorithm which covers 90% of all remaining pad shapes then this might be a different story.)
That still leaves a blind-spot, of all those 5.x designs using custom pads, that will not fix even when V6 arrives, without a redesign of library parts.
The whole point of the Anchor Pad approach, it is avoids the need for “invest a considerable amount of time into an algorithm”, by leveraging what already works. No new algorithms are needed.
It just needs way to overcome the decision of
IF CustomPAD then kill_all_thermals
which is what we have now, to instead be
IF CustomPAD then UseAnchorPadThermal
Mostly, it is removal of an 'off’switch.
@PCB_Wiz: I think I more agree with you on this. And if the decision go to @Rene_Poschl way, I would highly avoid using custom pads it seem not worthy to bring in another trouble for the board design work flow.
And what i had learn here, it is enough for me to not event think about using the custom pad. It just going to be hard for others designer like me to realize this issue when using thermal pad on custom pad only until at the final state of the board design (Zone filling).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.