Advanced Search

Isn't that what I said? :-D
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...

There is a very good reason i asked...

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 

  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 

  halcmd

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

  [SPINDLE_0] MAX_FORWARD_VELOCITY

  , Z at or above 

  [AXIS_Z] MAX_LIMIT

  , and optionally Z below a configurable floor.
• Persistence: the active chuck is stored in 

  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 

   user_tabs/chuck_manager/

    in your config directory and copy 

   chuck_manager.py

    and 

   chuck_manager.ui

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

   [DISPLAY]
   USER_TABS_PATH = user_tabs/

3. Optionally copy the example 

   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:ConstantDefaultMeaningRe-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 

   halcmd show pin ini.z.min_limit chuck-rpm-limit

    and check both values arrived.
3. In MDI, command an 

   S

    value above the chuck's limit. 

   chuck-rpm-limit.out

    must stay at the limit while 

   .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 

  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 

     Z_LIMIT_FLOOR

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

  3. halcmd setp

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

     current_chuck.json

      written.
• Startup: the tab loads 

  chucks.json

  , selects the saved chuck and, with 

  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. 

  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 

  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 :WidgetobjectNameQComboBoxQPushButton, , , QTableWidgetQLabel, , , , 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