I've never moved anything in a forum before, how do I do that?

This should be moved to the Qtvcp section.
Looks promising! Keep is updated! If you get stumped with the programming i can try to help.

I don't know about the file size @scotta ?
But scotta made the beta to try and solve my CSS problem. I still have no solution. If you have the RT1052 controller. Let me know if you can get the CSS working on your build.

Repository:
github.com/peter-pan08/LatheEasyStep LatheEasyStep is an experimental QtVCP panel for LinuxCNC that enables step-by-step conversational lathe programming directly at the machine — without external CAM software.The goal is fast, safe, and practical programming for typical workshop jobs.PurposeLatheEasyStep is designed for:

• Programming simple to medium turning operations directly at the machine
• Repetitive standard jobs (facing, contouring, grooving, drilling, threading, roughing)
• A workflow-focused approach:
  Enter parameters → Verify preview → Generate G-code

It aims to bring an industrial-style conversational workflow to LinuxCNC.Current Feature SetProgram Structure

• Program header with stock/workpiece parameters
  (diameters, lengths, units, safety values)
• Step-based program building with sortable operation list
• Save/load for single steps and full programs
• Bilingual UI (DE/EN)

Supported Operations

• Facing
• Contour
• Groove / parting-style operations
• Drilling
• Threading
• Roughing (material removal)
• Keyway (macro-based)

Preview & Visualization

• Live X/Z preview including reference geometry
• Dedicated chuck safety zone visualization (color-coded with legend)

Safety & Motion Logic (Core Focus)

• Context-aware retract/free-travel behavior per operation
• Material-aware retract decisions
• Extended chuck / no-go safety parameters:
  • Chuck size
  • Workpiece type
  • Clamping mode
  • Chuck profile
• Machine/workshop profile presets for faster setup

Project Status

• Experimental
• Actively developed
• Designed for real machine workflows
• Iterative improvements based on practical use

Known Limitations

• Not a full CAM replacement
• Complex freeform geometry is intentionally limited
• Machine-specific adaptation may be required

Target Direction

• Fast conversational programming at the machine
• Clear and understandable geometry visualization
• Safer default behavior for common turning tasks
• Continuous refinement driven by community feedback

Feedback WelcomeIf you test it, helpful reports include:

• Brief machine/configuration info
• Reproducible steps
• Expected vs. actual behavior
• Optional screenshots, preview images, or G-code snippets

 

Hi All, 
At some point the S-code could be used to command the spindle speed. The control sends an analog voltage to the LARRIOZ speed control card. The card reads a sensor that counts spindle revolutions and compares it to the commanded speed. The card can then switch relays, that in turn switch the contactors driving the motorized CVT transmission between spindle and spindle motor to increase/ decrease the spindle speed as required.
 
This never worked since I got the mill. I did at the time try to get it to work, but due to lack of knowledge and/ or documentation, I could not get working. I would think that the lithium battery in the Dallas non-volatile SRAM would be long gone, but I am not sure what would be stored in SRAM. I assume (While I know not to assume anything) that the firmware would live on the EPROM and the SRAM might hold parameters relating to the specific installation. Other than JP 1(Jumper), and P1 (Potentiometer) there is no other configuration or programming port on the LARRIOZ HABIKON1 board.
Although slow, I prefer this system, as I would not sacrifice low speed torque, as would be the case with using only a VFD for speed control.
I suppose it would be fairly easy with modern microcontrollers to get the system going again, but I would be happy to hear from others as to their experience or suggestions as to how I should proceed.
Regards
P
 

It would probably be a good idea to add MaHa's G10 solution to your startup code..

endian wrote:

Did anybody get it to run with Rods guide??

E.

I don't think it works.  The master is meant to sense if of EoE is available but 2 things collide.
1. There is a bug affecting this drive in the ethercat master
2. the Linuxcnc  driver does not support EoE

I think without the bug it should fall back to supporting non-EoE mode but its a long time since I looked at this.

Does joint.N.amp-fault-in actually turn the machine off? I'm not sure it does. I know it stops motion. My thinking is that conce you have the machine dialed in you will never get this error.

Aahh shoot! I was hoping to avoid resoldering my DIY pullup resistor board. But thank you for the explanation.

Hello, I was trying to change the bitfile in my 7c81 so that there would be only one 7i78 on port P1. Port P2 would be freed up for separate MPGs for X and Z axes. So there would be no need for 7i33 (which would probably be another complication I wouldn't go through). But in the Mesa firmware there is no 7i78x2 configuration, nor 7i78 for Xilinx ISE (*.xise). Is it possible to download this configuration somewhere else?

Good morning, I have looked at the code now. Clear out the whole loop() function and insert just this line

That should do it. You never called ecat_slv() in cyclous mode.
The danger of using someone else's code.
It meant it never used spi to query lan9252 for changes and updates to register etc etc.

There were a lot of diagnozing and trouble-shooting with the I2C so I wanted an easy way
to run the board as a normal aurduino without the ethercat things. It was required to define ECAT
during compile for it to be an ecat device. Now that is gone, so remove all of that.

Fastfred wrote:

 I will try to figure this out my apologies That I haven't picked up on this yet.
 

No worries, you'll get through this even if you feel like you're lost now.

Takes a while for HAL to sink in - it did for me.