Advanced Search

Thanks for your ideas, this all really helps. 

This is a summary of the various ways I could add sensors, or control to the overall gear ratio. 

1/ pull the motor fan, and use the shaft stud to drive an encoder, and then mount an electric cooling fan on the shround for the motor.
++ Seems most robust solution.
++ covers entire drive train with single unit.
++ high resolution, low noise
++ encoder in and encoder out, the gear ratio would be rock steady and real time.
++ does not require pulling the entire drive unit. 
++ spare encoder input available on 7i85

2/ Make a little amplifier to scale that 0-10V motor speed output to 0-36V
++ Simplest solution
-- I am not strong in electronics.
-- less resolution than motor encoder
-- lower qualiy signal than encoder

3/ use an optical or hall sensor to count motor fan fins, or CVT features.
++ Slightly simpler that adding an encoder... or not...
-- as it would need the entire drive pulled.
-- less resolution then encoder
-- doesn't sense gearbox ratio.
-- dirty environment, unsuitable for optical sensors.

4/ Add an encoder to the CVT linkage, or to the CVT lead screw.
-- better options above
-- need to pull drive unit.
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

5/ Replace the CVT motor with a stepper or servo
-- more work than the better options above
-- large wiring change, add addition servo driver etc
 -- need to pull drive unit.
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

6/ Use a laser range finder on the CVT belt with a look up table to estimate ratio.
-- dirty environment, optics will likely unreliable over time.
-- better options above
-- non-linear relationship to ratio
-- needs LUT or algorythm to convert to approx ratio.
-- less resolution than motor encoder
-- doesn't sense gearbox ratio.

7/ Using a sensor to detect backgear lever position .
-- dont think there is an external lever, it is internally, pneumatically actuated with no external moving parts.
-- Since it is only shifted stationary, this is the easiest to infer. I can log last position, and cross sheck it using overall ratio, so this seems unnecessary.

8/ adding a gear tooth detector in the gearbox
-- significant effort to pull, disassemble drive unit, and drill hole in housing, design and mount sensor
-- less resolution than motor encoder
-- better options above

Seems to me that the motor encoder would to be the most likely to simply work, and work best. It covers the entire drive train in a single component, offers the highest resolution, and provides (with the spindle encoder) the most direct measurement of overall reduction ratio without noise, interpolation, LUTs etc.

However, before I add a sensor which Schaublin didn't need when they designed this system in the first place, I am thinking of taking one last swing a software solution. My original idea, which I have not yet tried. How accurate does a lathes spindle speed control really need to be?

- divide the CVT range into 5 "fixed ratios", one second apart.
- survey the whole range, generate a look up table of CVT "fixed ratio", and VFD Hz.
- Command the CVT in one second bumps (gear changes).
- largely open loop with VFD frequency interpolated between LUT values.
- Maybe switch to closed loop to fine tune speed (but I am hoping not to need to)
-- if closed loop needed, add PI gains to the LUT.
--  I already have VFD "motor on speed" wired in, and had not thought to use that to gate and freeze the ratio calculation when it would be garbage.
-- when there is steady state operation, use the calculated ratio just to cross check and maybe correct for CVT drift after multiple shifts. In practice, I expect it to be on limits quite often, which is a natural drift reset.

If I can't get that working, and really do need a sensor, I tend to the motor encoder.

 

I wanted to share an approach that may interest anyone running CNC on a Linux SBC without a Mesa card or a real-time kernel.

### The setup

Hardware: Arduino UNO Q — a single board that combines a Qualcomm QRB2210 (Debian 13 Linux) with an STM32U585 MCU connected via an internal UART (`ttyHS1`). The STM32 runs grblHAL and handles all real-time step generation. The QRB2210 handles G-code interpretation.

### The key insight

`linuxcnc-uspace` ships a Python API for `rs274ngc` that works perfectly outside of a running LinuxCNC instance:

```python
import gcode
from rs274.interpret import Translated, StatMixin

result, seq = gcode.parse(filename, canon, "G21", "")
```

This gives you the full rs274ngc interpreter — canned cycles (G81, G83…), O-word subroutines, G92/G5x coordinate systems, polar coordinates, error checking — with zero HAL setup and no real-time kernel requirement.

The `canon` object intercepts the resulting primitive motion calls (`straight_feed`, `arc_feed`, `spindle_on`…) and translates them to grblHAL commands streamed over serial with `ok`-based flow control.

### What rs274ngc handles automatically

- Canned cycles expanded to primitive G0/G1 moves
- Incremental → absolute coordinate conversion
- G5x / G92 work coordinate offsets
- Polar coordinates
- O-word loops and subroutines
- Unit conversion (G20/G21)

### Architecture

```
G-code file
    ↓ gcode.parse() — rs274ngc Python API
canon calls (straight_feed, arc_feed …)
    ↓ Python bridge
G0 / G1 / G2 / G3 over /dev/ttyHS1
    ↓
grblHAL on STM32U585 — real-time step generation
    ↓
Stepper drivers / CNC shield
```

Note: rs274ngc canon calls are always in inches (internal unit). All coordinates are multiplied by 25.4 before sending to grblHAL in mm mode.

### Repos

- Bridge (Python, runs on QRB2210): github.com/hoshigarasu/canon-grbl-bridge
- grblHAL firmware (STM32U585 port): github.com/hoshigarasu/grblHAL-STM32U585

Demo video: XY pen plotter drawing a 50mm circle, G-code interpreted by rs274ngc on the QRB2210, executed by grblHAL on the STM32U585. [photos.app.goo.gl/vnDY3CgpnHprdv5dA]

Happy to answer questions about the rs274ngc Python API or the canon interface.

Mark I thought about your issue some more and I have a  solution. Not terribly invasive a little bit of work but saves the variator. 

Return the speed control pid tuning to linux cnc

Put a closed loop stepper motor on the variator. Here's why

1. step counts are easy targets, so 10 steps = 1 point of gear ratio for example.

2. build a table of Frequency from command to stepper that optimizes torque.

So on Y you have commanded input from Lcnc as frequency
on X you have steps iun the table itself you have gear ratios. Build you selector logic to Always shoot for best torque.




Speed Command from g code
encoder feedback
min max home positions.
then spindle at speed output.

the look up table doesn;t even have to be complex could just be along switch statement, if <200 && >300 spnd cmd gear = 4

that's it. then let linuxcnc handle the fine control. your just grabbing the spnd cmd speed and setting the ratio.

See attached

www.alibaba.com/pla/IHSS57-36-20-Nema23-...rGX0_eUaArgzEALw_wcB


 

I like to wire E-Stops to power, not enable pins, with as few steps as possible. Soft e-stop can control an enable/disable line, but "real" e-stops I want to pull power from motors. On my machine, it's set up so that the Mesa card is powered separately from the motors/spindle. The Mesa card directly controls the enable lines for the motors, but the power enable signal (to a relay controlling motor power) is also physically routed through the e-stop button such that pressing the button will remove power regardless of what the Mesa card wants. You can get e-stop buttons with multiple switches in them if you want/need multiple circuits being separately switched by one physical button.

I generally also like to wire things such that "power applied" is "enabled", so that a broken wire or loose connection will only disable the machine.

If you've got other safety hazards from just yanking power (eg, a Z axis that could fall), you may need to consider those.

That info is pure gold rodw, thanks a bunch!
- Dual homing switches were the plan yeah, just checking if it's fine to have a single limit switch or if i need one i both sides?
- I'm currently using a PWM output + an RC circuit to get 0-5v for my spindle RPM but had already got the suggestion of using serial to talk with the VFD, glad to confirm that is a good approach.
- IO modules, if i can get what i need from used beckoff listings on ebay i might go that way. The servo inputs should take care of all the homing/limits, and if the VFD is handled separately, one of the most common ones with 16 IO might just do for e-stops, probes.. And i can always just add another module if that changes.

The concept of the break is also new to me, is this something you need to config or it's something that's handled automatically between the servo and its driver?

I don't think you will have any problems getting the drive going. I'ver noted many attempts with this drive have been flawed from the very beginning. The fact is they are cia402  drives and this means the core Ethercat registers are standardized and there are components to follow the cia402 state machine to start the drive. 

I would use Linuxcnc homing and forget about internal homing for now because of your 2 joint main axis (We would say XYYZ). Internal homing of a joint axis by Ethercat is a bit unknown/unsupported. Note having homing switches on both sides is mandatory on gantry machines. The gantry is auto squared on homing.

There should be some inputs on the servos themselves you could use if configured to be generic inputs in your ethercat-conf.xml. The safest/easiest IO would be to use Beckhoff EK1100 but there are several on AliExpress like Rtelligent, deiwu (I have used both, configs here github.com/rodw-au/linuxcnc-cia402) and another with an encoder input called catio-a which is mostly documented here on the forum. I have one of these and the forum config generally works (I have one of these too).

Note that the Beckhoff encoder modules are quite expensive but with a printnc style spindle, you probably don't have a spindle encoder. You could use RS485 modbus for spindle control with a USB or RS232(preferred) RS485 interface. This works pretty well with ethercat. I've been playing with the modbus control on the catio-a and  read one register once but then could never repeat it after adding all of the required registers.

Good luck

As I'm planning to do live coin minting at some events I attend, I will retrofit a proxon milling thing to make my own coin dies.
Model is this one:
forum.drucktipps3d.de/file-download/12960/
I'm in contact with a nice austrian guy, who has done that before LinuxCNC exists (uses some old DOS software via par port). So the mechanical part is quite proven.
Plan is as follows:
- replace all threads with ballscrews
- a mesa 7i96s (have that from a dead project)
- stepper motor and microstepper driver (from yet another dead project)
- maybe place a 1:6 gear between stepper and ballscrew (this is actually trick from the austrian guy) for higher detail
My main question is about the milling spindle. As I will mill little amounts of material, I was aiming for some small spindle (partially for lower weight to have faster and more precise movements). On the other hand it should have quite high rpm and very good concentricity.

So far I was thinking a AMB 530 FME. At least I couldn't find a lighter one that would serve the purpose.

Please let me know if my plan might generate a working machine or if I have a major f-put in my plan.

Yes. I shelved this idea. The faceplate on the VFD made it quite clear that it isn't going to take 240. I have a buckboost to take 240 to 272. Hoping that this will give me enough power for the analog drives. Will use 240V single phase to power a VFD for a much lower HP spindle. Will also use 240V single phase to power any additional drives. Not super sure exactly which MESA setup I'm going with yet. Have to confirm that the analog drives are good first. I was wondering if I could just hook up the 10V to a 1.5V battery and make the drives move the steppers.

- I'm going to first disconnect the brushed servos from the analong drives. Power leads, encoders, everything.
- I guess I can first check the DC bus this by sending in 120V. This should give me close to 170VDC.
- If math serves me right, the DC bus should be 390V rectified with the single 277V leg. With my transformer, it should be 385V. Wondering if the drive cares whether the negative leg of the DC bus input is tied to ground. If it does matter, I'm not sure how to proceed from here. Not exactly sure how to check.
- From here, I am guessing that connecting a 1.5V battery to the drive "should" make the drive send out a tiny bit of the DC bus DC voltage. Since I'm not connecting it to anything, i should be fine. 

Will try to understand more from first principles but most appreciate any pointers.

I think you are on the right track.

Single-phase to the machine, and use 220vac step/dir drives and a 220 vac single-phase-in, 3-phase-out VFD for your spindle.

Based on some low-cost (maybe Stepperonline A6) servo specs, you've probably got enough power budget to realistically drive 4/ea 1kw servos (XYYZ), a couple of 750w servos (A&C), plus a 4-6kw VFD for a decent ATC spindle.

If you want a big vacuum for hold-down or dust collection, you might need to put that on a separate circuit.

I'd recommend planning on using timer relays (hardware or software-driven) for the drive and VFD main contactors.  Cheaper drives (and some expensive ones, too) don't have great inrush-limiting features and turning everything all on at once can strain (or overload) the supply circuit.  If you break up the inrush over 2-3 'stages' with some on-delay timers it'll be a lot more gentle.

Clear the estop and you'll hear clunk...clunk...clunk... over a few seconds before everything is ready.

Hi, my bad i did not mean COM but parallel port (must be a habit from my Arduino days). I did try to put the encoders on the second par port (parport 1) and for some reason it works now (parport 0 = stepper outputs, parport1 = encoder inputs). No idea why, i don´t think it is grounding related though.
As for the encoders: They are linear scales (5µm), my math was 5000 to 10000PPS * 0.005mm * 60 = 1500 to 3000 mm/min. The spindle has a 400PPR Encoder and max spindle speed is 3000rpm.
I still have to get the inputs on parport0 working to read the spindle encoder. Tomorrow i can send pics of the wiring.

Thank you!
-existing stuff
I don't see why I cannot use the existing drives for the existing servos. The intention was not to replace those at all. For the VFD, I very much want a water cooled VFD tho I have been told that it takes up a lot of extra vertical real estate. In the end, I'll be a one person outfit for a while anyway, so maybe I can just say screw you OSHA and just deal with the noise on that 16hp spindle. I will never use the full capacity, so as long as I can start it up, I think I should be alright. I imagine I can do some sort of a ramp up start with the VFD settings. That reminds me to check if it works.

-can I mix drives? the swivel head that I have will comes with yaskawa servos and no drives(or I can add drives). I cannot imagine there being as issue to mixing and matching. And concerns with mixing analog/digital?

**********
-if you still want to replace the drives, you have two choices in general: EtherCAT or Mesa with normal step/dir or analog servos (do not bother to look at steppers and close loop steppers)

I'll have to research this. I do not know if the current servos are closed loop ones. The ones on the X and Y axis are mts30r4-42. They have 3 power leads (2 bigger wires, 1 thinner). I've confirmed that I can get a voltage if i turn the servos by hand. The resistance is above the plate, but still under 2ohms. 4 brushes in good condition. There are 4 other pairs of wires that I found out are A, B, Index and Power. Haven't wrapped my head aroud thinking about them from first principles yet. Would this existing hardware affect any of my choices?

-For the Mesa/new drives, i would look for "position and velocity" mode drives (analog +-10V and step/dir) and also with encoder outputs (all have encoder inputs or absolute encoders, usually serial ones) so the loop can be closed in LinuxCNC with both types of control, makes life easier during use. Given the choice between analog and step/dir, choose step/dir.
>>> I'm going to research this paragraph a little more first.

I was wondering if there are good software or schematics for recreating the wiring. I found the Fagor 8055 manual, but it seems more like how to use it rather than how to fix it.

Thank you!

I might not be the best person to reply to this as i absolutely enjoy retrofitting and bringing back to life old machines, so i may be a bit on the "trigger happy" side, but:
-i would try to use the existing drives and motors and VFD/spindle
-seems like those are analog drives, so a Mesa 7i97T would do perfectly fine if you can find one, if not a 7i92T with 7i77 is the same thing, or if those are also scarce a 7i96S with 7i85 and 7i83 should do the same job.
-if you still want to replace the drives, you have two choices in general: EtherCAT or Mesa with normal step/dir or analog servos (do not bother to look at steppers and close loop steppers)
-You will be bombarded by others to choose EtherCAT, i am still avoiding them due to some fuzzy communication issues, but i will test them for sure the fist chance i get.
-For the Mesa/new drives, i would look for "position and velocity" mode drives (analog +-10V and step/dir) and also with encoder outputs (all have encoder inputs or absolute encoders, usually serial ones) so the loop can be closed in LinuxCNC with both types of control, makes life easier during use. Given the choice between analog and step/dir, choose step/dir.

You don't say what the inputs to and2.2 are. That is probably important.

A problem you will have is that spindle.0.index-enable is a bidirectional HAL pin, so can't be directly connected to the output of an and2 block.

You can probably work around this with linuxcnc.org/docs/stable/html/man/man9/tristate_bit.9.html

But, are you sure that your spindle encoder driver doesn't offer e direct, bidirectional, index-enable pin?

There is an example of an index-simulator HAL component here:
forum.linuxcnc.org/24-hal-components/388...ation?start=0#223508

It's written for a stepper spindle, but should work just as well (or just as badly) for an absolute encoder assuming that the encoder has an integer "counts" output.


I was going to suggest watching one bit of the binary counts value and tristate-bit. But that wouldn't zero the counts on index.

There _is_ a way to do it with a sample-hold to capture the counts at index, then subtracting that from the raw counts, that would need a bitslice, mux_generic (set up for signed int), edge, and tristate-bit HAL component.
It's do-able but at that point the custom HAL component makes more sense.

It's easy when you know it.
The problem is to come to know enough.

Anyway, it's not that hard and there is virtually no difference between
setting up stepper drives or servo drives with EtherCAT.
The cia402 layer makes them look the same.

The example I gave is a starting point.
You can copy the files to your installation, change the HALFILE=cia402.hal in the ini file
and give it a try.

But you are going to need to adopt and edit the files to your specific setup.
Number of drives, what number/name they have. And you need to add other
functions like spindle. That's in the sim file. So you need to mix them together
and take the motion part from cia402.hal and the other functions spindle, limits etc
from the sim config.
 

Update:
i have copied the "working" fies from page 1 into my axis.sim folder, removed the date in their names and put the Basic.hal to be called in the axis.ini file. now the axis.sim does not start and i get this error log: 
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/christian/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis.ini'
INIFILE=/home/christian/linuxcnc/configs/sim.axis/axis.ini
VERSION=1.1
PARAMETER_FILE=sim.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal
Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal
Found file(REL): ./cooling.hal
Found file(REL): ./Basic.hal
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
trivkins: already exists
./Basic.hal:3: waitpid failed /usr/bin/rtapi_app trivkins
./Basic.hal:3: /usr/bin/rtapi_app exited without becoming ready
./Basic.hal:3: insmod for trivkins failed, returned -1
2381
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime