Mail Archives: geda-user/2018/02/05/08:03:54
Hi Igor,
Op 05-02-18 om 13:25 schreef gedau AT igor2 DOT repo DOT hu:
>
>
> On Mon, 5 Feb 2018, Richard Rasker (rasker AT linetec DOT nl) [via
> geda-user AT delorie DOT com] wrote:
>
>> Igor has been very kind to implement this in his pcb-rnd, and even
>> though it has some quirks and limitations(*), it was a great help in
>> marking fixed 100 mm distances along a path.
>
> Cool, I'm happy you could solve your problem with this quick-hack
> solution.
Yup, it's definitely a lot easier than manually breaking up lines,
finding resulting segment lengths, and then counting dots :-)
And it's of course also the (ahem) warm fuzzy Open Source mentality,
with a feature fix within minutes instead of years (if even that).
The only drawback is that I feel somewhat guilty for hardly contributing
things myself (apart from some translations), being an end user most of
the time.
My programming abilities are unfortunately limited to a bit bash/shell,
and PIC assembly (albeit this last one quite extensively).
I could do some cleaning up up symbols and footprints, but that's only
useful when done on a large scale, which would gobble up a lot of time.
>> *: it only functions with the cursor over a straight line segment, at
>> least 40 mils from a local bend point, not over arcs. It also appears
>> slightly imprecise: it reports different values for the exact same
>> grid point if the mouse cursor is moved between measurements (I
>> estimate some 0.2% deviation maximum). And oh, by default, it selects
>> the local line segment between the local bend points, and it 'Finds'
>> (green highlight) the path to the right. But it's very useful all the
>> same.
> Arc: if needed, it's possible to do the same trick for arcs.
>
> Preicision: well, it works as specified/requested: to the cursor (not
> to the crosshair!). It's possible to modify it to work to the
> crosshair, if that's needed.
Ah, that'll be it -- I didn't think about the difference (so the one
being imprecise would be me, then, haha).
> The 40 mil limit: this is the only one that's somewhat hard at the
> moment. I plan to have a full rewrite of find.c this year (for other
> reasons), and that will introduce features that will make it simpler
> to do this sort of searches too, and then the 40 mil limitation could
> be removed.
Please don't spend too much time on these one-user features ... although
I can image some other uses, having to do with inductances and
resistances along track lengths, or the already mentioned memory bus
applications, with parallel chips each requiring well-specified,
identical path lengths. So it might have some more uses...
But anyway, thanks again,
Best regards,
Richard
- Raw text -