Configurable path patterns
The migration of PyCAM to a new modular GUI structure is almost completed. Thus I recently started to add some new fancy features to exploit all the new possibilities. One quite visible feature is the new configurable path generator. It now allows you to select a spiral toolpath instead of the currently available grid pattern.
Expect some even more interesting features for the next release …
UPDATE: rounded corners and spiral direction (inside / outside) are now configurable, as well.
Comments
Looking good!
The available strategies in Pycam were a bit lacking, so this is certainly good news. My personal preference is a radial one, where all paths originate from one central point (pruning is needed to avoid needless overlap). An even better strategy (IMHO) would be one that made paths perpendicular to the waterlines of the model.
But as far as I am concerned: the biggest missing link is the concept of ‘operations’: That can be the different depths you use in 2.5D milling, a finer endmill/strategy in a detailed part of a 3D model, or my personal favourite: a operation that drill holes in each object to secure them to the routing table (saves you from hitting them with the mill bit). Each operation would have the option to load its own dfx file or 3d model and/or define a segment of each. Is is not like you cannot use multiple fles already, but you need to juggle a lot if you wish to make a change in a previous operation.
Re: Looking good!
thanks for your comment – I am happy, that you like the new path pattern.
I also thought about the radial one, but for now I don’t have a good idea how to calculate the transition from a circle (in the middle) to a rectangle (outer limits). Any hints?
The waterline-based path would be clearly the best for a contour cutter strategy. Sadly the current implementation (waterline + tool radius offset) is not perfect and I am also missing a stable polygon offsetting algorithm.
Different depths: that is something, I was thinking about, as well. I guess, a good approach would be to determine some levels with “interesting features” (probably horizontal triangles) and use these instead of a fixed layer height.
Detailed parts: I plan to implement a “bounds” setting, that will not be defined via rectangle corners. Instead it will be based on a 2D model: closed polygons defining the processing bounds. In the future it would surely be good to detect detailed areas automatically.
Holes: do you mean holes, that should be drilled via GCode? Or are you talking about areas, that the tool may not enter (avoiding collisions with the screws)? Currently this can be done via the “Crop toolpath” feature, but this is a bit clumsy, I guess. Alternatively the above “bounds based on 2D model” approach could do the same. Or what do you think?
Thanks for you suggestions!
Lars
re radial pattern: if you
re radial pattern: if you travel outward stop when you encounter the edges of the bounding box. It might be better to travel inward though: start at the outer perimeter next to the last start (+ bit diameter – overlap) and continue until you come too close (say 50% of previous value) or you reach the centerpoint.
re holes: yes I mean drill hole to indicate where the workpiece should be screwed to the spoilboard. That way, you (should) know where your screws are and you won’t bump into them. (nb such a operation should always produce it’s own gcode file. Combining will lead to: let’s start again… oops)
re details: while making suggestions to the user is good, trying to do their thinking is not. Each job has its own set of challenges, some don’t lend themselves very well to automation. If you don’t need it now, don’t implement it now.
Post new comment