Advanced Search

I've been using the weekly builds for some time. TNP is not entirely solved, but I've slowly learned (after making some models for the third time) to be better at constructing models to avoid TNP issues. Worth the effort to reference things as far up the tree as possible, build reference planes, use parameter sets, etc. Overall I think the CAD is pretty good, once you get used to it. The last couple months leading up to the 1.0 release saw a huge improvement in stability, which is really nice. FAR fewer crashes. My only other real mechanical CAD experience is Rhino, so I can't really compare on that front- just being parametric is such a huge step up.

The CAM workbench in FreeCAD is both amazing and frustrating. It's awesome that it has (eg) adaptive toolpaths that you seemingly can't get in any CAM package under ~$3k USD. The new path/stock simulator is WAY faster/better than it was in older version. Plus, Linux native is great.

A lot of other things are maddeningly close to working well, but need some very specific workarounds to make work. Profiling open contours very notably falls in this category. You can make it work, but have to build a bunch of extra geometry to do so in my experience. It's on my to-look-at-fixing list...

On the up side, my experience fixing things (adaptive toolpaths not using the stock model you provide- pull request pending due to freeze prior to 1.0 release) was that it's shockingly easy. That fix took... a few hours, going into it mostly cold? So if you know Python and/or C++, and see something that seems dumb and annoys you, it might be worth looking into just fixing it.

 

I changed things up a bit from the cad model to work better with the materials I have laying around the shop. Hoping to have the mechanical side of things completed to run the table by the end of the month.

Hi guys i have been updating to the latest 2.9.3 pre-empt iso and seem to have an issue with my settings.
The last time i set up the machine i had a nuc which had realtek nics because i was running debian 10 i was able to select a slightly older board to make the compatibility, but with the debian 12 i have moved on to a slightly newer computer with intel 226 nics.

This newer board seems fine but i am having issues that i can't pin down.
So in summary i can't latch out of e-stop.the settings are the same, but it seems to be an issue.
 

Ha, so here we are for pathpilot. Seems to behave exactly like i imagine it would. Woo.



I guess I need to go look at the probe basic features now.

Hi Mark,
While I looking around for stuff on the previous entries I came across these 2 images, I can't recall where I got them from. They relate to stuff we discussed a way back. I mentioned that the resistors on the gear change were never invoked on my machine. I translated the images using Google, which I know you don't need, but I see at the bottom they mention the resistors are not needed for later Mahos. Mine is certainly fine without them. I'm thinking that the earlier Philips controller would have been much slower and maybe could monitor the cams fast enough. The diagrams are also the first I've seen that explain the actual reason for cams 4 and 5. So it may be that with the massive improvements in clock speeds since then the LinuxCNC conversions may not need them either? Mine still uses cam 5 as I recall to decide which way the ladder code hunts a cam lobe first. Presumably for the case where you've had a crash and it's not on a cam lobe.

Another thing I'm surprised at is that in the LinuxCNC conversions you keep a lot of the relay logic. Wouldn't it be better to shift the I/O for that into the computer and make it "fly by wire". As it stands there is a lot of relay logic outside LinuxCNC that it doesn't know about. You would still need relays for shifts in voltage like 5K1, but it wouldn't be for logic. On my machine it would involve a more than it can do I think. But in both our cases it seems we have a dinosaur brain sitting in parallel with a modern one.

Cheers,
David