Here is a page to document ideas for linuxcnc 3

From time to time I think of an idea that I think is important to discuss/plan for.
It's much easier to plan the infrastructure for a feature in the future if it's written down for reference,
It's my thought this could be a reference for discussion else where.
Please add your 2 cents worth here. - feel free to add another heading if required
Adding you name at the end could help a developer to follow up with questions, but is not necessary.
If you want know how to add information to this page, follow some BasicSteps.

1. Linux Distribution

1.1. Evaluate for stability and usability

1.2. Core LinuxCNC running headless

2. Programming Languages

2.1. Consider limiting languages

2.2. Well Defined API

3. HAL

3.1. Some simple logic in HAL

3.2. Allow multiple instances of all RT modules

4. GUI / User Interface

4.1. Widget Toolkits

4.2. Remote Multi-platform GUI

5. Trajectory Planner

5.1. n line Look-ahead

5.2. Control consideration for special machines

6. Interpreter

7. Configuration

7.1. Have the spindle be considered a special axis and optional.

7.2. Joints vs axes go mainstream.

8. Other

8.1. Appliance Mode

8.2. Network Appliance

8.3. Parts Packing

8.4. Multi-Tool heads

1. Linux Distribution

1.1. Evaluate for stability and usability

Ubuntu seem to moving away from a desktop that is usable for serious work.
Others such as Mint have the right philosophy about usability yet are still modern and updated regularly
What is it that is important to use? -CMorley

1.2. Core LinuxCNC running headless

Allow the core LinuxCNC functions (HAL, interpreter, trajectory planner, etc.) to run headless on a server install of the desired flavor of Linux.

2. Programming Languages

2.1. Consider limiting languages

Do we need more the C C++ and Python?
Should we go with PYObject right away? -CMorley

2.2. Well Defined API

Add well defined API, so other 'outside' languages can support access themselves, and core LinuxCNC can support a more limited set to keep development overhead down.

3. HAL

3.1. Some simple logic in HAL

Having a component that could decide on a action based on the pass/fail of loading another could be useful
For example if a USB joystick is present then HAL loads the pins for it otherwise it skips them - CMorley

3.2. Allow multiple instances of all RT modules

Currently, only one instance of motion and kinematics modules may be loaded in a linuxcnc session.
For machines with multiple "tool points", such as multiturret lathes or multihead pick and place
machines, this would make the difference between one PC for a machine and multiple PC's for a single
machine. The hostmot2 module and Mesa hardware permits plenty of axes, but we are currently limited
to six axes controlling a single tool point by allowing only a single instance of motion and kins.

4. GUI / User Interface

4.1. Widget Toolkits

Drop Tkinter, migrate to GTK3, consider QT4 -CMorley

4.2. Remote Multi-platform GUI

Remote network based GUI targeting platforms including various flavors of Linux (DEBs, RPMs, Android), Windows and iOS.

5. Trajectory Planner

5.1. n line Look-ahead

Option to remove the stop at end of next line limit and read ahead more lines. Make it be able to stop by the end of the last line read, or the end of the cut (next G0). Maybe allow the end user to choose the number of lines read ahead to tune performance for their system.

5.2. Control consideration for special machines

A common machine that has problems with this is laser control. using spindle or a regular axis seems to be sub optimal
What about EDM machines that need the control to back off and re-enter on the same line
some sort of 'feed to start point' incorporated with run-from-line would be useful for restarting torches and plasma-CMorley

6. Interpreter

modularised so one could load a conversational interpreter or stand alone or whatever-CMorley

7. Configuration

7.1. Have the spindle be considered a special axis and optional.

Not all machines have spindles. It would be nice if the spindle had acceleration and velocity limits specified in the INI file, like other axes.
A minimum and maximum RPM limit set in the INI that the planner honours would be useful for VFD's with minimum speed requirements.
Is it possible to have the spindle control as a module then you could have special modules for gear changes and hand-off hooks to the C axis. -CMorley

7.2. Joints vs axes go mainstream.

Version 3 would be the right place to merge joints_axes branch with master. I just am not sure, how mature that branch is, but, considering that Yishin's company based their modifications of LinuxCNC (implemented s-curve velocity profile and other things) on this branch, it seems to be ready.

8. Other

8.1. Appliance Mode

Separate 'cut down' versions for ladder logic and CNC mode for simple 3 or 4 motor 3 axis machines. The RepRap/Makerbot? communities have done this for some FDM (Filament Deposited Material) application uses. These would be focused on 'small' implementations (like on Arduino Mega, RaspberryPi or similar without having a 'support computer' attached or with USB only type of attachment. Yes, some of this is being done as separate projects, but rolling them into the mix as supported optional versions (hopefully supported with compile time flags, etc) could help proliferation of LinuxCNC as the backbone CNC support.

Might consider rolling in some of the interface type support like Makerbot community has started using. (limited display with few buttons and jog wheel type support when driving device locally or from USB card. -- In some ways I like the idea of one to several 'projects' or 'parts' files on a USB card for common or 'cut on demand' parts.

Having a few 'reference designs for embedded controllers' would be great for setting standard of one or two ways to implement appliance mode on small (cheap) devices.

8.2. Network Appliance

Have a 'directory' where a part could be downloaded over a network interface, and a 'perform action' file could be downloaded to the same place. This would put 'parts' in a queue to be made. One 'perform action' file per part to be made. Having a few 'reference designs for networked controllers' would be great for setting standard of one or two ways to implement appliance mode on small (cheap) devices.

8.3. Parts Packing

Allow for automatic parts making optimization, either in a pre-processing mode or with separate OSS utility (that I am not aware of currently), where kerf size, grain direction, etc, could be automated to get higher yield out of materials. I am thinking mainly of cutting with router/spindle or metal cutting torch or laser cutting or water jet type applications.

8.4. Multi-Tool heads

Having a router or spindle with other 'heads' on the same 'head' is used by some, but they each need to be used independently like separate tools. I could see on 'device' having a router, a drill (think of shelf holes), and a engraving head or other marking device all on the same Y carriage. each would have a separate but attached origin. Once set up they might be dealt with as different 'bits' on the same 'head', but the separate origin issues might need to be addressed in HAL and elsewhere.

Regarding multiple tool heads - do we have support for multiple separate tool change mechanisms?