Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    sliptonic
    @sliptonic
    merged
    Schildkroet
    @Schildkroet
    thx
    Schildkroet
    @Schildkroet
    do you know the current release plans?
    sliptonic
    @sliptonic
    Not really. I've been through this enough times to know what it looks like but it's never very predictable.
    At some point, Werner and Yorik well agree that it's time to freeze. Then it's anywhere from a few weeks to a couple months until a release is done.
    There'll be a major push for bug fixes and translations. Also another push to cleanup wiki
    Werner has signaled that it's close but I don't know what exactly he wants to see before pulling the trigger
    Eric Trombly
    @etrombly
    So I think to fix the loading times is going to involve going over all the imports. I'll keep working on it. I'm going to fix up the things Werner pointed out on my other pull request first though.
    Russell Johnson
    @Russ4262
    @etrombly
    Sounds great! Today rings of progress for the PathWB!
    @sliptonic
    I just submitted PR #3314 to fix the manual StartDepth and lack of update for it. All Gui::QuantitySpinBox class-based inputs were affected by the problem. This PR should fix the issues. (At least it does on my
    ... Windows machine.
    Eric Trombly
    @etrombly
    @sliptonic just watched your video. Really like the idea of having it remember a custom path, I keep my tool library in dropbox. Is that i3?
    sliptonic
    @sliptonic
    @etrombly yep,I3! Thanks for looking at the import stuff and the PR
    Russell Johnson
    @Russ4262
    @sliptonic
    Travis CI is failing on deburr test.
    @sliptonic Is it due to PR #3132 ?
    ======================================================================
    FAIL: test01 (PathTests.TestPathDeburr.TestPathDeburr)
    Verify chamfer depth and offset for a 90° v-bit.
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/usr/local/Mod/Path/PathTests/TestPathDeburr.py", line 62, in test01
        self.assertRoughly(0, offset)
      File "/usr/local/Mod/Path/PathTests/PathTestUtils.py", line 38, in assertRoughly
        self.assertTrue(math.fabs(f1 - f2) < error, "%f != %f" % (f1, f2))
    AssertionError: False is not true : 0.000000 != 0.010000
    
    ----------------------------------------------------------------------
    Russell Johnson
    @Russ4262
    @Schildkroet
    Any ideas?
        def test01(self):
            '''Verify chamfer depth and offset for a 90° v-bit.'''
            tool = Path.Tool()
            tool.FlatRadius = 0
            tool.CuttingEdgeAngle = 90
    
            (depth, offset) = PathDeburr.toolDepthAndOffset(1, 0, tool)
            self.assertRoughly(1, depth)
            self.assertRoughly(0, offset)  ## here....
    
            (depth, offset) = PathDeburr.toolDepthAndOffset(1, 0.2, tool)
            self.assertRoughly(1.2, depth)
            self.assertRoughly(0.2, offset)
    Schildkroet
    @Schildkroet
    Yes, this is because of my PR
    offset.PNG
    I thougt an offset with 0.0 makes no sense. So i added a check and increased it to at least 0.01mm
    sliptonic
    @sliptonic
    Isn't deburr supposed to be an "on the line" op?
    Daniel Wood
    @dubstar-04
    @sliptonic I think the offset allows the tool to not cut at the tip. i.e part way up the tip. This helps with tool wear and reduces the chance of getting a step in the chamfer.
    Schildkroet
    @Schildkroet
    @sliptonic This deburr op is to create a chamfer. Offset of 0 would mean, the tip of the tool would move along the edge of the operation
    deburr.png
    sliptonic
    @sliptonic
    Right. I know the path is offset. I had in my mind that the offset was done in the path calc and the user was setting it up for a on-the-line. Makes sense
    mlampert
    @mlampert
    it's not the "tip" for offset 0, it's the edge of the bottom radius - IIRC
    Daniel Wood
    @dubstar-04
    @sliptonic do we need to request that Werner review this: FreeCAD/FreeCAD#3316
    sliptonic
    @sliptonic
    No. It's all in RT's code. If it passes unit tests and seems to work, it's good
    Eric Trombly
    @etrombly
    https://imgur.com/gallery/4YJPeUr So a lot of the slow startup time is actually ArchPanel and DraftTools. From testing the path workbench was taking 10-20 seconds to load. Out of a 16 second load 5 were just importing those two. I switched the slowest imports to loading deferred and it got the start times down to 3-5 seconds (the second image). ProfileEdges and PathJobGui use Draft all over the place, and PathPocketShapes uses TechDraw all over, so for those three I just commented out the imports for testing. Would have to see if it's worth the trade off of deferring the import though. The first time you use a function that needs them there will be a 3-4 second hang while importing. I think it's worth it though.
    sliptonic
    @sliptonic
    @etrombly Good stuff! I'll take a look. ArchPanel might be something we can deprecate. I'm not sure anyone is actually using what was built there.
    DraftTool is widely used. Did you find any evidence of an import loop?
    Russell Johnson
    @Russ4262
    @sliptonic @etrombly
    I just submitted PR #3320 that will optimize ProfileEdges a little, removing dependency on the Draft module and DocObjects.
    I need to look at 3D Surface next. Someone in the forums posted errors with a simple use case of Rotation usage.
    Daniel Wood
    @dubstar-04
    Amazing work @Russ4262 Thank you for all your effort!
    Eric Trombly
    @etrombly
    Here's a comparison of the branch I was working on, to at least see all the files that needed to be modified. I didn't verify if everything was still functioning correctly though. https://github.com/FreeCAD/FreeCAD/compare/master...etrombly:path_open
    @sliptonic It doesn't look like an import loop was the problem. In kcachegrind during load there were a bunch of cycles, recursive calls in freeze when loading the modules. I thought it was caused by an import loop, but that's not the case. Haven't been able to track it down, but it looks like it wasn't the cause of the slow imports anyway.
    Eric Trombly
    @etrombly
    for the modules that we can't strip out the imports we could probably see if lazy loading will work. https://wil.yegelwel.com/lazily-importing-python-modules/ If I have time I'll test it. Pretty busy today though.
    sliptonic
    @sliptonic
    In the near future, we need to rethink some things in order to support other kinds of jobs like lathe. It would be great if we could defer loading of the different operation implementation so that a Lathe job user isn't importing all the code for milling related ops.
    Eric Trombly
    @etrombly
    so the lazy loading seems to work pretty well. Since it could be used by other workbenches where should I put it? Base, App?
    Eric Trombly
    @etrombly
    also it's from tensorflow and apache licensed, is that compatible? If not I can probably find another implamentation.
    Eric Trombly
    @etrombly
    just looked it up, freecad is lgpl2 or later, so it's fine to include apache stuff
    Russell Johnson
    @Russ4262
    @sliptonic
    I just rebased the LGTM pull request for Path since PR #3295. I ran PathWB unit tests with latest 20477 nightly and didn't have any errors.
    sliptonic
    @sliptonic
    I'll take a look in the morning. Bout to crash
    Russell Johnson
    @Russ4262
    Sure. Just communicating. No pressure or hurry. Thanks.
    sliptonic
    @sliptonic
    @etrombly apache might be technically license compatible but I highly encourage a discussion on the forum before adding any dependencies. Some folks have strong feelings about particular licenses
    Actual placement probably needs input from werner and kurt
    Russell Johnson
    @Russ4262
    @etrombly
    Early morning, Sir. Just loading up the recent 20477 nightly. Working on 3D Surface module. Running some rotational paths. Your improvements are quite noticeable so far. Wanted to say thanks for bringing your expertise to the FreeCAD project, and also, specifically, the PathWB. Much appreciated, Sir!
    Eric Trombly
    @etrombly
    @sliptonic no problem, I'll make a thread later. It's not going to be an external dep, just a single file that's copied. I'd just keep the original copyright and license header at the top of the file. @Russ4262 no problem, it's been great working on this with you guys, learning a lot.
    Eric Trombly
    @etrombly