the slow loading directory bug is specific to the mac build, somewhere I found a fix by:
FYI, I am watching freecad from a distance and it looks like they are making some improvements to mac. I would keep an eye on it and try it again in a bit if you are having stability issues in mac.
Generally. In open source projects, there are people (the maintainers) that don’t have your system and you’re really helping them by reporting issues. Especially if they make some data products (like a core dump or log file). Reporting issues is a really helpful thing to do, especially if you are willing to work back and forth while they investigate it.
So, in essence, if you use FS 360 for drawings etc a fairly basic level ie plywood things, and export the .dxf from the sketch and use Estlecam etc then really nothing will change that much? Except you will have to shuffle drawings from active to inactive and back…?
Pretty much. Until the next culling of free features.
I thought that means no dxf export?
Can I still laser-cut or do 2D routing?
Save As DXF is still available from sketch.
Oh. That’s a lot better.
Out of curiosity, what does export as dxf from the file menu do? Automatically make a sketch or something?
I’ll have to go play with it, but I believe it will export the entire part to dxf and not just a single schematic.
OK, I’m still new to toolpathing/machining.
My question is regarding the “rapid feedrates are limited to cutting feedrates” statement in the changes.
What exactly does this mean?
Rapid noncutting moves will move at the same speed as cut moves. So if you finish a cut on one side of say a 24" wide sign, and the next start is the other side, it’s going to take a while to get there.
But that’s only if you do your cam in fusion. You can still have rapids in another cam if you export the dxf.
It may be possible to add some rapids back in if we can make some assumptions about the geometry. Everything in the clearance plane is a rapid, for example. It won’t help for movements in a pocket or adaptive stuff, unless we got very smart.
@barry99705 thanks for the clarification.
are there any G code editors that can isolate the rapids a then change them to what you want, or would that be a daunting task
I didn’t see any official news, but the twitters are saying they are backing up a little and allowing step output.
Here’s a good video that confirms it.
That’s funny, I actually bought Steve’s course on the weekend workshop, so I could get my garage shop cleaned up so I could rebuild my MPCNC (this time with dust collection). Didn’t think I’d find another mere mortal on here.
I haven’t bought his course. Just watch some of his YouTube stuff
Somebody at Autodesk saw the AWS S3 bill as everyone accessed all their documents via the script you told everybody about. You get all the credit for this turnaround Jeffe.
I couldn’t sleep and started thinking about the rapid speeds issue. I think this could be fixed with a simple python script.
Most rapids across a part are preceeded by a positive z movement followed by a negative z movement. We should be able to read the file into python, look for lines of gcode that fit that situation and adjust them. Heck, might even be able to do it with a fancy sed command.
Most of my rapids look very similar to this:
g0 z5 fsomething
G0 xsomething ysomething fsomethingfaster
G0 z-something fsomething
I think rapids inside of a trochodial milling operation are less of an issue as you’re usually running a higher cutting speed already.
So I just did a google search for G code editors with the idea of manually changing rapids if necessary.
I found this website https://ncviewer.com/ where you can load your G code and you can click any position you want, it highlights that line in the code which then you could modify yourself.
