Advanced Search

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 ?

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