This might be the point where I can give my software-expertise to this project

I wrote some software which simulates the spindle control behavior based on the files uploaded here 17.5.2026. I have very little understanding of actual linuxcnc, so take everything with a grain of salt. The simulator is quite crude and it's translated in python, as I do not have access to a physical LinuxCNC machine for now. I'll need some confirmation that it somehow resembles the actual behavior of the Schaublin now before I dig in further. It does look like that the pid works "ok'ish" on low gear, only a minor overshoot, but it's way off on high gear. There's some possibility that the simulator could be useful when developing a state of the art control. I would also say that no extra hardware is needed, many things can be deducted from the spindle speed, cvt end switches and the motor hz.

The thingy is now there, I did not spend too much time on it, it's also mainly vibe-coded. The translation of the .comp logic is in spindle_supervisor_model.py lines 161:582

github.com/heff3/schaublin-cvt-simulator

Easiest way to get it working is to use "uv", it's a modern python virtual environment manager (does not break your machine). AI will help with this one, but on mac the most convenient way is with "brew install uv". Brew is the most common package manager for osx.

After cloning the repository, one should be able to:
uv run python spindle_realtime_simulator.py

q - quits the application (or the usual ctrl+c)
space - starts the motor
k / j - tunes the target spindle rpm


The simulator behaves better once it has run awhile with a few toggles on/off, dunno if the real lathe behaves the same?

ALERT: The real lathe might have insufficient max rpm limit now. For example if one targets 2000rpm, the pid might overshoot it quite a lot.

The trajectory of what gcode file of the maximum size can be visualized with acceptable performance? Or I’ll ask differently: how many segments are the maximum?

I was making a similar interface and ran into browser limitations in terms of memory, etc.

No response.
So, is what I am trying to do possible.
I want to jog the machine in X-Y-Z using an analog joystick with gmoccapy as the frontend with the jog speed dynamic based on the joystick position.

Anticipate only allowing jogging when in the jog menu of gmoccapay.

Also of note when I am jogging using the jog buttons in gmoccapy and move the joystick the jogging stops. Is there a conflict between gmoccapy and the analog controls. 

Hi Rod. Since the back gear is only switched when stationary, there is no need for such feedback. logging the command is enough. Sanity check once the spindle turns and you can see the overall ratio.

Is there another area that discusses Mesa boards and setting them up

Let me preface this with I am very new to LinuxCNC, Ethercat, and CNCs in general. However, in hopes to help someone else out and maybe keep them interested in getting LinuxCNC working for their CNC I wanted to share my very basic setup files for the Lichaun CL57E-4A 4 axis Ethercat closed looped stepper motor driver. I think these files would be similar to what would be needed for the Lichaun OL57E? I searched the forums for the past few weeks but could not find any working examples for the Lichaun CL57E, (I might just be bad at searching the forum haha). I followed MrRodW's fantastic YouTube tutorial video on how to get all the main Ethercat setup complete and I am using an old HP Elitedesk 800 G1 DM PC, and its built in Ethernet port to run my LinuxCNC setup.

Attached is a very basic Ethercat xml configuration file, that I created with the "lcec_configgen" tool and then I filled in the missing parts by referencing the attached "pdos" and "sdos" files. Also attached are the hal and ini files. With the three files "cl57e-ethercat-conf.xml", "cl57e.hal", "cl57e.ini" a LinuxCNC config can be created and ran, which should in turn allow you to move all four axes. These files are very basic and will need more to get the CNC really going but it is always nice to see the motor move when you tell them too.

Is it possible that there is a grounding issue?

Did the original system use a tachometer?

If so , it would be floating which may be a requirement of the drives input circuit

The runaway only happens when I add a small amount of gain to P.

I've backed up a little to triple check that I have both outputs scaled and the correct directions. The original Fanuc manuals show the test points and expected scales of the input signals for the drives. 

The machine moves 0.2362 inches per revolution and the encoders have 2000 pulses/rev. I used that to calculate an encoder scale which does need to be negative to make the DRO move the correct direction. I then calculated the ratios to get the inches per second of movement that should equate to 10V for both the velocity command and tachometer.

Next I wanted to measure the actual values at the drive. I have the oscilloscope hooked up to the virtual tach signal(output3) and the velocity command signal(output0). I set the PID values back to zero for this test. These images are of the halscope and oscilloscope with a positive value in the tachometer output scale. The pink trace is the tachometer signal(output3) and the yellow trace is the velocity signal(output0). 

These images are with a negative tachometer output. 

With the PID values set to zero, shouldn't analogout0 be zero? it seems to follow analogout3. I've double checked that I dont have a short between the two. 

This is now in master branch 2.10
To see new pins install 2.10 and type man motion
Interpreter Metadata PinsThese pins provide geometric intent and interpreter state for the segment of motion currently being executed. Unlike standard position feedback, these values are synchronized with the trajectory planner’s execution point.Interpreter Status Pins

• Code:

  motion.interp.line-number
   (s32, out)
  The current G-code line number being executed.
• Code:

  motion.interp.motion-type
   (s32, out)
  The type of motion currently in progress:
  • 0: None
  • 1: Rapid (G0)
  • 2: Feed (G1)
  • 3: Arc (G2, G3)
  • 4: Tool Change/Other
• Code:

  motion.interp.feedrate
   (float, out)
  The interpreted feedrate for the current segment in units per minute.

Interpreter Geometric Pins

• Code:

  motion.interp.heading
   (float, out)
  The XY plane heading of the current linear move in degrees. Measured counter-clockwise from the +X axis (0 to 360). This could be used to control a tangential knife.
• Code:

  motion.interp.arc-radius
   (float, out)
  The radius of the current circular move. This value is 0.0 during linear moves. This could be used to modify plasma cutting parameters based on the arc radius and when hole cutting.
• Code:

  motion.interp.arc-center-x
   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane
• Code:

  motion.interp.arc-center-y
   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane
• Code:

  motion.interp.arc-center-z
   (float, out)
  The absolute Y-coordinate of the center point for the current arc if in XZ or YZ plane.
• Code:

  motion.interp.normal-heading
   (float, out)
  the heading from the current point back to the arc centre for the current arc.
• Code:

  motion.interp.iscircle
   (bit, out)
  True if the current arc is a full circle and not a helix.

NoteThese pins represent the commanded geometric intent from the interpreter and are updated in real-time as each motion segment is consumed by the trajectory planner. 
 

My original untested theory was that if you knew the arc radius in real time, you could calculate the centripetal radius for a given accelleration and cut speed to know when velocity had to slow down to negotiate an arc. So then on a corner, it might be possible to lock the cut height and move to using current for the process control variable to keep voltage constant. This should keep the kerf width constant.

I also added an motion.interp.iscircle pin so you can sense when the machine is cutting a circle and implement a real time algorithm to improve hole cutting.

And finally, I added tangential heading and normal-heading which is the direction back to the arc centre. The intent here is if you had an appropriate motion head on your plasma torch, you could cut bevels from 2D gcode.

This stuff might be a bit out there, but its there if you guys want to experiment with it with extensions to QTplasmac its there. I've done the hard part for you!

I'll just mention it here as after all its only taken me 6 years to get it into master branch as of this morning. You guys might like to think about how you could use these new pins (taken from man motion) in plasma cutting enhancements.Interpreter Metadata PinsThese pins provide geometric intent and interpreter state for the segment of motion currently being executed. Unlike standard position feedback, these values are synchronized with the trajectory planner’s execution point.Interpreter Status Pins

• Code:

  motion.interp.line-number
   (s32, out)
  The current G-code line number being executed.
• Code:

  motion.interp.motion-type
   (s32, out)
  The type of motion currently in progress:
  • 0: None
  • 1: Rapid (G0)
  • 2: Feed (G1)
  • 3: Arc (G2, G3)
  • 4: Tool Change/Other
• Code:

  motion.interp.feedrate
   (float, out)
  The interpreted feedrate for the current segment in units per minute.

Interpreter Geometric Pins

• Code:

  motion.interp.heading
   (float, out)
  The XY plane heading of the current linear move in degrees. Measured counter-clockwise from the +X axis (0 to 360). This could be used to control a tangential knife.
• Code:

  motion.interp.arc-radius
   (float, out)
  The radius of the current circular move. This value is 0.0 during linear moves. This could be used to modify plasma cutting parameters based on the arc radius and when hole cutting.
• Code:

  motion.interp.arc-center-x
   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane
• Code:

  motion.interp.arc-center-y
   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane
• Code:

  motion.interp.arc-center-z
   (float, out)
  The absolute Y-coordinate of the center point for the current arc if in XZ or YZ plane.
• Code:

  motion.interp.normal-heading
   (float, out)
  the heading from the current point back to the arc centre for the current arc.
• Code:

  motion.interp.iscircle
   (bit, out)
  True if the current arc is a full circle and not a helix.

NoteThese pins represent the commanded geometric intent from the interpreter and are updated in real-time as each motion segment is consumed by the trajectory planner.

my eyes glazed over looking at all the options but if its pneumatically actuated, why not a pressure switch? Cheap as chips!

 

Amazing work.

And furthermore 

And there's more