Mail Archives: geda-user/2018/02/09/22:29:38
On Fri, 9 Feb 2018, karl AT aspodata DOT se wrote:
>> (The real fix would be to upgrade pcb with the flag compat patch, back
>> from 2013 - but I gave up on trying to get it applied back in 2015)
>
> You mean this:
> http://www.delorie.com/archives/browse.cgi?p=geda-user/2013/09/01/02:49:59
Yup.
> Yes, wouldn't mind that, but Richards problem was to cooperate with
> the pcb programs run by his fellow designers, i.e. make it work with
> older versions of pcb.
Yes, I understand. And that's what shoudl be absolutely possible with
pcb-rnd. You should be able to work together with your friends who use
pcb, kicad or protel if you use pcb-rnd.
>
>>> pcb: rtree.c:1054: r_insert_entry: Assertion `which->X1 <= which->X2' failed.
>>> Aborted
> ...
>> However, the assert is a bug in pcb - it should not assert even on invalid
>> input.
>
> Perhaps, but it does in the debug version, and the problem was: can
> Richard save files from pcb-rnd and give them to his co-workers ?
Again: the goal, and normal situation is that you can save pcb files from
pcb-rnd and load them with older and recent versions of pcb mainline. When
that doesn't work, that's a bug, that users need to report so it can be
fixed. As you have seen yesterday, the bugs you reported got fixed
literally within minutes. We are still in the middle of a big data model
rewrite so it's sort of expected to have bugs like this, in trunk. We
expect to have this sort of things fixed by the next release. See also:
http://www.repo.hu/cgi-bin/pcb-rnd-people.cgi?cmd=timeline
What I dislike is when you say things that suggest the normal situation is
that pcb-rnd can not work together with pcb mainline. That's _not true_.
It is designed to work together with pcb mainline as much as with kicad.
There are bugs, like in any other software. You need to report the bugs,
else they won't get fixed.
The negative coord problem got fixed in pcb-rnd. What I said was that it's
not handled properly in pcb if it gave a bbox related assert on it.
Yes, this assert happens only in debug mode - in non-debug mode you don't
get the an assert but random misbehavour, perhaps in any rtree related
code.
>> If it doesn't like negative coords in some fields,
>
> Soo, what do a "thickness" of -2mm mean ?
For historical reasons smd pads are lines in pcb. At the end you msot
often want rectangles at the end, so you toggle the square flag. There's
some code that converts between the two shapes, "square cap line" and
"rectangle". It's just a bunch of + and * operations, negative numbers
technically do a coord flip. If you have both forth and back converter
calculation written correctly, you get full round trips - I did that with
pcb-rnd, so I didn't even notice the negative coords.
Anyway, I changed the code to flip the coords manually so we always emit
positive thicnkess now. What I said about pcb's parsing still holds: if it
doesn't handle negative coords properly, it should warn about them because
any random 3rd party code, e.g. footprint generator scripts can
occassionally make a similar mistake and get a negative coord and the bbox
assert is not very helpful figuring it.
So this is as much as time I want to spend on it, from now on pcb-rnd
doesn't export negative thickness, and whether pcb improves their error
messages or not is not my problem.
(One last thought on this: the line-as-rectangle idea is bad design that
introduces subtle corner cases. My favorite one is when you want a real
square: the most trivial way is to have a zero-length line, in which case
the thickness of the line will happen to be the side length of your
square. Sounds like a good idea. Until you rotate your element 45 degrees:
that's when the square stays axis aligned because the 45 degree rotated
endpoints of a zero length line is the same as for any other angle. A
trivial workaround would be to cheat and say the line is 1 nm long -
probably works for n*45 degree, but what if you rotate 30 degrees next? So
in reality there's a virtual limit even on the minimal length of pad lines
if you want to get it to work properly. For reasons like this we can use
real polygons for pads (padstacks) in pcb-rnd.)
> 1, silk lines is missing from the pcb-rnd saved element
>
> 2. pcb-rnd creates attributes which it later complains about:
>
> 3. original clearance is 0.5mm, pcb-rnd converts that to 0.25mm
>
> 4. I don't really know how to treat a mask value of -2mm,
> the orig. is 1.5mm
>
> 5. theese are supposed to be the same, care to tell me how:
> Pad[-0.3500mm 1.5500mm 0.3500mm 1.5500mm 1.3000mm 0.5000mm 1.5000mm "1" "1" "onsolder,square"]
> Pad[-0.3500mm -1.5500mm 0.3500mm -1.5500mm 1.3000mm 0.5000mm 1.5000mm "2" "2" "onsolder,square"]
>
> Pad[0.0 1200.0um 0.0 1900.0um -2.0mm 250.0um -2.0mm "1" "1" "square"]
> Pad[0.0 -1900.0um 0.0 -1200.0um -2.0mm 250.0um -2.0mm "2" "2" "square"]
>
Thanks, these look like legit bugs.
As I asked before: please send minimal test cases. Just copying random
snippets and grep output won't help me reproducing the problem here. It
looks like you can get these with a footprint. Please send that footprint.
Regards,
Igor2
- Raw text -