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
If you want know how to add information to this page, follow some BasicSteps.

1. Linux Distribution

1.1. Evaluate for stability and usability

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

5. Trajectory Planner

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?

2. Programming Languages

2.1. Consider limiting languages

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

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

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

5. Trajectory Planner

6. Interpreter

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.
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.

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?