Advanced Search

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.

While getting my linuxcnc rettrofit lathe running again after moving shop. I wanted to turn close to the spindle. But my soft limits protect me from doing this. Of course you can ignore limits, but I was thinking about a "chuck table" with some more details on it like:
diameter, max rpm, z_limit, number of jaws and weight.

My concept so far...

Files:

• chucks.json – Stores your database of chucks, limits, and parameters.
  • current_chuck.json – Automatically created/updated to persist the currently active chuck across reboots.
    • chuck_manager.py – The Python handler script linked to your custom tab.
    
    Widgets:
    
    Widget TypeObject Name (objectName)Description
    QComboBoxchuck ComboBoxDropdown showing line numbers and chuck names (synced with the table)
    QPushButton activateChuckBtn  confirmation button to apply limits and save state.
    QTableWidget chuckTable 7-column interactive table to view, add, edit, and delete chuck profiles.
    QPushButton addChuckBtn Button to insert a new blank row into the table.
    QPushButton saveTableBtn Button to save table modifications permanently back to chucks.json.
    QPushButton deleteChuckBtn Button to remove the currently selected row.
    QLabel lblMaxRpm Displays the maximum allowed spindle RPM for the selected chuck.
    QLabel lblZLimit Displays the active Z-axis soft limit (ini.z.min_limit).
    QLabel lblDiameter Displays the chuck body diameter.
    QLabel lblJaws Displays the number of jaws.
    QLabel lblJawsDisplays the number of jaws.QLabellbl Weight Displays the chuck weight in kilograms.
    
    
    At the moment I have four chucks:
    
    {
       "Standard 3-Jaw Chuck (250mm)": {
          "max_rpm": 2400,
          "z_limit": -45.0,
          "diameter": 250,
          "jaws": 3,
          "weight_kg": 25.5
       },
       "centric 4-jaw Chuck (160mm)": {
          "max_rpm": 3000,
          "z_limit": -60.0,
          "diameter": 160,
          "jaws": 4,
          "weight_kg": 4.2
       },
       "Heavy 4-jaw Chuck (400mm)": {
          "max_rpm": 800,
          "z_limit": -30.0,
          "diameter": 400,
          "jaws": 4,
          "weight_kg": 40.0
       }
       "Power chuck (250mm)": {
          "max_rpm": 2400,
          "z_limit": -45.0,
          "diameter": 250,
          "jaws": 3,
          "weight_kg": 50.0
       }
    ​​​​​​   "Spindle": {
          "max_rpm": 3000,
          "z_limit": -110.0,
          "diameter": 60,
          "jaws": 0,
          "weight_kg": 0.0
       }
    }
    
    Next is writing and debugging the script.

I’ve had problems with my lathe after running ‘reference’ in Flex GUI.
When both axes are  homed, I can jog the X-axis without any problems.
But the Z-axis doesn’t move. If I run ‘unhome’ on the X or Z, I can jog the Z-axis.
I switched to Probe Basic and it works as intended with the same INI file
no problems with jogging once the axes are  homed.
I checked with HalShow, and the difference between Flex GUI and PB was that the telop
function worked on both axes in PB but only on the X-axis in Flex GUI.
In Flex GUI, the X-axis is 0 and the Z-axis is 1. When the axes are not at home, jogging works normally. Where should I look for the fault?


 

I don't see any 5i25+7I76+7I85S firmware images with step/dir index
but I can compile one in the next day or so if you want to try it.

fmueller wrote:

• If LinuxCNC requests tool T5 but the operator installs the wrong tool, the simulator should use the geometry of the tool that was actually installed.
  • If the physical tool length differs from the value in LinuxCNC's tool table, that difference should affect the machining result.
    • A virtual toolsetter should be able to detect the actual tool length, just like a real toolsetter.
      • Incorrect offsets, incorrect tools, or incorrect workpiece positioning should be capable of producing incorrect machining results or collisions.

I can't imagine it.
The simulator cannot use information that is not available.
If, for example, we have a manual tool change, the simulator can at most receive information that the tool has been replaced. LinuxCNC does not ask what physical tool the operator has installed, cannot use the answer to a question he did not ask and cannot transfer information to the simulator that he does not have.
I wrote about tool measurement simulation only in the sense that the simulator would show the movements that will actually be made.
I have a remap that goes to the manual tool change position, then moves to the height sensor, and then returns to where it started. Showing these movements would make the simulation more realistic, but it seems impossible to simulate operator error.
There are simply things that cannot be done and you have to accept it.
Coming back to REMAP M6, it could probably be done.
You could use a shell script that would first run a program to tell the simulator to change the tool, and then run the user remap  program. This should work.
An alternative would be to change the stepper-ninja code so that additional information is transmitted. Maybe it's worth going in this direction, because it would provide additional possibilities that could be useful in the future...

Alexf2a wrote:

Alexf2a post=350204 userid=28355

Yes, I use the encoder solely for the homing procedure using the Z-mark on the Sino linear scale.
First, the axis moves to the inductive sensor, and then a precise homing sequence is performed at a lower speed using the encoder's Z-mark.

Is this open loop in the sense that you do not actually use the encoder
or its index for position feedback?

Here is 5I25T firmware for the Haase parallel interface.
(just a minor bit different than Benezan)

 

Note that a stepgen (stepgen4)  is used to drive the chargepump pin
(pncconf knows how to set this up)

Hi tuxcnc,Thank you for your feedback and suggestions! You have actually touched on two of the next major features we are planning: physical tools and tool measurement.I think it would be useful to explain the underlying concept of this simulator, because it is slightly different from a traditional G-code simulator.Our goal is to simulate a real CNC machine, including its capabilities, limitations, and potential mistakes.A real CNC machine does not interpret G-code itself. LinuxCNC is responsible for interpreting G-code, planning trajectories, applying tool offsets, and controlling the hardware. The machine simply responds to the commands it receives.We want our simulator to behave in exactly the same way.The virtual machine will have its own physical state: axis positions, spindle, installed tool, tool geometry, workpiece, sensors, and eventually machine geometry and collisions.An important design principle is that the physical state of the simulated machine must remain independent of what LinuxCNC believes that state to be.For example:

• If LinuxCNC requests tool T5 but the operator installs the wrong tool, the simulator should use the geometry of the tool that was actually installed.
• If the physical tool length differs from the value in LinuxCNC's tool table, that difference should affect the machining result.
• A virtual toolsetter should be able to detect the actual tool length, just like a real toolsetter.
• Incorrect offsets, incorrect tools, or incorrect workpiece positioning should be capable of producing incorrect machining results or collisions.

This behavior is intentional. We don't want the simulator to automatically correct mistakes that would also happen on a real machine.For the same reason, I would prefer not to intercept or reinterpret M6 using a custom REMAP. We should instead investigate how to model the machine-side tool-changing process through the normal LinuxCNC interfaces, without interfering with an existing tool-change implementation.Of course, the simulator should also support automatic tool changers in the future. The important distinction is that a requested tool change and the tool physically installed in the spindle are not necessarily the same thing.We have also completed the first virtual spindle implementation. LinuxCNC can now control it through the normal spindle commands, with encoder feedback returned through the Stepper-Ninja interface.Our next development steps are the physical tool model, tool changes, and tool measurement.Your feedback is very valuable because it helps us identify what is needed to make the simulator useful for real LinuxCNC configurations.Thanks again for testing the project!

Are you in Germany or thereabouts?