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
Here are some older ideas pages for inspiration:
- 1. Linux Distribution
- 1.1. Evaluate for stability and usability
- 1.2. Core LinuxCNC running headless
- 1.3. Allow HAL to run stand-alone
- 1.4. Repackage Linuxcnc
3. Programming Languages
- 2.1. Code Overview
- 2.2. A plan
- 3.1. Consider limiting languages
- 3.2. Well Defined API
5. GUI / User Interface
- 4.1. Some simple logic in HAL
- 4.2. Interlock control pin
- 4.3. Allow multiple instances of all RT modules
- 4.4. HAL netlist visualizer/editor
- 4.5. HAL support for shared/common resources (I/O Bus)
- 4.6. support absolute / distance coded encoders for homing
6. Trajectory Planner
- 5.1. Widget Toolkits
- 5.2. Remote Multi-platform GUI
- 5.3. One HALUI type program that all GUIs talk to
- 6.1. n line Look-ahead
- 6.2. Control consideration for special machines
- 7.1. loadable interpreter
- 7.2. Mirrored axis for lathe
- 7.3. Better Error Message System
- 7.4. Support for Swiss Lathes.
- 7.5. Support for multitturret / multispindle Lathes.
- 7.6. Allow tool changes in manual mode
- 8.1. Have the spindle be considered a special axis and optional.
- 8.2. Joints vs axes go mainstream.
- 8.3. INI config file: support for inline comments.
- 9.1. Appliance Mode
- 9.2. Network Appliance
- 9.3. Parts Packing
- 9.4. Multi-Tool heads
- 9.5. Wizards
- 9.6. Cutting simulation
- 9.7. Dry-Run Simulation
- 9.8. Wiki software/markup
- 9.9. Build system
- 9.10. Tool Management Hooks
- 9.11. Doxygen documentation
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.
1.3. Allow HAL to run stand-alone
Decouple HAL from Linuxcnc so it can be used as a general purpose control system.
1.4. Repackage Linuxcnc
Repackage Linuxcnc into smaller individually installable packages, some of which already exist. Individual packages might include:
- CNC Control
- Device Drivers
- Classic Ladder
- User Interfaces
- Example configurations
- Example NC Files
Ideally a meta-package would then enable installing of the desired individual packages.
2.1. Code Overview
We badly need up-to-date code overview and visual flow chart.
A rough table of contents of the source code folders would be extra helpful too. CMorley
2.2. A plan
A rough plan of where we would like to go, and what our underlying vision is, would help us move forward with focus
3. Programming Languages
3.1. Consider limiting languages
Do we need more the C C++ and Python?
Should we go with PYObject right away? -CMorley
3.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.
4.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
4.2. Interlock control pin
At the moment we have motion-feed-hold which can be made to work in most circumstances, but it can be masked.
We need a non-mask-able feed hold as well.
Also an interlock pin(s) that would actually cause an error massage without estop/machine-off would be useful too. eg 'Can't start spindle when chuck open' CMorley
4.3. 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.4. HAL netlist visualizer/editor
A tool that allows viewing HAL netlists and/or editing the graphically.
The HAL-file(s) provide the required netlist, but an additional help for visualizing the netlist could
be included as comments in the HAL file.
See work by Kent A. Reed https://sites.google.com/site/manisbutareed/visualizing-emc2-configurations
4.5. HAL support for shared/common resources (I/O Bus)
It would be great if HAL could gracefully support handling of shared resources when communicating with low-level chips (I2C, SPI, serial, etc). Especially with I2C and SPI, there is usually a chunk of common hardware shared between more than one component, which makes it difficult to support more than one device in the current HAL.
4.6. support absolute / distance coded encoders for homing
This requires changes to motion module too - I have Heidenhain encoders that give distance coded indexes that could be used to home by moving a small distance anywhere.
Since motion only resets the reference point to zero rather then to an arbitrary absolute position I can't use it even if the encoder module understood how.
Some commercial machines have absolute encoders, it's not clear to me how to use them as linuxcnc expects homing.
5. GUI / User Interface
5.1. Widget Toolkits
Drop Tkinter, migrate to GTK3, consider QT4 -CMorley
5.2. Remote Multi-platform GUI
Remote network based GUI targeting platforms including various flavors of Linux (DEBs, RPMs, Android), Windows and iOS.
5.3. One HALUI type program that all GUIs talk to
If the GUIs messaged to a HALUI type program and vice versa then the HAL interface for each GUI would be much more common.
Right now each GUI makes it's own HAL pins which makes switching GUI difficult and having networked GUI's more challenging CMorley
6. Trajectory Planner
6.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.
6.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
7.1. loadable interpreter
modularised so one could load a conversational interpreter or stand alone or whatever-CMorley
7.2. Mirrored axis for lathe
I have an Okuma lathe with a front and rear turret. It originally had a mirror function for the back turret.
it reversed the axis direction controls, reversed the spindle direction controls and had a different tool offset reference
7.3. Better Error Message System
It would be nice for the GUI to be able to erase error messages when the are fixed rather then asking the operator to clear them CMorley
Messages about being on limits for example should cleared when the machine is off the limits
7.4. Support for Swiss Lathes.
Support for programming independent movement of axis (or joints).-VNR
7.5. Support for multitturret / multispindle Lathes.
Support for programming independent "set of axis".-VNR
7.6. Allow tool changes in manual mode
Right now the machine must be homed and a MDI command must be sent to index the tool.
Some machines (lathes) can tool chaange anywhere so this is an annoying restriction.
8.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
8.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. -Viesturs
8.3. INI config file: support for inline comments.
Support for: VARIABLE = value #valid comment
Actually is (example from INI config manual):
INCORRECT = value # and a comment
# Correct Comment
CORRECT = value
9.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.
9.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.
9.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.
Awallin comment: I believe this is called "Nesting" in the literature. There may be an opportunity to use OpenVoronoi for this but I have not had time to look at it yet.
9.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? -Viesturs
There are many wizards for gcode and such but not under one umbrella no standard API nor many in the repository.
GWIZ was started but has bit rotted a bit but what a great idea CMorley
Isn't NGCGUI the place, where some/most of them have been gathered? -Viesturs
GWIZ was a frame work for incorporating gcode-making-programs into one screen. - The key word being framework
9.6. Cutting simulation
Cutting simulation where a virtual workpiece is cut using G-code. This requires the tooltable to contain sufficient information on the geometry of the tool (only diameter is now stored?). The existing interpreter can be used. An OpenGL?
viewport with sufficient speed for rendering vertex-buffer-objects or a similar data-structure is required. For ease of use the GUI should be made similar to AXIS.
This should require only a simulator build of linuxcnc, not real-time.
If This was a gladeVCP widget then it could be embedded into any operator screen. CMorley
check out openscam: http://openscam.com/
9.7. Dry-Run Simulation
Allow even a realtime machine to run the program on screen without the machine moving, to help verify a program. maybe with selectable running speeds CMorley
9.8. Wiki software/markup
The de-facto wiki standard is what wikipedia uses, MediaWiki?
. Use that.
9.9. Build system
Raw makefiles should be a thing of the past. There are many alternatives but I would look at cmake or maybe a python-based alternative to make.
9.10. Tool Management Hooks
Commercial machines can keep track of number of parts per tool, total feed time on tool and set limits on motor load while using a tool.
If the first two are kept track in the tool table operator could take note and reset it when the tool is indexed etc. CMorley
9.11. Doxygen documentation
Doxygen is a tool that builds HTML documentation from the source-code and specially formatted comments in the code.
Some source-files of linuxcnc already seem to have doxygen-style comments.