Subtraction of hole from filled area or polyline

Jim Canale

I want to know if there is any way to subtract a hole or other shape from a solid filled polygon or wide polylines.   In this case, the borders of the complex polygons were removed before I was given the drawing.   Only the solid fill remains.    And other parts of  drawing were created out of wide polylines.   If the polygon still had a border, I could delete the fill, draw my hole,  and reinsert a solid fill between the border and the hole.    I can't figure out how to trace the outline of the polygons or polylines.    There is nothing to snap to.

In case you're wondering, I'm working with a PCB drawing that was exported from Cadsoft Eagle PCB in a DXF format.     The board has ground planes made up of wide polylines, and filled polygons.  I need to add some holes to the PCB model and use the modified model to design a bed of nails fixture.

Jim Canale

I should have stated that I am working in 2D.  But that was probably apparent from my comments.

One other thing I need to figure out is how to create a negative of one of the board layers, the solder mask.   It was exported inverted.    I tried filling around all the objects, and then deleting the objects, but since the objects do not have a border, the fill was not constrained.   

Roy Klein Gebbinck

Two possible solutions:
1.
To regenerate the outline of (solid) hatches you can use the built-in _HATCHGENERATEBOUNDARY command.
2.
To create the outline of 'wide polylines' you can try Lee Mac's PolyOutline function.

Roy Klein Gebbinck

... Lee also has an advanced version of his function.

Louis_Verdonck

The HATCHGENERATEBOUNDARY command is best used from the QUAD cursor menu:

1. If necessary, press the F12 function key to activate the Quad.

2. Pause the cursor over the hatch, then choose the command in the 2D editing command group.

Jim Canale

I knew you guys would come up with something!   I'll give it a try when I get back to work tomorrow.  I'll let you know how they work.

Jim C.

Knut Hohenberg

@Jim:
another solution:
- you could use the TRIM command to punch holes also into non-associative hatches. However, due to the (broken) implementation of solid hatches, selecting the hatch for trimming might be a problem, in which case you would have to change the hatch pattern temporarily.
- IMO, wide polylines make sense for drawing PCB layouts, I would probably just use draworder and blocks with wipeouts to create the holes...

@Roy:
Thanks for mentioning HATCHGENERATEBOUNDARY (what a name), I somehow missed this was available...
What I do not understand, though, is why the command does not re-associate the hatch with the restored boundary.
And, BTW, what I never understood is why you cannot stretch or grip-edit non-associative hatches...

Roy Klein Gebbinck

To (re)associate a hatch you can use _HATCHSETASSOC. I don't know why _HATCHGENERATEBOUNDARY doesn't do this automatically.

Jim Canale

Roy,  Louis, and Knut,

Thank you all.   Ok, I have tried HATCHGENERATEBOUNDARY, and it works great.  

However, I'm not having much luck with the rounded end polylines created by Eagle PCB CAD    I loaded Lee Mac's Advanced Poly Outline Function, but I'm not sure it is doing what I need.  I need a 0 width polyline representing the outside edge of the Eagle polylines.    When I invoke MPOLYOUT, and select the all the Eagle polylines which border the ground plane,  the function gives me a an unfilled polyline with the same width as the original polyline.  That does not get me any closer to having a border I can solid fill. 

Knut,  I haven't been able to punch holes in a hatch using the TRIM command.   And I don't follow your discussion on using blocks with wipeouts.    How would I use WIPEOUT to cut a circular hole?   Would you please elaborate?

Knut Hohenberg

Hello Jim,

I never designed a circuit board (one of the few things not asked from architects), but I assume you were talking about the drill holes / connectors in the copper area.
Then I guess the best solution to draw such kind of geometry depends on what your drawing is intended for:
- if it is to serve as input for some kind of CAM, you will probably have to generate closed boundaries for all areas, so the approach proposed by Roy would be the road to follow.
- if on the other hand you are only concerned that your drawing displays and prints correctly, you might prefer a method as commonly found in graphics applications, where you just stack objects on top each other. So, in the screenshot, there are no real holes in the polyline, there are just circular wipeouts (included in blocks, for convenience) drawn on top of it. The advantage of this approach is that you can very easily edit your drawing by just moving grips. Unfortunately, .dwg does not support layer based draw order, but it is still advisable to group all objects that should have the same draworder-level on a layer, so you can e.g. easily bring all holes to the front.

As to trimming solid hatches: BricsCAD internally triangulates solid hatches, and trimming will only succeed if you are able to select one of these (invisible) triangle borders inside your trim boundary, which is not likely the case with small holes. You will likely need to temporarily change the hatch to a dense line pattern in able to select the hatch inside of your hole.

PCB.dwgPCB.pdf

PCB.png

Jim Canale

Thanks Knut.    The PCB's have already been built.     I'm just trying to use the Eagle PCB DXF export to design a bed of nails test fixture for the PCB.   I have to locate holes for pogo pins and other devices.    I also have to modify some of the PCB's, adding holes and cutouts.   (I operate our model shop, and do some machining here.)   I wanted to end up with a drawing I could fully dimension.   Either method you suggested gives me "holes".   (either a mask or an actual hole in the ground plane.)   Once I have the "hole", I am also able to dimension to the center of it.   However,  I'm disappointed that once I join the holes and ground plane into a block, the dimension and radius tools can no longer grab and measure the circle or arc.

Knut Hohenberg

Hello Jim,
you're right - though a linear dimension can be associatively attached to the center of a circle contained in a block, radius dimensions etc. cannot.
I think this is because the linear dimension command asks for a point, and then looks through the database for candidate objects (traversing block boundaries), while e.g. a radius dimension asks for an object, and then just gets a block where it needs a circle or arc. I'm not sure this can easily be improved, but it may still be worth raising an SR.

Jim Canale

I may submit an SR, but I doubt they will be too interested.   Anyway, thanks again for the help.

Hans De Backer

Hi Jim,
they are interested...
When inserting a block containing circles and arcs, I have no problem to dimension these using DIMRADIUS, DIMARC, DIMDIAMETER or DIMLINEAR.
Please file a support request and attach a drawing that allows to reproduce the issue.
Kind regards,
Hans

Knut Hohenberg

Hello Hans,
nice to see Bricsys is monitoring the forums closely...
and my apologies, my statement above was incorrect in a number of ways:
- the problem only occurs in connection with solid hatches, otherwise everything works as you said.
- when the circle is in a block and part of the boundary of a (visible) solid hatch, then the radius/diameter dimensioning seems unable to detect it, even if the draworder inside the block is correct (hatch behind border).
- in this case, linear dimensions work, but the association with the geometry is not reliably established.

The attached drawing contains some test cases:
- the radius dimension of the larger circle can not be created while the solid hatch displays (I had to turn the "hatch" layer of to place it)
- the ordinate dimension was placed with the hatch visible, and is associative nonetheless
- the horizontal dimension was created alike, but although it claims to be associative in the properties tab, it fails to update when the circle in the block is moved
- the circle that is not part of the hatch boundary works flawlessly

So, in all not a big problem, as long as you keep your drawing neatly structured...

hatch_dimension.png

hatch_dimension.dwg

Hans De Backer

Hello Knut,
you're right, to pick entities which coincide with a hatch boundary, and are contained in a block insert, the layer of the hatch should be turned off, else the hatch will 'win', unless the hatch has a sparse pattern that allows to pick the entity at a location where no dash of the hatch falls in the snap aperture. AutoCAD behavior is similar.

Unlike AutoCAD, BricsCAD attempts, and succeeds, to preserve and apply associativity. E.g. after modifying radius and location of the circles during a refedit session, all dimensions are updated accordingly upon Refclose/save. In AutoCAD 2014, none of the dimensions are updated, although they keep stating they are associative.

The horizontal dimension in your example does not update because at creation it probably was not associated to the circle center: when I create a similar dimension and pay attention that the circle center snap marker is displayed when I pick it as a dimension reference point, the dimension updates as expected upon moving the circle.

Knut Hohenberg

Hello Hans,
thanks for clarifying. Indeed, you seem to be right - linear dimensioning is reliable for entities in blocks. In my example, the grid snap coincides with the circle center, so having the cursor snap to this position probably fooled me into thinking it actually snapped to the circle.

Also, the linear dimension not updating although it 'claims' to be associative cannot be called a bug either: one of its defpoints is associated to the rectangle, while the other does not reference any object.
In this case, the properties window would have to report associativity as 'partial' instead of just 'yes' or 'no' to be fully correct, but maybe this is a bit over the top...

But anyway, the fact that BricsCAD already performs better than AutoCAD in this regard should IMO not stop Bricsys from finishing the subject off completely; that the hatchs 'wins' over its boundary objects sound like a correctable issue to me, and I think perfection in such matters could make a strong point for the software.

And, off topic, but while we're at it: the HATCHGENERATEBOUNDARY command that Roy kindly mentioned looks a bit like a misfit to me (reminds me of rhino where each tiny function tends to be a command on its own): I understand that this allowed for simple integration into the QUAD-menu, but would it not be more consistent with the 'AutoCAD-way' if the (-)BOUNDARY command simply accepted hatches as input?

And lastly: _HATCHSETASSOC (thanks again, Roy) is not in the command reference - is this intentional?

Hans De Backer

Hi Knut,
the remarks you make usually deserve being taken into account, and this case is no exception, in fact, we had already planned to rework this for V15.

The reason _HATCHSETASSOC is not in the command reference is that it will be removed in V15, it is a perfect example of "each tiny function being a command on its own". There is already the HPASSOC setting to control whether created hatches are associative, so instead we will, unlike AutoCAD, let the HATCHGENERATEBOUNDARY command obey this setting: it looks like a more consistent and straightforward approach.

Knut Hohenberg

Hans, thanks for the kind remarks, and happy to hear you're working in this direction.