Advanced Search

For context, this is what I'd expect to be able to get out of the Adaptive operation: 

That lets me set the speeds/feeds to optimize MRR within my machine's limits, based on the depth of cut I know it's taking. If it starts taking variable depths of cut, I'm running far slower than I need to for the shallow stepdowns. Not to say Z level detection is a bad feature at all! if I weren't so obsessive about trying to optimize toolpaths, it'd be great to have a one-click option. But it's suboptimal if you're trying to optimize cut time.

I'll try not to be a broken record about this, but IMO give me the dumbest, most manual way of specifying an operation first. Once that's bombproof, make it nicer/easier. Doesn't matter how easy it is if I have no way to get the output I want.

And again... I have strong opinions, they may not reflect the general public's. You should design your software to work for your target demographic, not a single squeaky wheel on a forum.

I've updated my initial comments to reflect where I mis-represented things.

I'll try to move more detailed bug reporting to your actual system, but quick notes below. Also a reminder that I'm just one voice- what I say isn't law, and the way I expect things to work isn't necessarily "right". So long as you can get to the same end result, there's room for interpretation. It's when you literally can't do what you need to that there's a problem.

Adaptive doesn't clear outside stock, regardless of bounding box vs silhouette selection. This is with bbox (silhouette is even more constrained):
 
(you can also see it cutting a bunch of layers, when I'd really like it to do one depth on the outside and one on the inside- at least the option to control that)

Re AFR: This appears to be a different bug than I presented- it appears cuts you add manually subsequently show up in the AFR list- that caused me to believe it was partially detecting features, when in fact I had only partially selected them.

Re chamfer: The highlighted face is one giving me problems. There's no chamfer modeled on it- I just want to do a slight edge break. The entire contour has tangent end points- tiny radii in the "sharp" corners. If I select the face and try to chamfer, I get an error about the geometry. If I select auto loop, it only touches the outside of the "U" shape. I have yet to get manual selection to work- it's really tedious, and the couple times I've tried it's said it's an open loop and can't connect the edges.
 

Separate chamfer issue- maybe your fix mentioned above will correct it- but it's not just walls. In this case, trying to deburr (again, add a small 0.1mm edge break to the slot in the bottom) will run into the boss marked in yellow. This is one of the places where being able to adjust the start point would be helpful- normally what I do in these cases is to manually offset the start of the path to skip the area that's problematic.
 

Re lead-in/-out: This is more about options than operations that I saw that need it. There are lots of places where more control over the lead is required. Different leads for the lead-in and -out may be appropriate. Sometimes you want to lead in with a tangent line, not an arc. Sometimes you want an arc, but only 60 degrees, not 90.


New thing I just found: Pocket operation doesn't seem to respect the entry method for more than the first pass- you can see one helix entry, then a plunge on the outside pass. Doesn't seem to matter if I check the "keep tool down" box or not.
 
(this also illustrates a second thing I think is a bug- that green face is stuck highlighted, makes it hard to see the toolpaths)

And while I'm being picky... controlling the helix angle is important. Some tools choke at more than 1 degree, others are fine at 5 degrees.

OK, that wasn't that quick... but I'd like to end on a positive note here. Like I said in my initial post, I think the core looks really good here, and you're clearly dedicated to making things better. I really like to see that, and am optimistic you'll get there quickly.

Darrell wrote:

I had an old I5 pc that I am repurposing. I have an old GTX1070 I was trying to get to work with the RT kernel (fail), so the gcode preview wouldn't take so long to load with 5MB+ file sizes.. I get that users can run linuxcnc on PI and other micro controllers, but I thought I could just repurpose this old pc to do the job, and have some cool bigger "out of left field" features. haha
 

Nice. I also enjoy using capable 'almost out-of-date by today's standards' PCs. There's lots of them that run great on linux.
I'm pretty sure I have a couple GTX1070 GPUs around here, I don't recall having much trouble with them, but have not recently run LinuxCNC with RT kernel on one. I might have live-booted it at some point but don't remember how it went. I will certainly try it out soon and if I make any progress on that I will share here.

You mention my project, I assume you are referring to halflow? That one got pushed back lately due to other high priority projects eating all my time. When I get back to it, I want to do a major rewrite of it. My new idea is to spend a lot more time planning the structure before the coding starts. AI/llm all the way. I can read and write bash, python and C++ but AI is just faster.

On several different recent projects I spent literally days planning and refining the whole thing before the coding started. I produce a big detailed text file with help from chatgpt, with the build split into stages and finally give it to claude and basically say go. Of course, it ends up needing lots of follow-up and direction. It produced a more coherent build. Back when I started with halflow I had only a vague idea what the end result was supposed to look like, so I simply plunged into building and trying stuff, eventually it became something of a spaghetti program for lack of a solid plan structure. To date, I've refused to buy anything more than Claude/Chatgpt's entry level $20usd/month plans. When they block me saying my quota is used up I say time for a break.

NoSmoke wrote:

I'm starting a search for an older CNC vertical/knee mill for my home shop and thought I'd introduce myself and ask for advice before buying something.
What machines from this era are worth saving, and what should I inspect before buying?

Thanks in advance
 

It's really dependent on your location.

Some makes/models just aren't available in certain locations.  @tommylight's suggestion of a Maho is fine if you're in Europe, but not in the US.

You'll want to find something local - if not, the transport costs will likely double the cost of an old machine.

And location also dictates - to some extent - the electrical supply you have to work with.

Power, at least in the US, is the primary bottleneck for many home-machinists.  You can hire riggers, build a giant workshop, pour a thick concrete pad... but if you don't have enough amps to your house/location (or your breaker/service is near capacity) then it will be very expensive to upgrade your electrical system to handle a 3-phase converter.  In this case you might still be able to run a Bridgeport-ish sized mill, but you will have to budget for a phase converting VFD as well as single-phase servo drives.

So...

Location?
Budget?
Power availability?  (i.e. what phase/voltage/amps do you have - or can get w/in your budget?)
Maximum work envelope?

Hi @dbtayl, a follow-up on the chamfer point. You were right, and we've reproduced it.

When the edge you chamfer ends against a wall, the path runs the tool to the end of the edge, and the tool's side cuts into the wall. That was 3 mm with a 6 mm V-bit on our test part. Collision detection doesn't come into it: the chamfer path should never touch that wall in the first place.

While chasing it, we found a second issue in Mill Chamfer: the outside corners of an open chain of edges are cut up to 0.8 mm too deep. Closed loops (outer rims, pocket rims) are not affected by either.

Both are logged on our community hub. The fixes will be in the next update (1.0.8).

Thanks again. This is exactly the kind of report that makes the product better.

I’m also looking for a real machine for extended testing of the multi-channel system. It does not matter whether the machine still has the original drives.

Are you located in the US?  If so, I can help you find/obtain a really cheap machine for testing.  HGR Surplus typically has a number of obsolete swiss-type lathes for sale that can be had for essentially scrap value.

I'm only about an hour from HGR and can get eyes on any machine candidates if you're serious about acquiring hardware for testing.
 

If anyone is interested in testing the system, contributing, or discussing the architecture, I’d be happy to share more details, screenshots and videos.

I don't have a machine that's a perfect candidate for testing, but I do have a subspindle gang-tool lathe with a separate parting slide mounted to the headstock.  Both the slide - configured as either a V or X axis using switchkins - and the subspindle could be re-configured in a separate channel if that would be of any use to you.

Just to clarify, my sub is mounted on the X-slide and is intended to be used with tools (eventually) mounted next to the headstock for back-work. 

My operations are (will be) sequential, other than the parting and sub hand-off; it's not the textbook example of multi-channel like a swiss or sliding headstock.

I am not skilled enough to really help with coding, but if you can walk me through a configuration and GUI setup I'd be happy to try something.  Servos are step/dir with glass scale feedback.

And another thing... I struggled with LCNC's limitations on axis letters.  While my main spindle is also the C-axis, my sub is not defined as an axis despite being mechanically capable of it (servo driven). I'm not aware of any way to add axes beyond the standard 9 which also participate in the trajectory planner (i.e. not 'extra-joints').  I would rally have liked to name the sub "C2" or similar.  In your post you indicated 'C1' and 'C2' and that axes could be shifted between channels, but it's not clear how axes beyond the usual letters are named or handled.  I'd be interested in how you're addressing duplicate axis names - a basic swiss lathe capable of simultaneous sub work would need C1, X1, Z1 (main) and C2, X2, Z2 (sub).

As @tommylight said, this would be a monumental addition to LCNC.

djdelorie, the error idea is good, and it's the missing half of this. With a radius reference available, the state space for a rotary cutting move in G94 becomes:

G93 active: fine, inverse time.
G94 with a radius set (INI default or a G-code word): fine, surface feed.
G94 with no radius anywhere: today this silently runs deg/min, your "stupidly slow" case.

An opt-in INI guard makes state 3 a hard error instead of a slow wreck: "rotary feed move with no radius reference, add G93 or set a feed radius". Loud failure with the fix in the message, instead of finding out by watching the machine crawl. Every rotary machine then either runs a correct feed or refuses to run.

The guard alone is worth having even without the rest, since it catches the forgotten-G93 case you described, which the feed feature by itself doesn't. Cheap to implement, breaks nothing, machine builder opts in.
On "anything new is work and learning": agreed, which is why I'd keep the operator-facing part to one G-code word and let everything else default to today's behavior. The guard is the one piece aimed at operators, and its whole job is to say "stop, your program is missing something" instead of teaching them a new mode.

tuxcnc, on the Mach3 comparison I think you're aiming at the wrong part. The thing that's bad in Mach3's rotation radius DRO isn't the concept, it's that the radius is a value the operator types per stock and nothing in the program records it. That critique I fully agree with, and it's exactly why a G/M word carrying the radius in the file is the right mechanism, as you said: one file, reusable per diameter in a single program, unused by anyone who doesn't want it. Nothing to argue about there.

Where I disagree is "the same g-code should execute the same way on different machines". That was never true, in LinuxCNC or anywhere else. WRAPPED_ROTARY in the INI already changes what G0 A400 does. The default G64 tolerance, the G20/G21 default, startup codes, and above all the kinematics the machine builder picks, all change how the same file executes. G-code describes a toolpath relative to a machine definition; cross-machine portability has always been the post-processor's job, not the interpreter's. An opt-in INI value that no existing config sets is the same kind of contract as those knobs: unset means behavior identical to today, zero risk to twenty-year-old programs.

And it isn't Mach3 lineage. Siemens has FGREF for exactly this, settable from the program, which is an argument for your G-code form. Fanuc goes further in the direction you dislike: a parameter bit switches rotary feed from deg/min to length/min outright (1404#1 RFD, if I remember the number right). So both ends exist in serious industrial controls.

On "questions like who would like it are the wrong questions": I think asking is precisely the right first step. A project like this stays alive for 20 years because the people building it keep an ear on what users actually need, and because users see that asking can lead somewhere. "Devs build whatever comes to mind, users take it or leave it" is the model that slowly empties a user base. A quick census before sinking weeks into a feature isn't design-by-committee, it's just checking that the work lands with someone. Nobody is bound by the answers; I'll weigh the design on its merits, this thread included.
Net result of the thread so far, the way I read it: G93 covers the CAM crowd, hand-writers would take a G-code word for the radius, and whatever lands must not change behavior on any existing config. That's a useful outcome for a few days of asking.

I will suggest another option... An INI setting that causes any A motion other than a rapid to be an error, in G94 mode, or perhaps a pop-up warning.
A G94.1 mode for "It's G94 but use the X/Y/Z in the INI as the rotary center for calculations" would be nice, but anything "new" is work and learning for operators.
 

Danke Juergen, wir werden es uns ansehen.

Hi @dbtayl. Thank you for the observations. Here are some thoughts on the ODD and Bad.

The Odd

1) Both Z43 and Mouse behaviour can be set in preferences.
2) Updates will be available for upto 24 months from a product launch. After that the product works as is forever. We expect to release a new product that keeps up with changes in OS and tech. You can continue using the old one forever.
3) We use Paddle - a UK based MOR. We are adding Paypal directly to the options soon to make it easier.
4) Let us know if you face any specific bugs and we can address it. We have a community hub website. We track all bugs live there and currently the queue is clean.

The Bad

1) Yes you can, the op specific parameters allow you to choose between sihouette and Bounding box
2) We will refine the strategy in the coming weeks. Thank you for the input
3) Understood, this is a likely bug where the face picker may be masking the edge picker. We will investigate and fix
4) Ramps for pocket is scheduled as a 1.0.10 update. About 3 weeks out from today.
5) Yes, we limited it to the operations we thought needed it. Can you kindly tell us which other ops you find it useful and missing
6) Our website states that collision detection is available only for 3D Ops and Complex Rotary Ops. Never oversold. If some literature miscommunicated the same, kindly let us know.
7) We have pick start in the op config section for the ops that we thought needed it. Once again, if you can help us identify other ops you think qualify for it, we'd be happy to take a look at it.

Your comment on AFR being a hit or miss is especially worrying to us as this is the first time we received this as feedback. All other customers are very happy with it and have not reported any false positives yet. Can you tell us how bad the miss was?

In process stock is scheduled for 1.0.12, which is about 5 weeks off.

Overall we thank you for an unbiased critical view of our app and we are certain we can improve all of these to meet your expectations.

 

First of all, GIGO, i.e. processing incorrect data, gives incorrect results.
You can also say that if you ask the wrong question, all the answers will be wrong...
Questions like who would like to do it and whether to do it are the wrong questions, especially when asking a small and non-representative group of a few active users of this forum.

The real question is: HOW NOT TO DO THIS?

And here we know the right answer - NOT like in Mach3.
Mach3 is commercial software, which means that nothing is done to make it work good, but to make the users like it, because the company's income depends on the users' satisfaction.

It works differently in free software - if someone has the time and inclination, they add a new utility, and if someone doesn't like it, they don't use it.
The only problem here is not to break anything and not to let a program with a twenty-year history suddenly start working in a way that is unpredictable for the user.

But let's get back to Mach3.
I don't have the time or inclination to look for better examples, but what I quickly found is completely enough. Here is one of the many screens for changing Mach3 settings:

Notice the "G04 dwell ms" entry in the upper right corner.
The way it works is that depending on whether this item is selected or deselected, the G04 code is interpreted in a different way. There is no need to explain the difference between 3 seconds and 3 milliseconds, and the g-code author may have no idea how his code will be executed.
Let's ignore the sobbing of the operator when his disk goes bad and he has to recreate all the windows and buttons, because that would be offtopic.
The utility we are talking about here is implemented in Mach3. AI writes about it this way:Basically everything is true.
Let's not do the same in LinuxCNC.
The definition of g-code is that it is a description of the tool path and let's stick to it.
The same g-code should be executed in the same way on different machines, and not on each machine differently because the operator changed something in settings...

I think the A 0.000 should align right with the numbers above Z-10,000, where the last two zeros are on top of each other, maybe the dtgs could get a slightly less bright red to distinguish them more visibly.

Not sure why A and B needs the smaller text size, but looks ok.

You are removing information though, the Abs might deserve a switch, maybe on click/tap? maybe with some kind of hint, clicking on dtg changes it to abs?

Food for thoughts, not implementation requests