I should note that a closed loop linear encoder feedback system will be difficult
to make stable unless you can remove the backlash mechanically...

I'm in France, right next door, I believe this said « German / European ».

Ok yes, it's right there in the title, glad I didn't imagine it.

 Thanks for a firmware. I will try. And this firmware will work with option of use of the encoder for use of feedback by situation? This assembly now so works for me but it is not possible to configure well PID - when there is a processing on three coordinates not the really good surface of processing at once. If there is a processing at the same time on two coordinates purity of processing acceptable. On the milling machine a heavy table. Earlier I managed this Mach 3 machine and at small speeds the processing on three coordinates gave at once a good surface.  I want to try to make also and in Linuxcnc with exact search of the house by encoders.

the limits wee already on the machine and fixed.
But I solved it in a custom tab if its for anyone of interest:

forum.linuxcnc.org/qtpyvcp/59312-lathe-chuck-table#350217

Received a heads up my site was redirecting the listing sub page yesterday, thank you! That has been fixed. You can now navigate the listings directory to see photos / review the manuals.

 

5I25 configuration for 7I76 +7I85S with Step/Dir index for
Step/Dir channels 0..3 (7I76)  on 7I85S encoder index pins 0..3

That is 7I85S encoder inputs 0..3 has shared encoder and stepgen
index function with the stepgen index function applying to stepgens
0..3 (on the 7I76)

I Cheated and used Claude in the end.If anyone wants to use soothing like this also here is a manual and the necessary files

OverviewThis UserTab lets a lathe operator pick the mounted chuck from a list and enforce that chuck's limits in HAL: a maximum spindle speed and a Z soft limit. It is built for Probe Basic Lathe (QtPyVCP) and tested on a Mesa 7i97 machine, but nothing in it is hardware-specific.

• Chuck table: add, edit, delete and save chucks (name, max RPM, Z limit, diameter, jaws, weight). Data lives in 
  Code:

  chucks.json
   in the config directory.
• Dropdown + info line: select a chuck and see its data at a glance. The active chuck is highlighted green in the table.
• Activation with confirmation: one button writes both limits to HAL after a Yes/No dialog. If 
  Code:

  halcmd
   fails, the chuck is not marked active and an error dialog appears.
• Plausibility check: rejects RPM <= 0, RPM above 
  Code:

  [SPINDLE_0] MAX_FORWARD_VELOCITY
  , Z at or above 
  Code:

  [AXIS_Z] MAX_LIMIT
  , and optionally Z below a configurable floor.
• Persistence: the active chuck is stored in 
  Code:

  current_chuck.json
   and re-applied automatically at startup, so the display and HAL never disagree after a restart.
• Fail-safe RPM clamp: the spindle clamp is a HAL component with a conservative default, so the low limit holds even if the GUI never starts.

Requirements and file layoutYou need LinuxCNC 2.9 or newer (for the writable   HAL pins) and Probe Basic Lathe with UserTab support. Check the Z pin exists with  . The folder name,   name and   name must match. The JSON files live in the config directory, not in the tab folder; the tab finds it through the   environment variable that LinuxCNC sets.Step 1: HALLinuxCNC has no writable HAL pin for the maximum spindle speed, so a   component is inserted into the speed command chain. The Z soft limit needs no HAL change: the tab writes the existing   pin.Find the line in your main HAL file that takes   (or  ) to your output stage. Insert the clamp between them. Example for a chain that ends in a   component: Without a gearbox, connect   to whatever   fed before (a PWM generator, a scale component, a VFD pin). The clamp sits after the spindle override and before the gearbox, so it limits the real chuck speed and the override knob cannot push past it.The pins are named   and  , without underscore. The   source declares them as   /  , but   strips the trailing underscore.   aborts LinuxCNC startup with "parameter or pin not found".After a restart, check with  .Step 2: install the UserTab files

1. Create 
   Code:

   user_tabs/chuck_manager/
    in your config directory and copy 
   Code:

   chuck_manager.py
    and 
   Code:

   chuck_manager.ui
    into it.
2. Point Probe Basic at the folder in your INI, if it is not there yet:
   Code:

   [DISPLAY] USER_TABS_PATH = user_tabs/
3. Optionally copy the example 
   Code:

   chucks.json
    into the config directory. Without it the table starts empty and the file is created on the first "Save Changes".

The database is one object per chuck, keyed by its name: The values in the example are placeholders. Take max RPM from the chuck's rating plate or datasheet, and measure the Z limit on your machine. Z is in machine coordinates, so its sign depends on your machine's travel and home position.Step 3: configure and testFour constants at the top of   control the behaviour:ConstantDefaultMeaning Re-apply the saved chuck to HAL at startup without a dialog.   only logs a warning and marks nothing active. Pin for the Z soft limit. Pin for the RPM clamp from Step 1. Lowest Z limit a chuck may have, in mm.   disables the check. Set it a few tenths of a mm inside the physical limit switch once you have measured it.The chuck limit can only make the machine more restrictive. LinuxCNC still enforces   and   from the INI, so a chuck Z limit below them has no effect. Set the INI values to the real travel and let the chucks narrow it.Test before cutting:

1. Start LinuxCNC and open the tab. The dropdown and the table must show your chucks.
2. Activate a chuck. Then run 
   Code:

   halcmd show pin ini.z.min_limit chuck-rpm-limit
    and check both values arrived.
3. In MDI, command an 
   Code:

   S
    value above the chuck's limit. 
   Code:

   chuck-rpm-limit.out
    must stay at the limit while 
   Code:

   .in
    shows the commanded value.
4. Jog Z slowly toward the chuck. Motion must stop at the chuck's Z limit.
5. Restart LinuxCNC. The same chuck must be green again and step 2 must show the same values.

How it worksEditing and activating are separate: changing the table never touches HAL, only "Activate Chuck" does.

• Edit: type into the table, use "Add Chuck" / "Remove Chuck", then "Save Changes". Save validates all numbers and rewrites 
  Code:

  chucks.json
  . A row with invalid data aborts the save with a message.
• Select: pick a chuck in the dropdown or click its row. The info line shows max RPM, Z limit, diameter, jaws and weight. Nothing is applied yet.
• Activate: "Activate Chuck" runs this sequence:
  1. Plausibility check against the INI and 
     Code:

     Z_LIMIT_FLOOR
     . On failure: error dialog, nothing applied.
  2. Confirmation dialog showing the two limits.
  3. Code:

     halcmd setp
      for the Z pin, then the RPM pin. Each return code is checked.
  4. Only if both succeeded: green row and 
     Code:

     current_chuck.json
      written.
• Startup: the tab loads 
  Code:

  chucks.json
  , selects the saved chuck and, with 
  Code:

  AUTO_APPLY_ON_START
  , re-runs steps 1, 3 and 4 without the dialog.

The dropdown items carry the chuck name as item data. Matching is exact, so "Collet" never selects "Collet ER32".Safety notes and limitationsThis is a software convenience layer, not a safety function. It reduces operator error; it does not replace hardware protection.

• It clamps the command, not the spindle. A drive fault, a wrong analog scale or a runaway VFD can still overspeed the chuck. Real overspeed protection needs independent monitoring of the encoder speed, or a drive-side speed limit.
• The clamp is silent. 
  Code:

  S2000
   with a 1500 RPM chuck runs at 1500 RPM without a warning. Surface speed and feed per rev change accordingly.
• The operator must select the right chuck. The system cannot detect which chuck is mounted.
• The fail-safe default only helps if it is low. Set 
  Code:

  chuck-rpm-limit.max
   in the HAL file to your weakest chuck.
• Limits apply until the next activation or restart. Changing a chuck's row and saving does not re-apply it; activate again.
• Keep hardware limit switches and E-stop in the drive enable chain. If LinuxCNC or the GUI hangs, only hardware stops the machine.

Use at your own risk, and test every chuck with a low commanded speed first.Pitfalls we hitThese cost the most time during development and apply to any QtPyVCP tab.SymptomCauseFixDropdown stays empty although the table loadsPyQt gives   a  , so an empty combo box is falsy.   returns before the first item is added.Test widgets with   /  , never by truthiness.  behaves the same.LinuxCNC aborts: "parameter or pin 'chuck-rpm-limit.min_' not found"  strips a trailing underscore from pin names.Use   /  .Activation seems to work but the spindle is not limited  does not exist;  ignored the error.Clamp in HAL (Step 1) and check the   return code.A button does nothingIts objectName in the   (e.g.   after copy/paste) differs from the name in the code.Keep the names in the table below.  on a LED pin failsQtPyVCP turns   in a widget name into   in the pin name: widget   becomes  .Look up pin names with  .Object names the code expects in the  :WidgetobjectNameQComboBox QPushButton ,  ,  ,  QTableWidget QLabel ,  ,  ,  ,  If   is missing from the  , the code creates one and inserts it into the layout named  .

A short clip of the home-built lathe that Turn G-code was written for. It runs LinuxCNC; the G-code for the cuts in the video was made with the program.



Happy to answer questions about the build or the program.

I think you're making a mistake in your assumptions.
LinuxCNC does not receive information from the servo telepathically, but in the same way as information about the position reached and it takes the same amount of time. The observed differences in the values ​​of various variables probably come from the fact that they mean something completely different. The position error in LinuxCNC and the position error in the servo are two different errors, calculated from different data.

Is there a way to use the following error of the servo drives instead of the simple internal calculation in LinuxCNC? 
I get the actual following error from the servo drives (inovance SV660N / stepperonline a6) via ethercat idx="60F4" and have used it to tune the drives. 

There is an inherent lag between the commanded and actual position of servos due to the servo cycle of 1ms plus execution time plus processing in the drives and so on. For high speeds of say 50m/min LinuxCNC reports a couple mm of following error while the servo driver itself does not show any significant error. Is there a way to use the actual following error from the servo driver, and use that as the following error in linuxcnc for the joint, instead of the calculation on the side of linuxcnc?

Hallo

I cant get my stepper motor to turn. It is linuxcnc version 2.9.4, a leadshine cs-d508 and a transmotec SHW4247-09-168. The configuration files originate from a 7i95t setup via MesaCT, but I have tried to adjust the prarameters of the ini file in order to get it running. When starting linuxcnc (axis gui) it powers the motor up (blocks the shaft) and at first does not show any errors. (Later with the test ngc file error finishing read and joint following error) The gui shows the movements according to the test ngc, but goes beyond x=50.

Only the x axis was set up since I wanted to keep ini and hal files as simple as possible in order to alleviate debuging and error tracking. I am aware the cs-d508 is a closed loop driver. After the system is correctly behaving, I intend to retrofit a DRO to my lathe and use its signal for a closed loop system

It does turn when used with an arduino and tb6600 With linuxcnc it turns neither with cs-d508 nur tb6600.
Any ideas what I am missing ?

Thx

geebee

On my lathe running PBL I have an adjustable (sliding) limit switch that I can reposition if I change the chuck and/or use a long tool. It doesn't set the soft limits but will stop the carriage and prevent a crash.

But yes, a configurable (soft) travel limit would be very helpful, so you could set it without having to edit the ini file.

Thank you very much!

I don't know anything about that particular servo, but I would 1st suspect either a wiring issue (bad cable) or if the servo uses an absolute encoder, a dead backup battery for the encoder.