Re: [Kicad-developers] Arc Adjustment proposal

Don't get me wrong... I don't say KiCad has not to be improved. I just say that complex mechanical objects have to be designed and checked in a mechanical environment. And that is exactly what we have done with the KiCAd libraries... Most of footprints are designed using scripts and are

Re: [Kicad-developers] Arc Adjustment proposal

I strongly disagree with this mindset. It feels like saying that because KiCad is currently bad at something, it should always be bad at something and users should just use a different tool because KiCad will never be good at it. If we have the developer interest to make KiCad good at drawing

Re: [Kicad-developers] Arc Adjustment proposal

On 11/07/19 18:16, easyw wrote: On 07/11/2019 5:17 PM, Jeff Young wrote: Here’s a footprint I drew recently which was made much harder by Kicad’s focus on arc centre points: This is exactly an example that should be done in a mechanical CAD and imported later in KiCAD (i.e. as DXF).

Re: [Kicad-developers] Arc Adjustment proposal

If you’re going to do everything in DXF, why have drawing tools at all? (And by corollary, if you’re going to have drawing tools then make them suitable for the task at hand.) Cheers, Jeff. > On 11 Jul 2019, at 17:16, easyw wrote: > > > On 07/11/2019 5:17 PM, Jeff Young wrote: >> Here’s a

Re: [Kicad-developers] Arc Adjustment proposal

On 07/11/2019 5:17 PM, Jeff Young wrote: Here’s a footprint I drew recently which was made much harder by Kicad’s focus on arc centre points: This is exactly an example that should be done in a mechanical CAD and imported later in KiCAD (i.e. as DXF). Complex mechanical object should be

Re: [Kicad-developers] Arc Adjustment proposal

Here’s a footprint I drew recently which was made much harder by Kicad’s focus on arc centre points: > On 11 Jul 2019, at 15:46, Eeli Kaikkonen wrote: > > > > to 11. heinäk. 2019 klo 15.43 easyw (ea...@katamail.com > ) kirjoitti: > > On 07/11/2019 1:21 PM,

Re: [Kicad-developers] Arc Adjustment proposal

to 11. heinäk. 2019 klo 15.43 easyw (ea...@katamail.com) kirjoitti: > > On 07/11/2019 1:21 PM, Dino Ghilardi wrote: > > On 11/07/19 12:26, easyw wrote: > > then your fashion design should use a proper CAD to design the board, > > and the EDGE should then imported inside KiCAD i.e. from a svg or a

Re: [Kicad-developers] Arc Adjustment proposal

On 11/07/19 14:42, easyw wrote:> > On 07/11/2019 1:21 PM, Dino Ghilardi wrote: >> On 11/07/19 12:26, easyw wrote: >> then your fashion design should use a proper CAD to design the board, >> and the EDGE should then imported inside KiCAD i.e. from a svg or a >> dxf file or handled directly with

Re: [Kicad-developers] Arc Adjustment proposal

Hi Tom- On 2019-07-11 08:52, Tomasz Wlostowski wrote: As I've been working on the Constraint Solver for a while, I'd like to add my 5 cents too. The solver allows to define arcs in different ways: - center/angles/radius - start/end point (tangential to adjacent lines/arcs) The input parameters

Re: [Kicad-developers] Arc Adjustment proposal

On 10/07/2019 19:25, Seth Hillbrand wrote: > > Proposed solution: I would like to adjust the pcbnew file format and > internal SHAPE_ARC, DRAWSEGMENT arc and EDGE_MODULE arc to use a single > format consisting of start point, mid point and end point.  Mid point > here is defined as the point

Re: [Kicad-developers] Arc Adjustment proposal

On 07/11/2019 1:21 PM, Dino Ghilardi wrote: On 11/07/19 12:26, easyw wrote: then your fashion design should use a proper CAD to design the board, and the EDGE should then imported inside KiCAD i.e. from a svg or a dxf file or handled directly with FreeCAD. Yes, he should... but he won't:

Re: [Kicad-developers] Arc Adjustment proposal

On 11/07/19 12:26, easyw wrote: On 07/11/2019 12:05 PM, Dino Ghilardi wrote: My two cents... Unfortunatly some times the centers are anchors of the board, other times they are not: when the external case is designed by a "fashon designer" and you have to put your electronics inside, the

Re: [Kicad-developers] Arc Adjustment proposal

On 07/11/2019 12:05 PM, Dino Ghilardi wrote: My two cents... Unfortunatly some times the centers are anchors of the board, other times they are not: when the external case is designed by a "fashon designer" and you have to put your electronics inside, the board outlines can be quite weird,

Re: [Kicad-developers] Arc Adjustment proposal

On 07/10/2019 10:52 PM, Eeli Kaikkonen wrote:> For what it's worth, in normal graphical arcs (especially in edge cuts) the two endpoints (or start and end) are usually important, the centerpoint isn't. This is not true. Generally for mechanical concerns, you should start exactly from the

Re: [Kicad-developers] Arc Adjustment proposal

On 07/10/2019 9:02 PM, Wayne Stambaugh wrote: Don't forget, this will impact all import from and export to 3rd party file formats so it's not going to be a trivial change. Wayne Then it could be introduced an extra way to define arcs only for tracks, leaving the previous definition unaltered

Re: [Kicad-developers] Arc Adjustment proposal

Why not use start end, "bulge" as DXFs do for LWPOLYLINEs? http://www.lee-mac.com/bulgeconversion.html Instead of the bulge number (which is related to the included angle of the triangle formed between the endpoints and the center) you could also write out the angle of the arc directly. This is a

Re: [Kicad-developers] Arc Adjustment proposal

Hi Eeli, Have you tried the new arc editing in the Symbol Editor? I think it’s much easier to use, and I think that’s the direction Seth is going for Pcbnew/FootprintEditor. Cheers, Jeff. > On 10 Jul 2019, at 21:52, Eeli Kaikkonen wrote: > > ke 10. heinäk. 2019 klo 20.26 Seth Hillbrand

Re: [Kicad-developers] Arc Adjustment proposal

ke 10. heinäk. 2019 klo 20.26 Seth Hillbrand (s...@hillbrand.org) kirjoitti: > Problem: Arcs are stored in the pcbnew file using center, start point > and arc angle. This leaves the end point of the arc subject to rounding > errors. > For what it's worth, in normal graphical arcs (especially in

Re: [Kicad-developers] Arc Adjustment proposal

On 2019-07-10 15:02, Wayne Stambaugh wrote: Are you planning on allowing either direct or fixing it to a single direction? I would think the latter would be preferable. I'm not currently planning on using the center point method unless someone has a good solution to the invalid arc issue.

Re: [Kicad-developers] Arc Adjustment proposal

Seth, On 7/10/19 2:20 PM, Seth Hillbrand wrote: > On 2019-07-10 14:08, Brian wrote: >> On 7/10/19 2:02 PM, Seth Hillbrand wrote: >>> Start-center-end is under constrained and requires the additional >>> knowledge of which direction the arc is going. >> >> On the contrary.  Start-center-end is

Re: [Kicad-developers] Arc Adjustment proposal

On 2019-07-10 2:35 p.m., Brian wrote: I'm not sure I'm convinced that start-mid-end is any more or less immune to invalidity than start-center-end. Instead of start-center-end what about center-start-angle where angle is a positive or negative angle to indicate CW or CCW? -- Cheers! Kevin.

Re: [Kicad-developers] Arc Adjustment proposal

On 7/10/19 2:20 PM, Seth Hillbrand wrote: On 2019-07-10 14:08, Brian wrote: On 7/10/19 2:02 PM, Seth Hillbrand wrote: Start-center-end is under constrained and requires the additional knowledge of which direction the arc is going. On the contrary.  Start-center-end is fully constrained. 

Re: [Kicad-developers] Arc Adjustment proposal

On 2019-07-10 14:08, Brian wrote: On 7/10/19 2:02 PM, Seth Hillbrand wrote: Start-center-end is under constrained and requires the additional knowledge of which direction the arc is going. On the contrary.  Start-center-end is fully constrained.  Arc direction is implied and unambiguous. Ah

Re: [Kicad-developers] Arc Adjustment proposal

On 7/10/19 2:02 PM, Seth Hillbrand wrote: Start-center-end is under constrained and requires the additional knowledge of which direction the arc is going. On the contrary.  Start-center-end is fully constrained.  Arc direction is implied and unambiguous.

Re: [Kicad-developers] Arc Adjustment proposal

Hi Jon- Welcome back! Start-center-end is under constrained and requires the additional knowledge of which direction the arc is going. The center point in my proposal will still be user-adjustable and snappable, just not stored in the file where we write floating points values instead of

Re: [Kicad-developers] Arc Adjustment proposal

+1 to start, end and +0 to whatever ... is. > On 10 Jul 2019, at 18:37, Larry Doolittle wrote: > > Jon - > > On Wed, Jul 10, 2019 at 01:29:11PM -0400, Jon Evans wrote: >> I am curious why start-midpoint-end is better than start-center-end, though. >> I think the latter is used more often

Re: [Kicad-developers] Arc Adjustment proposal

Jon - On Wed, Jul 10, 2019 at 01:29:11PM -0400, Jon Evans wrote: > I am curious why start-midpoint-end is better than start-center-end, though. > I think the latter is used more often in mcad tools, although I could be > wrong. start-center-end is mathematically over-constrained, so it sounds

Re: [Kicad-developers] Arc Adjustment proposal

(back on the internet, slowly reading more emails) I agree that the storage method should be changed. Thanks for taking this on, Seth. I am curious why start-midpoint-end is better than start-center-end, though. I think the latter is used more often in mcad tools, although I could be wrong.