2025-02-22

Last modified: 2025-02-23 09:17:56

• Car ramp toy
• FreeCAD

Car ramp toy

A start:

(Only the top one is complete, I'll just mirror it in the slicer to get the others).

Obviously will be screwed to some sort of wooden frame.

I have 5 colours of ABS-GF filament coming.

Now just needs a car that will fit. And probably I should make sure "normal" size toy cars fit as well.

The road is 25mm wide at the flat part.

Lucy's Mini is 32mm wide, so I'll make it 35mm instead.

I think I want to put washers in the car bodies to give them a bit more weight than just 3d-printed plastic.

And maybe o-rings for tyres? But will they just get pulled off and lost? Maybe don't need tyres.

And how do you do axles?

I made a toy train once and I just attached the wheels with M3 allen screws, and they ripped out when the train got trod on, so I probably want the axle to go all the way through.

The ones she has appear to be mushroomed-over on the ends, not sure I could easily do that in a way that doesn't buckle the axle or bind up the wheels.

FreeCAD

I looked at making all the FreeCAD recomputeFeature() stuff require a Message_ProgressRange&, but I think the issue is that the FreeCAD "App" doesn't depend on OpenCascade. Only the Part workbench depends on OpenCascade. So I can't use OpenCascade types inside "App".

So maybe I basically wrap ProgressIndicator/ProgressRange/ProgressScope in FreeCAD, and provide a function that can return the OpenCascade versions at whatever layer requires them.

According to Cursor, the Part workbench is the only one that directly interfaces with OCCT.

I should basically make a FreeCAD ProgressRange interface in App, and a no-op implementation of it. And in Part I should make an implementation that just wraps the OCCT one.

OK, I'm working on this. I need to do ProgressScope as well, but forget it for now.

The process is to change the interface to require a ProgressRange argument, and then try to compile it and see what fails, and fix it, and repeat until done.

After I've finished this, I need to make all the TopoShape methods take ProgressRange arguments and wrap them in something I can pass to OCCT. Then it'll be more of the same edit/compile/edit/compile/edit/compile/etc. until done.

And then we can grep the codebase for NullProgressRange and work out whether the places that construct them should also take one in.

Probably the thing that constructs a NullProgressRange should instead create the ComputationDialog? Either it is in a Gui component, in which case it should create the dialog, else it should take a ProgressRange as an input.

I'm stopping for tonight, this seems to be going well though.

$ git diff | wc -l
6244

FML.