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.

 

Thanks, I will look into these parameters!

My thought behind adding it as an E-stop was to have it as part of the safety relay circuit outside of linuxcnc.

I need help with this. I can not seem to get mine working. If you remember how you where able to do it would be a great help. The hal file only loads after the psng probe screen. I can switch back to the gmoccapy change.ngc and it work as expected but i can then not probe like i want to. I can not get the correct tool height after gcode start. Any help would greatly be appreciated!

Measure between gnd and each channel.

You cannot do this without two  differential probes.

Measure the A,B signals relative to ground.

But as you said I don't think this is the issue as long as the position
readout is correct.
 

I was measuring it against the compliment. I had the probe on channel A and the ground on the probe clamped to the inverse channel A. Same thing for channel B.

Viewing channel a and channel b in HALSCOPE everything looks normal. So I’d assume this isn’t actually the issue either.

scsmith1451 wrote:

The GMOCCAPY documentation indicates that if no EMBED_LOCATION is defined, the the glade VCP will be floating. Is that no longer valid?

AFAIK this was never supported. Where do you have this info from? I can't find such in the current Gmoccapy documentation.

Have a look at this, no AI was harmed during that retrofit !
forum.linuxcnc.org/show-your-stuff/32784...-15-retrofit?start=0

Hi all,
Hoping this is the right place for a conversation about machine controller conversions. I'm a hobby user, not a production shop. I've got a  Mazak VQC 20/40 mill with M2 control, it's a nice fully functional machine with good tolerances for it advanced age. It's lack of memory is a real pain point. Programming in Mazatrol CAM M2 was probably great back in the day, not so much now. I can send G-Code files to it, but hit file size limits rather quickly. It's not capable of drip feed. I think I'm ready to go for the Mesa upgrade. With AI help I've input all the info I can think of, this is where I'm at... realistic? reasonable?

Servo Motors & Drives:
X-axis: Mitsubishi HD-81-12 DC permanent magnet servo motor with analog drive accepting ±10V command (terminals: AX, BX, G1X, G2X, G)
Y-axis: Mitsubishi HD-81-12S DC PM servo with analog drive (terminals: AY, BY, G1Y, G2Y, G)
Z-axis: Mitsubishi HD-101-12 DC PM servo with analog drive (terminals: AZ, BZ, G1Z, G2Z, G)
All three drives are MELDA-8 or similar Mitsubishi analog cards that accept ±10V command signals—these are REUSABLE
Position Feedback:
X-axis: Magnescale SR-921RH linear encoder (outputs quadrature signals directly) + MS3100B 20-29P tacho generator
Y-axis: Tamagawa Seiki resolver (MS3108B 20-29P, pins: RS1, RS2, RC1, RC2, RO1, RO2) + tacho generator
Z-axis: Magnescale SR-921RH-450-R-0 linear encoder + MS3108B 20-29P tacho generator
Spindle:
Mitsubishi AC motor SE-EV-FV with FREQROL FR-SX VFD controller
Already accepts 0-10V analog speed command and direction signal—fully LinuxCNC compatible
Tool Changer:
20-tool carousel ATC with CAT40 tooling
Nachi proximity sensors for position detectionMesa Hardware StackCore Cards 
7i92H  - Ethernet-based motion controller, main brain
7i77  - 6-axis ±10V analog outputs + encoder inputs + 48 I/O points
7i49 - 6-channel resolver interface (for Y-axis only)
7i73 - Pendant/operator panel interface

Servo Drive Connections:

Existing 24VDC power supply (HR-11F, outputs P24 and G24) remains in service:
Mesa 7i77 I/O is 24V compatible
Existing Contactors (3S-1, 3S-2, 3S-3, 3S-4):
Control servo drive enable sequencing
Spindle power control
Lube/coolant pump control
These stay and get controlled through Mesa 7i77 I/O outputsATC IntegrationInputs to LinuxCNC:
Tool-in-position sensors (Nachi proximity switches)
Carousel rotation feedback
Gripper open/close confirmation
Drawbar clamp/unclamp sensors
Outputs from LinuxCNC:
Carousel motor control (forward/reverse)
Gripper solenoid
Drawbar solenoid
Air blast control

Oh, I almost forgot – I wanted to let you know if I succeed.I’ve been gradually increasing the C00.05 stiffness parameter.

Are you measuring the encoder signals against ground?

(you cannot measure differential signals on an oscilloscope  without a differential probe)

Unfortunately HDD is dead. A colegue of mine will bring a laptop he was using with simillar machine but on Windows+Mach setup, maybe i will get some info from there

I guess the H11L1SM optocoupler could be damaged but that's
much less likely as it does not connect to the outside world.

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.

I'm at this step to. But I feel like it's been worse after the autotune than it was before.
That software is such a mess that I regret not going the Leadshine way.
I also have a slightly noisy Z axis servo but I can't find the gain parameter... Any clue ?