steplengths 5000, 7000, and 15000 all give joint following or finishing read errors.
Obviously, my parameters for speeds, acceleration, and the values in [joint 0] are still far from the right ballpark.

In addition to this, my ini in section [MESA] has an empty parameter called firmware. I copied these files in the directory as assigned by mesact. I am not sure what is required here but I want to emphasize the 7i95t manual strongly recommends not to use firmware for the 7i95 ( no T at the end) board.

Does someone have any advice on this ?

Cheers

geebee

Isn't that what I said?
following error in LinuxCNC is merely the sum of position commanded - position reported by the servo drive, a value without timestamps, always lagging behind. following error in the servo drive is more accurate as it is calculated on the drive itself without a lag of one or more servo cycles.

I am also in Germany but in no way an expert.
But yesterday I used Claude to write me something for my gui after gemini flailed.
And it worked damn good and relatively quick.
I also then let him check and comment my hal files with great results.
I was lazy and hacked around badly commented. now at least the hal of my lathe is clean and easy to understand I have also an overwie which signals are going across hal files.. I also used it to clean my really messy folders where all the failed attempts from the past and qnd copying over from other machines of mine messed everything up.
Tidy up some of my really messy python scripts. gave good suggestions renaming some of my buttons (oil, test, and test2 are not really easy to unerstand what they are doing ).

I will also do this with my mill.

So long story short for trouble shooting AI worked great for me.
I dumped my ini, hal, parameter and pin export and the ui files of my custom gui parts in there and then had a nice discussion.

You have the step length set to 10 ns

STEPLEN = 10

I would try 5 usec to start:

STEPLEN = 5000

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?