Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

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 checked using a 
mechanical sw.


I agree that a new user should find a decent drawing editor, but when 
he/she gets experienced, the right direction is toward a MCAD/ECAD 
collaboration.


All commercial ECADs do it already, even with the entry level products.
So mechanical collaboration should be strongly suggested IMO.

Maurice


On 07/11/2019 6:51 PM, Jon Evans wrote:

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 things, why
not do so?
It doesn't help that the available FOSS MCAD tools are (in my opinion) much
less capable relative to their commercial competitors than KiCad is
relative to commercial ECAD tools.

-Jon

On Thu, Jul 11, 2019 at 12:16 PM 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).

Complex mechanical object should be addressed with mechanical CAD, not
ECAD.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jon Evans]

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 things, why
not do so?
It doesn't help that the available FOSS MCAD tools are (in my opinion) much
less capable relative to their commercial competitors than KiCad is
relative to commercial ECAD tools.

-Jon

On Thu, Jul 11, 2019 at 12:16 PM 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).
>
> Complex mechanical object should be addressed with mechanical CAD, not
> ECAD.
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Dino Ghilardi]

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).


Complex mechanical object should be addressed with mechanical CAD, not 
ECAD.




I agree, but that implies that the gui who uses kicad for electronics 
also needs to have (and learn) a mechanical cad and this is not always 
true (the world is full of different people with different backgrounds).


If you are starting using kicad and you never used a mechanical cad the 
time you need to learn it will be more than the time needed to struggle 
with the limited 2D-lines/arcs capabilities of kicad.


Also the fact that there is not a dxf export in footprint editor does 
not help going back and forth between the two cads.


Of course, as you say, an experienced user, with knowledge of both 
electronic and mechanic (2D and 3D) cads will use the right tool for the 
right work and do it efficiently, but a new user (or a student) that 
starts from the electronic cad would just say "I was not able to do it, 
the tool is too limited, no good cad" and leave kicad.


Cheers,
Dino.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jeff Young]

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 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 addressed with mechanical CAD, not ECAD.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

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 addressed with mechanical CAD, not ECAD.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jeff Young]

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, 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: (he's not under my control).
> 
> I don't get your user case...
> 
> I realized even before you (easyw) wrote that I was partly wrong about the 
> relative importance of different features of arc. But I have lately been 
> exposed to a workflow quite similar to what Dino told about. And he's exactly 
> right - "should do" and "do" are two different things. In small companies 
> fighting for their life you don't have the luxury of having dedicated 
> "fashion designer" and people use what they can and do what they can. I won't 
> go into details here to save myself and some other people from embarrassment; 
> for example I won't mention STL as intermediate format.
> 
> I don't blame KiCad at all for not supporting suboptimal design workflows but 
> it would be good if it would support all use cases. This is of course only 
> tangential for the discussion about the file format, but maybe it can at 
> least give something "FYI" to the developers. What Tom said is very 
> interesting. The new UI and backend may make current feature wishes 
> fullfilled or unnecessary.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Eeli Kaikkonen]

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
> > dxf file or handled directly with FreeCAD.
> >
> > Yes, he should... but he won't: (he's not under my control).
>
> I don't get your user case...
>

I realized even before you (easyw) wrote that I was partly wrong about the
relative importance of different features of arc. But I have lately been
exposed to a workflow quite similar to what Dino told about. And he's
exactly right - "should do" and "do" are two different things. In small
companies fighting for their life you don't have the luxury of having
dedicated "fashion designer" and people use what they can and do what they
can. I won't go into details here to save myself and some other people from
embarrassment; for example I won't mention STL as intermediate format.

I don't blame KiCad at all for not supporting suboptimal design workflows
but it would be good if it would support all use cases. This is of course
only tangential for the discussion about the file format, but maybe it can
at least give something "FYI" to the developers. What Tom said is very
interesting. The new UI and backend may make current feature wishes
fullfilled or unnecessary.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Dino Ghilardi]

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 FreeCAD.
>>
>> Yes, he should... but he won't: (he's not under my control).
>
> I don't get your user case...
> are you receiving
> 1) a KiCAD pcb board from your fashion designer
> or
> 2) the enclosure for your board, coming from the fashion designer
> or
> 3) the outline of the pcb in external format
>
> The 1) is quite a weird case... your fashion designer should us
> mechanical sw to define the board outlines
>
> The 2) case is totally on your control...
> you need to use a mechanical sw to create pcb outline fitting your
> enclosure
>
> The same for the 3) case, you can fix the file before importing inside
> kicad.
>
> Please have a search for "ECAD MCAD Collaboration" for a deeper insight

I know there is a better or "correct" way do do anything, but in my 
opinion the question is not how a user gets to the trouble situation, or 
how to workaround it re-doing part of his work, but how the software 
helps to fix it when the problem is found: the easier is to get out of 
troubles, the better is the software (at least from the user's point of 
view). ...but now we are going a little bit off-topic.



now...back to the main topic:

Also I like the Tomasz point of view to store
"start/end/midpoint and the set of
CS arc input parameters which have been specified by the user"

It has the advantage that the stored parameters are just what the user 
wanted when the arc was created, also the arc-properties dialog could be 
modified in order to be able to enter center-start-angle or three-points 
arc (I'd like to have that).
Also probably makes the implementation of a "three-point-arc" tool 
easier, making easy to have the three points on grid.


Cheers, Dino.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Seth Hillbrand]

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 to the CS is some subset of the above. The outputs
are start/end/midpoint, which define the geometry of an arc for other
processes (plotting/drawing/etc.). In order to derive the arc from its
definition based radius/angles, I need that radius and angles to be
stored in the file too - for example calculating the radius back and
forth from endpoints/midpoint would accumulate rounding errors.

What would you say about storing the start/end/midpoint and the set of
CS arc input parameters which have been specified by the user?


I prefer to avoid extra parameters if we can as it makes editing by hand 
much harder.  But if we need them, I'm not opposed.  I'm not certain, 
however, how we keep the parameter relation under affine transformation 
as someone needs to drive the other.  It feels like we lose the relation 
during computation and not during storage.  What am I missing?


Best-
Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Tomasz Wlostowski]

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 along the arc that is at the half-angle of
> the full arc.
> 

Hi Seth,

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 to the CS is some subset of the above. The outputs
are start/end/midpoint, which define the geometry of an arc for other
processes (plotting/drawing/etc.). In order to derive the arc from its
definition based radius/angles, I need that radius and angles to be
stored in the file too - for example calculating the radius back and
forth from endpoints/midpoint would accumulate rounding errors.

What would you say about storing the start/end/midpoint and the set of
CS arc input parameters which have been specified by the user?

Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

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: (he's not under my control).


I don't get your user case...
are you receiving
1) a KiCAD pcb board from your fashion designer
or
2) the enclosure for your board, coming from the fashion designer
or
3) the outline of the pcb in external format

The 1) is quite a weird case... your fashion designer should us 
mechanical sw to define the board outlines


The 2) case is totally on your control...
you need to use a mechanical sw to create pcb outline fitting your enclosure

The same for the 3) case, you can fix the file before importing inside 
kicad.


Please have a search for "ECAD MCAD Collaboration" for a deeper insight

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Dino Ghilardi]

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 board 
outlines can be quite weird, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


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: (he's not under my control).



There is a Snap option in KiCAD to make an end of a segment snapping to 
a selected end point.

You can do this by holding the Alt key while moved an end point.




Works well with segments, but when snapping to join two arcs it works 
only when moving one of the ending points (the other does not change the 
radius), so it becomes a little bit tricky.


Cheers,
Dino.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

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, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


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.



Personnally I ran into the "endpoint" problem for some board edges, 
since to close the perimeter of the board for a step export, the arc 
start/endpoint need to be exact, while having an exact arc center was 
not so important (considering also the resolution used in kicad and the 
mechanical tolerances of the real word, an error of some nm in the 
center position should not be a problem).


There is a Snap option in KiCAD to make an end of a segment snapping to 
a selected end point.

You can do this by holding the Alt key while moved an end point.





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Dino Ghilardi]

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 centers, which are the anchors of your board.
If you start your design with mechanical constraints in mind, your board 
will not have EdgeCuts issues.




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, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


Personnally I ran into the "endpoint" problem for some board edges, 
since to close the perimeter of the board for a step export, the arc 
start/endpoint need to be exact, while having an exact arc center was 
not so important (considering also the resolution used in kicad and the 
mechanical tolerances of the real word, an error of some nm in the 
center position should not be a problem).


From a user point of view anything helps in having closed board 
outlines when using arbitrary arcs gets my +1 (no matter if this is a 
new internal arc data structure or a new "trim" tool to close two 
selected edges/arc).


Cheers, Dino.











___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

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 for drawings and edges.

The pcb format would be changed only if used Arc tracks in the board.

On 07/10/2019 7:25 PM, Seth Hillbrand wrote:> I'd like to adjust how our 
arcs are handled and stored.  This is part of
the arc tracks work package but is sufficiently tangential that I think 
it bears checking before I implement.


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.  This causes problems in STEP export as well as (for the arc 
tracks) connectivity issues as dragging requires point matching, not 
just copper overlap.


The issue on edge STEP export (board edge not closed) is related to the 
following:


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 centers, which are the anchors of your board.
If you start your design with mechanical constraints in mind, your board 
will not have EdgeCuts issues.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[José Ignacio]

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 very compact representation for polylines that have
arcs (like arc traces) as the center point is implied. there are also no
invalid values as a bulge of zero is a straight segment and an almost full
circle of infinite radius would be + or - infinity.

On Wed, Jul 10, 2019 at 6:57 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.  Arc
> > direction is implied and unambiguous.
>
> Ah yes, you are right.  We can assume a CW or CCW direction and swap
> start/end to match.
>
> The only remaining concern would be robustness.  You can create a
> start-center-end combination that is invalid, so we'd need to define a
> governing parameter.
>
> The start-midpoint-end triplet can also be invalid but only if you
> assume the midpoint is exactly midway.  The three-point conversion I
> listed previously allows the third point to exist anywhere on the arc
> and avoids this issue.  We would use midpoint for convenience when
> writing the file but don't require it when reading.
>
> Is there a good solution to this issue for the center point idea?
>
> Best-
> Seth
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jeff Young]

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 (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 edge cuts) the 
> two endpoints (or start and end) are usually important, the centerpoint 
> isn't. The endpoints should snap to other graphical items. I don't think the 
> current implementation has caused much problems for that - although I may be 
> wrong, I have struggled with some edge cuts. What has been more important is 
> the limited editing capabilities: I should be able to lock some of the values 
> and edit the arc by giving some values, and edit graphically by using tangent 
> lines. And the current way of having start/endpoint distinction and different 
> funtionality for them in the UI is really cumbersome. But that's another 
> story altogether...
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Eeli Kaikkonen]

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 edge cuts) the
two endpoints (or start and end) are usually important, the centerpoint
isn't. The endpoints should snap to other graphical items. I don't think
the current implementation has caused much problems for that - although I
may be wrong, I have struggled with some edge cuts. What has been more
important is the limited editing capabilities: I should be able to lock
some of the values and edit the arc by giving some values, and edit
graphically by using tangent lines. And the current way of having
start/endpoint distinction and different funtionality for them in the UI is
really cumbersome. But that's another story altogether...

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Seth Hillbrand]

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.  The 
three-arc-point solution I proposed does not need a direction as it is 
implicit in the point positions.



Is there a good solution to this issue for the center point idea?


That was my other concern.  The mid point may not round to 1nm.  It
seems to me you are always bound by rounding and resolution limits.


The nomenclature is biting us here :).  The center point would be in the 
middle of the circle along which the arc is drawn.  The midpoint is on 
the arc itself.


Internally, I propose that the midpoint is a set value (not calculated) 
in integer units.  All integer values up to 53 bits are exactly 
representable as 64-bit floating point values with no rounding.  We are 
currently using 32-bit integers for our internal representation so we 
should not encounter rounding issues with the midpoint.  Now, it may not 
be precisely at the midpoint of the arc but this doesn't matter for our 
calculation, which only needs the three points to lie on the same arc.


In this proposal, the center point, arc angle and radius are all 
calculated and may exhibit rounding issues when directly used.  The 
rounding issues will be on the order of the current rounding issues we 
have with the end point but, critically, do not cause discontinuities.



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.


Agreed.  That is why I want to get the buy-in before coding up a 
proposed implementation.  This will touch a lot of things.


-Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Wayne Stambaugh]

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 fully constrained.  Arc
>> direction is implied and unambiguous.
> 
> Ah yes, you are right.  We can assume a CW or CCW direction and swap
> start/end to match.

Are you planning on allowing either direct or fixing it to a single
direction?  I would think the latter would be preferable.

> 
> The only remaining concern would be robustness.  You can create a
> start-center-end combination that is invalid, so we'd need to define a
> governing parameter.
> 
> The start-midpoint-end triplet can also be invalid but only if you
> assume the midpoint is exactly midway.  The three-point conversion I
> listed previously allows the third point to exist anywhere on the arc
> and avoids this issue.  We would use midpoint for convenience when
> writing the file but don't require it when reading.
> 
> Is there a good solution to this issue for the center point idea?

That was my other concern.  The mid point may not round to 1nm.  It
seems to me you are always bound by rounding and resolution limits.  As
long as you can come up with a robust way to prevent an invalid arc
definition that still meets your end point requirements, then I don't
have an issue with this.

> 
> Best-
> Seth
> 


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


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Kevin Cozens]

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.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Brian]

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.  Arc
direction is implied and unambiguous.


Ah yes, you are right.  We can assume a CW or CCW direction and swap 
start/end to match.


The only remaining concern would be robustness.  You can create a 
start-center-end combination that is invalid, so we'd need to define a 
governing parameter.


The start-midpoint-end triplet can also be invalid but only if you 
assume the midpoint is exactly midway.  The three-point conversion I 
listed previously allows the third point to exist anywhere on the arc 
and avoids this issue. 
I'm not sure I'm convinced that start-mid-end is any more or less immune 
to invalidity than start-center-end.  Either can be specified in such a 
way as to represent an invalid geometry -- both are susceptible to one 
constraining point not being on the same arc (that is, the same distance 
from a specified or implied center point) as another.  In either case, 
KiCad would need to be able to handle this situation, either by applying 
some rounding factor to bring errant points in line, or by emitting an 
error (or not) and discarding the invalid geometry.


As an aside, geometrically speaking, there's no requirement that "mid" 
be actually equidistant from start and end; the only requirement is that 
it be between them and on the same arc (co-arcear?  is there a word for 
the curved version of colinear?). Though not relevant for the concern of 
fully-constrained-ness, I think start-center-end actually leaves less 
room for invalidity, as it is easily validated by comparing the linear 
distance between both endpoints and the centerpoint (i.e. test for 
constant radius).  With start-mid-end, the centerpoint must first be 
derived in order to find out if the geometry is valid (and if it isn't, 
deriving a centerpoint is ambiguous itself).


My $0.02,
-Brian







___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Seth Hillbrand]

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 yes, you are right.  We can assume a CW or CCW direction and swap 
start/end to match.


The only remaining concern would be robustness.  You can create a 
start-center-end combination that is invalid, so we'd need to define a 
governing parameter.


The start-midpoint-end triplet can also be invalid but only if you 
assume the midpoint is exactly midway.  The three-point conversion I 
listed previously allows the third point to exist anywhere on the arc 
and avoids this issue.  We would use midpoint for convenience when 
writing the file but don't require it when reading.


Is there a good solution to this issue for the center point idea?

Best-
Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Brian]

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.





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Seth Hillbrand]

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 ints.  Does that address the concern?  If not, we 
could think about an additional 'direction' parameter.


Best-
Seth

On 2019-07-10 13:29, Jon Evans wrote:

(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.
Having a non-rounded center point stored seems like it could be useful
if the center point location is important to the arc geometry (for
example, if it's supposed to be snapped onto another point).
I can't think of why having the mid-angle point being stored precisely
would be as useful.

$0.02
-Jon

On Wed, Jul 10, 2019 at 1:26 PM Seth Hillbrand 
wrote:


Hi Devs-

I'd like to adjust how our arcs are handled and stored.  This is
part of
the arc tracks work package but is sufficiently tangential that I
think
it bears checking before I implement.

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.  This causes problems in STEP export as well as (for the arc

tracks) connectivity issues as dragging requires point matching, not

just copper overlap.

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 along the arc that is at the half-angle
of
the full arc.

In this case, the values used and saved for connectivity and edge
continuity will be fixed.  The center point of the arc may vary due
to
rounding issues but arc will remain continuous with its neighboring
segments.  Since the mid point of the arc is also saved, we closely
constrain the arc extent as well.

To get the arc center in this case (for drawing/plotting), we would
use
GetArcCenter() from trigo.cpp.

Does anyone have objections to this course of action?  If not, I'll
send
around the patch for testing before pushing.

Best-
Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jeff Young]

+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 in mcad tools, although I could be
>> wrong.
> 
> start-center-end is mathematically over-constrained, so it sounds
> worth avoiding.
> 
> start-midpoint-end encodes a useless -- but not over-constrining --
> degree of freedom, in the position along the arc of the "midpoint".
> 
> The mathematically correct number of parameters is five, and Seth makes
> a good case that four of them should be the start and end coordinates.
> One non-pathological definition of the fifth parameter is curvature,
> in units of inverse-distance.  Zero is no curvature -- converts back to
> a straight line.  The sign of the curvature tells whether the arc bends
> left or right.  I _don't_ assert that this is any better in real life than
> start-midpoint-end.
> 
>  - Larry
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Larry Doolittle]

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
worth avoiding.

start-midpoint-end encodes a useless -- but not over-constrining --
degree of freedom, in the position along the arc of the "midpoint".

The mathematically correct number of parameters is five, and Seth makes
a good case that four of them should be the start and end coordinates.
One non-pathological definition of the fifth parameter is curvature,
in units of inverse-distance.  Zero is no curvature -- converts back to
a straight line.  The sign of the curvature tells whether the arc bends
left or right.  I _don't_ assert that this is any better in real life than
start-midpoint-end.

  - Larry

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Arc Adjustment proposal

[Jon Evans]

(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.
Having a non-rounded center point stored seems like it could be useful if
the center point location is important to the arc geometry (for example, if
it's supposed to be snapped onto another point).
I can't think of why having the mid-angle point being stored precisely
would be as useful.

$0.02
-Jon

On Wed, Jul 10, 2019 at 1:26 PM Seth Hillbrand  wrote:

> Hi Devs-
>
> I'd like to adjust how our arcs are handled and stored.  This is part of
> the arc tracks work package but is sufficiently tangential that I think
> it bears checking before I implement.
>
> 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.  This causes problems in STEP export as well as (for the arc
> tracks) connectivity issues as dragging requires point matching, not
> just copper overlap.
>
> 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 along the arc that is at the half-angle of
> the full arc.
>
> In this case, the values used and saved for connectivity and edge
> continuity will be fixed.  The center point of the arc may vary due to
> rounding issues but arc will remain continuous with its neighboring
> segments.  Since the mid point of the arc is also saved, we closely
> constrain the arc extent as well.
>
> To get the arc center in this case (for drawing/plotting), we would use
> GetArcCenter() from trigo.cpp.
>
> Does anyone have objections to this course of action?  If not, I'll send
> around the patch for testing before pushing.
>
> Best-
> Seth
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp