Feature request: Multiple horizontal passes on Profile/Contour?

[chrisb]

What you describe sounds to me as if you should use two operations, one for the outside and another for the inside with a different FinishDepth.

[VVilhelnn]

Have you tried an adaptive profiling? or an adaptive clearing from outside?

Thanks for the reply, yes I have tried it and play with the settings, I cannot get it to do profile in straight line. It generates 100 or maybe 1000s of little circles which take hours to actually cut (Looking at G-code all of these are a bunch of segments and G1 commands, Wondering how come G2 are not used as in helix operations , this is probably why is taking so long to cut). Usually with CNC router the parts to cut out are much larger and not like CNC mill the difference being couple of meters of work area and this operations with 100 of circles will take hours to cut.

I also try clear operation, but the problem with the clear operation is that it wants to clear the entire "BOX boundary and not just next to the part wall.

stock on Job properties is set to use solid, not bbox, or extend, etc... but tried those too and get same results

for example:
profiling:


clearing:


-Wilhelm

[dubstar-04]

stock on Job properties is set to use solid, not bbox, or extend, etc... but tried those too and get same results

-Wilhelm

I have to do this very frequently and I normally achieve it by creating multiple profile operations and adjusting the 'extra offset' on each pass.
You might have to create passes at multiple z offsets but it works.

profileOffset.png (31.1 KiB) Viewed 1780 times

I don't understand why there is resistance to add the ability to make multiple passes to the profile operation. In IMO it would add a lot of value to the operation and bring it inline with users expectations.

Example file attached.

Thanks,

Dan

[Wsk8]

See #3484

[dubstar-04]

See #3484

Absolutely Fantastic!

This will be a real time saver for me!

Thanks,

Dan

[VVilhelnn]

See #3484

Absolutely Fantastic!

This will be a real time saver for me!

Thanks,

Dan

I second the thanks (Absolutely Fantastic! ) for the addition, thanks this will really help as original post described; when having DYI CNC routers with low rigidity, again thank you this will save lot of time and frustration with chips not being evacuated in deep profile operations... Thank you soo very much .



But, but... Please see my next thread after testing gcode in simulator...

[VVilhelnn]

See #3484

Hi @Wsk8, Again thanks for the work... I was testing this but I think it did the multiple passes but didn't really get the issue resolve, this basically does what we do manually create multiple profile passes one at the time... key part one at the time, that is what we are trying to avoid; what we are trying to achieve is that during the profile operation there is enough room for the chips to go somaple place specially if say we are milling a 25.4mm (1in) piece of aluminum, the endmill will be very deep in the slot rubbing with chips that were not evacuated against the wall of the slot.

With current changes it does one profile all the way to final depth then second profile offset down to final depth, I think what we where asking for is per-step down do each incremental offset thus creating space for chips to go someplace palace while we continue cutting down the slot.

For example:
we have the 25mm thick aluminum at a step down of say 0.5mm (very weak machine), and we want 2 times pass profile with incremental offset of say 1.5mm (endmill is a 3.175mm). What we want to save the life of the endmill and the project from heating/melting/sticking the aluminum into the endmill. One pass step down to 0.5mm second pass same Z but offset 1.5mm, next step down next offset. When I am down at -24.5mm there is a wider slot where chips can go to and hopefully pick up by the vacuum to evacuate-out and/or if not they are not rubbing and creating heat down a 24.5 mm slot.

Of course if looking at this it seems better for passes to start away from the part so the pass closes to the part is the one that has the benefit of the extra wide slot as opposed to the other way around.

I hope that all of us who are looking for this do have the same interpretation of the end-goal, if not please say something.

Again thanks everyone this is a great tool... now that I can see what files/code got modify I can also experiment Thanks for that too.

[chrisb]

I hope I finally understood what these multiple passes are about, and if so, then my post above was wrong. The current approach is what I would call a "depth first" approach ...

depthFirst.png (14.55 KiB) Viewed 1692 times

... where the second path is exactly below the first, and the third is exactly below the second.
When the bottom is reached a path beside the first is milled and the it goes just down again.

The desired behaviour would be to have a "width first" approach ...

widthFirst.png (14.53 KiB) Viewed 1692 times

... where the second path is beside the first, and the third is exactly below the first; fourth is again besides the third ...
When the bottom is reached everything is done.

If this goes all through, then depending on which side the milling started, path 6 could be avoided, but - not being an expert - I would start at the far side and do the second step with a stepover of 50% to get a better finish at the model and not at the waste.

what we are trying to achieve

Wilhelm, is this right as I understand it now?

[VVilhelnn]

I hope I finally understood what these multiple passes are about, and if so, then my post above was wrong. The current approach is what I would call a "depth first" approach ...
depthFirst.png
... where the second path is exactly below the first, and the third is exactly below the second.
When the bottom is reached a path beside the first is milled and the it goes just down again.

The desired behaviour would be to have a "width first" approach ...
widthFirst.png
... where the second path is beside the first, and the third is exactly below the first; fourth is again besides the third ...
When the bottom is reached everything is done.

If this goes all through, then depending on which side the milling started, path 6 could be avoided, but - not being an expert - I would start at the far side and do the second step with a stepover of 50% to get a better finish at the model and not at the waste.

what we are trying to achieve

Wilhelm, is this right as I understand it now?

You nailed it with the description, YES the need to help with the chips is the "width first" approach. Also on comment of the best finish start away from the part finish closes to part.

I was experimenting with the code a little now that the params where added and I had example code; I got half success by changing _buildPathArea function instead, of course this only takes care of close segments not open segments.

Not sure if is ok to talk about the code here but here it goes... what I was experimenting with just to get my hands dirty is the following (code below) From the changes of @Wsk8 and patch into FreeCAD.19.21125

I disable the loop added by @Wsk8 with the following change "for i in range(1)" (back down to one loop, and not change a bunch of code), but use the same strategy in _buildPathArea to generate all the sections then merge/interleave them since that generates depth first. The results I got where almost there as first pass starts away from the part and cuts each pass to the part, but second pass starts closes to the part then ends on away from part, next one is like first pass away first then close to the part and so on... probably the interleaving and the loop... But first time I play with this code so not sure of the ins and outs and probably not the right place to make this change.

Code: Select all

   
   def _buildPathArea(self, obj, baseobject, isHole, start, getsim):
        '''_buildPathArea(obj, baseobject, isHole, start, getsim) ... internal function.'''
        # pylint: disable=unused-argument
        PathLog.track()
        area = Path.Area()
        area.setPlane(PathUtils.makeWorkplane(baseobject))
        area.add(baseobject)

        if obj.ProfileCount < 1:
            obj.ProfileCount = 1

        OrigOffset = obj.OffsetExtra.Value

        sections_perProfileCount = list()
        for i in range(obj.ProfileCount):

            areaParams = self.areaOpAreaParams(obj, isHole) # pylint: disable=assignment-from-no-return

            heights = [i for i in self.depthparams]
            PathLog.debug('depths: {}'.format(heights))

            area.setParams(**areaParams)
            obj.AreaParams = str(area.getParams())

            PathLog.debug("Area with params: {}".format(area.getParams()))

            sections = area.makeSections(mode=0, project=self.areaOpUseProjection(obj), heights=heights)
            sections_perProfileCount.append(sections)

            # Increase offset for next pass
            obj.OffsetExtra.Value += obj.MultipleOffsetExtra.Value

        # Reset Offset to its original value
        obj.OffsetExtra.Value = OrigOffset

        sections = sum((list(i) for i in zip(*sections_perProfileCount)),[])

        # sections = area.makeSections(mode=0, project=self.areaOpUseProjection(obj), heights=heights)
        

But to be completely honest I can't explain why it started away from the part, the way I understand the code it will create the list of the sections with the tool offset, then second list with first off set from (obj.OffsetExtra.Value += obj.MultipleOffsetExtra.Value) and so on with any extra passes, when I merge interleave the list I was expecting

list 1 [a,b,c] the arrays are ----→ depth-first
list 2 [1,2,3]
list n [#,$,%]
↓
offset down the list of lists

new list [a, 1, #, b, 2, $, c, 3, %]

and that is what the code does, not sure where but some place probably there is an optimization pass and the gcode generated does this:

[#, 1, a, b, 2, $, %, 3, c]

interesting outcome

-Wilhelm

[VVilhelnn]

Had a few toughs and wanted to get some perspective from other...

and manly for the expert on the code design/implementation; I was wondering if profile is the right approach, seems like a pocket operation with a "fake wall offset from the part". Would pocket be a better option, then we get for free all the different patterns for pocket "zigSag, Offset, Spiral, ZigSagOffset, etc, etc", what I am doing looks a lot like a pocket with Offset pattern.

Would it make more sense to treat this as a pocket? it seems it is a pocket in between the side of the part and a fake wall offset at a "n" value. It would keep down "feature creep" and the behaviors expected are well understood from a pocket perspective!!?? maybe the only thing needed is for the boundary options to support a offset to part boundary as oppose to a square box, paort body (with no offset). This way the pocket operation would work outside the part as it does now with the boundary box. This way all operations still work as is, no changes to pocket or profile code!!??

Opinions / thoughts? Just thinking the solution is already there with the pocket operation, it just need a way to tell pocket the boundary offset (following parth outline, not square) around part. Would this create others problems or it would just work?

-Wilhelm