> Hi, Thomas, thanks!
Thanks for the compliment ;')
> The target machine is a rapid prototyping (RP) machine-- RepRap. Thus, the
> infill for a slice is not necessarily a 'machine all material away' path.
> Ultimately it still uses Gcode, but it is additive rather than subtractive. I
> use EMC for machine control.
Actually that is a _wonderful_ design decision!
G-code is way preferable over obscure proprietary instructions… good to hear…
> The ideal is actually to offset all of the wires on the face inwards to
> create a user-configured number of 'shells' around the exterior boundaries,
> but then inside fill with a hatch pattern. For the offset I can use
> BRepOffsetAPI of course.
Why the hatch? What is the distance between your scanlines?
> The unusual variation that an RP machine has is that the interior hatching is
> ideally not uniform or 100% coverage. Sometimes a honeycomb is desired, and
> other times, a 'sparse' hatch is desired to save material.
Wow, that offers interesting possibilities…
So you'd need to know about the area of the slice for instance?
> I thought about looping over the surface parameters, but then again realized
> it would not create points along a uniform grid.
Hard to say. You'd have to check for each sample whether this is trimmed area
or not.
> Is there a function that will test whether a point is on the surface?
Yes.
class Blaaaat(object)
self.cl = self._setup_trimmed()
def _setup_trimmed(self):
#tol = 1e-4
tol = 1e-9
u1,u2, v1,v2 = BRepTools().UVBounds(self.face)
dailen = (u2-u1)*(u2-u1) + (v2-v1)*(v2-v1)
#dailen = math.sqrt(dailen) / 400.
#dailen = math.sqrt(dailen) / 4000.
#tol = max([dailen, tol])
return BRepTopAdaptor_FClass2d(self.face, tol)
def is_uv_in_face_domain(self, u, v):
'''checks if curve is trimmed
'''
uv = gp_Pnt2d(u,v)
if self.cl.Perform(uv) == TopAbs_IN:
return True
else:
return False
> Maybe it would be easiest to make my own discrete x-y- grid, and then simply
> test each point for membership on the surface.
Like a gp_Lin per-face intersection test… hmm…
> I'm quite excited about this project. The main reason is that nearly the
> entire RP community ( including commercial ) still relies on STL files for
> production. This is a pain because it results in all toolpaths being little
> line segments. So for curves there end up being a billion little G01 moves.
Dave! True! You are bound to set off a revolution in resolution!
Yes, given a high level precision of the machine ( where machine_precision <
tesselation_error ) it sure could be interesting…
Also, it would be less imposing on your hardware controllers, right?
> Using OCC represents the only way i know of to use STEP representations of
> solids, which when sliced still preserve the ability to generate Gcode arcs (
> G02/G03 ), which result in much smaller Gcode and much smoother motion than
> having all arcs represented by tiny line segments.
Cool!
> This would be the first tool that can prevent a triangulated approximation
> during the fabrication process.
Awesome! Promise me you will manufacture me something when you get it done (
and Thomas too, that goes without saying ).
> Thanks for the help!
Sure thing.
Perhaps this saves you another 10 minutes staring doxygens documentation…
Don't forget to look into the Level2API and anything in /Utils ( Construct.py
could be nice for you )
You did see that we paralleled your slicer, right?
samples/Level2/Concurrency/parallel_slicer.py
-jelle
def face_normal(face):
umin, umax, vmin, vmax = BRepTools().UVBounds(face)
surf=BRep_Tool().Surface(face)
props= GeomLProp_SLProps(surf, (umin+umax)/2., (vmin+vmax)/2., 1, TOLERANCE)
norm = props.Normal()
if face.Orientation()==TopAbs_REVERSED:
norm.Reverse()
return norm
def offset_wire(wire, offset_distance):
offA = BRepOffsetAPI_MakeOffset(wire)
try:
offA.Perform( offset_distance, 0.0)
offA.Build()
# offA.Delete()
except:
print 'failed to offset wire'
return None
te = ShapeToTopology()
offA_shape = te(offA.Shape())
return offA_shape
_______________________________________________
Pythonocc-users mailing list
[email protected]
https://mail.gna.org/listinfo/pythonocc-users
