LatheEasyStep – experimental QtVCP macro for step-by-step lathe programming

NativeCAM is an interesting project, but it has a fundamental issue today:the codebase is very old (Python 2, GTK2/PyGTK) and has not been actively maintained for quite some time. I have taken a closer look at the project locally and am currently trying to get it running on a modern system (Debian 13, Python 3, LinuxCNC 2.10). At the moment it already fails at the basic dependency level, since Python 2 and PyGTK are essentially unavailable on current distributions. Before discussing any functional extensions, a significant porting effort is required (Python 3, GTK3/gi).Only if NativeCAM can be made stable on a modern system does it make sense to consider whether and how the lathe functionality could be extended or reimplemented. For now, my focus is not on new features, but solely on determining whether the project is still technically viable as a future foundation.

There is a version of nativecam in a linuxcnc branch that mostly works.
It's a work in very slow progress. It's based on Qt.
github.com/LinuxCNC/linuxcnc/tree/qt_ncam

There is also another project I've seem on the forum that keeps it gtk based and just updates it to python3 and whatever pygtk is called now.

But I would suggest you just finish what you have built, as it seems you are pretty far along.
You could always convert it to another platform later.

Hi everyone,

I’d like to give a short status update on LatheEasyStep, mainly to clarify what has changed recently and what my current focus is.

 What has changed

1. Interactive legend in the preview

The preview now includes an interactive legend.

The title “Legend” is always visible and acts as a permanent click area.

Clicking on it toggles the legend collapsed / expanded.

When collapsed, only the header remains visible so the legend can always be reopened.

The legend affects visualization only, not geometry calculation or toolpath logic.

2. Improved preview with safety areas

The preview now clearly distinguishes different geometry and safety elements:

Green (solid): contour / target geometry

Yellow (solid): active machining path

Grey (dashed): stock outline

Cyan (dashed): retract planes (XRA/XRI/ZRA/ZRI)

Red (dashed): machining / safety limit (e.g. ZB)

Safety limit violations are highlighted visually.

Stock and retract planes are drawn based on the actual configured parameters, not approximations.

3. Facing – chamfer or radius at the end

In the Facing tab it is now possible to define an optional chamfer or radius at the outer end of the facing operation.

Supported options:

None

Chamfer

Radius

This affects both the preview geometry and the generated toolpath.

All of these changes are documented in the README, in both German and English.

 Current focus: the preview

Right now, my main focus is the preview system.

The goal is to make sure that:

geometry is displayed correctly,

safety and retract areas are clearly understandable,

and the preview can be trusted as a visual plausibility and collision-check aid.

Once the preview side is solid and stable, I’ll move on to the fine-tuning of the actual machining / stock removal functions and further logic improvements.

 Next steps

Further testing and stabilization of the preview

Real-world test cases with complete programs

UI adjustments if needed

After that: refinement and extension of machining features

Hi,

thanks a lot for the update. I’m always happy to see new progress in this thread!

Also thanks for the screenshots, everything is looking very promising.I noticed that you’re writing the manual in German as well, so I assume you’re German too.

If you’re interested in chatting "in real time" in German with like-minded people, there’s a German-speaking Discord from Peter aka Talla83. You’ll find many LinuxCNC users there, including quite a few lathe users. If you’re ever looking for feedback or beta testers, that could be a good place to connect.

Of course, this is only meant as an addition, please definitely keep posting updates here as well. If you are interested, here is a Discord server invite link: discord.gg/dPBgNR3t

Best regards

Tom

The current state focuses on contour machining and the related LinuxCNC cycles.Contour (CONTOUR) is defined purely as geometry (lines, chamfers, radii, inner/outer).
Different operations can then be derived from this geometry, independent of their order in the workflow.Currently implemented:

• Drilling using LinuxCNC cycles G81–G84 (including G82 with dwell, G83/G73 peck drilling, G84 tapping)
  • cycle-specific parameters are shown dynamically
  • internal correct switching to
    Code:

    G17
    , followed by
    Code:

    G80
    and back to
    Code:

    G18
• Roughing of contours
  • use of G71/G72 if the contour is monotonic
  • automatic fallback to move-based machining for non-suitable contours
• Finishing of the same contour as a separate step

All operations reference the same contour geometry but are processed as logically separate steps.G-code generation (current logic):

• Before every tool change, the machine always moves to a defined G53 tool change position
• Definition of an explicit safe area (
  Code:

  X_safe
  ,
  Code:

  Z_safe
  ) derived from stock geometry and retract planes
• After each cutting step:
  • retract in X first
  • then retract in Z (no combined retract moves)
• Approach from the safe area may be diagonal
• Coolant (
  Code:

  M7/M8/M9
  ) is set explicitly per operation
• Comments are sanitized (no nested parentheses)

The preview is directly based on the geometry:

• true arcs for radii
• separate visualization of contour, stock, toolpaths, retract planes, and safety limits
• visual highlighting when machining or safety limits are exceeded

A reworked README describes the current feature set, safety logic, and G-code strategies in detail.
Screenshots will follow in the next few days.
The current state will also be published on GitHub in the coming days.Additionally, a test file ( ) is attached, reflecting the current state of the generated G-code.

I tried loading this in master and came up with an error message.

[QTvcp.QTVCP.QT_MAKEGUI][ERROR] Easystep: Trouble looking for handlers in 'lathe_easystep_handler': (qt_makegui.py:469)
Traceback (most recent call last):
File "/home/chris/emc/lib/python/qtvcp/qt_makegui.py", line 446, in _load_handlers
objlist = h(halcomp, widgets, self.PATHS) # this sets the handler class signature
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 7101, in get_handlers
return [HandlerClass(halcomp, widgets, paths)]
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 3038, in __init__
self._connect_signals()
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 4468, in _connect_signals
self.list_ops.currentRowChanged.connect(self._handle_selection_change)
AttributeError: 'QWidget' object has no attribute 'currentRowChanged'

I didn't look into why.

I did switch to 2.9 and it seems to work, but I haven't figured out how to use it yet