Differnt UCCNC moduals as seperate versions

[cncdrive]

My opinion is a strong no.
Reasoning: A screenset and associated macros can separate different functionalities required for the different machine types.
The rest is g-codes which the user can select what to use and what's not for his machine and his jobs.

[cncdrive]

OK, but different screensets could separate them. Then there is no need to make and maintain several different core codes.

[cncdrive]

But UCCNC does not support lathe, so it is not an issue yet.

[extent]

Would removing everything that is NOT needed make teh Program more stable over time.

Only if you are completely abandoning development of the mill functions. You could create a stripped down version, but all you've actually accomplished in that case is created a larger overall codebase (with all 3 individual cores) with more redundant code that needs to be maintained, increasing the overall complexity and increasing the likelihood of bugs. The benefits in reducing maintenance complexity far outweigh any possible gains from unrolling to separate cores.

I'm not even sure what gains you would expect to see, it's not like the path planning for a laser is any different than the path planning for a mill. 90% of the features called out are, as mentioned, just a matter of screen set, and otherwise have 0 overhead when not in use.

And if you're happy with a simpler feature set then why not just use what's released now and never update it again? Once you have a release that's feature complete for the mode you're using there's nothing that says you have to update the software constantly. You can do the "run for a long time without futher functions added" thing yourself literally any time you want to.

[ger21]

Do any of the controls you are talking about cost $60?

What hobby level software controls have individual modules for each different application?

Yes, separate applications for each type of machine would be preferable, especially when it comes to lathe, but it's not a viable option at this price point. If you were paying $500 for the software, then that's a different story.

Why aren't you using any of these commercial controllers, if they are so much better?

[extent]

https://www.fanuc.eu/si/en/cnc/controls ... rol-series

I don't see any machine class controls listed at all (on the contrary they control all manner of cnc machines, and loaders, and robots) they differentiate mainly on number of axis controlled, number of simultaneous movement axis, and other advanced features.

https://www.siemens.com/global/en/home/ ... stems.html

Siemens only seems to differentiate by holding back grinding for the more advanced controls, but all models handle mill/turn. One of their major selling points is actually that all the controls use the same SINUMERIK CNC kernel that allows you to run offline simulation and setup for any machine running their control with one package.

If you're talking about the random crap chinese control boxes that you can get on ebay or ali then those are largely differentiated by what physical hardware they have, and you really don't have a way to know what the software running in them is capable of. Very likely they're all running the same code base within each brand, just with different features enabled or disabled in software. Just like the bluetooth DRO that I have on my lathe, I have the source code for the firmware, and I know that it supports spindle index pulse sensing, but the box that it came in doesn't have any of the circuitry for pulse sensing, so that feature just doesn't show up, even though all of the source code is the same for it.

Everything in one massive code base is far better and far easier. Every bit of shared code you can have is less work that you have to do, because fixes you can make once and they apply to every possible "module" If you have even a single bug in a split module thing you've instantly multiplied the amount of work it takes to fix by the number of unique products you have, and probably even more if you have diverging code bases where a simple fix in one moduleized version becomes a complicated fix in other modules.

It may be hard to understand if you've never dealt with any large codebases yourself, but the answer to all of your questions is a firm and unqualified "No",
except for the last question to which I'd shrug and say "Maybe?"

[Derek]

I'm going to weigh in here even though I'm no programer. Having modules may mean more work for the programers but less risk for the users. Right now making a change to something that is for plasma only can break something in mill. I have personally experienced this. Also the reason I spotted it is because I'm doing things with my machines that others don't. It wasn't like when I started UCCNC it kicked up a warning. No it showed up running code and macros on a machine that I had run thousands and thousands of times. Because the plasma fix was rolled into a fix I was interested in I only paid attention to the fix that pertained to the mill.

Modules would put the testing onus on those that are using the module. I would prefer that a change that is pertinent to plasma only would be part of a separate module. I'm sure plasma users would be pissed if a change to tapping caused the plasma head to dive into the work.

I'm also going to admit the problem is people like me who are using a hobby system to do professional work. Yes it can do a lot things but it is a $60.00 program. How much development can possibly go into 60.00 software? Like Mach it does most basic 3 axis operations extremely well. But when you get into more complex demands things start to get a little wonky.

[asuratman]

When will 4th axis rotary program be available ? What will be developed after cnc mill/router ? CNC turning ?

[cncdrive]

You can already do rotary work with the UCCNC: https://www.youtube.com/watch?v=Ox4SrYt-qEY

We have no short term plans for lathe support.