My guess is Rufus is the problem, create a new ISO with Balena Etcher

.hal/.ini attached:

Hi,
I tried Editor, Notepad++ and eq. all the same result!

Still trying to figure out what the problem is...

If I open the file with gedit from Linux, everything looks fine, but as soonas I change to LinuxCNC I have the same crap...

Freddie

I have a 7I77 and a 7I76 hooked to a 5i25. And then there is a 7I66-8 and a 7I66-24 connected via serial (but I don't think those matter).

I looked for a while and didn't find / couldn't figure out with firmware I would need. Can you recommend an exact firmware?

Thanks!

To get hardware PWM you need to have firmware on the FPGA that supports PWM.
For example if using a 7I76, there is FPGA firmware that replaces 1 Step/Dir output
with hardware PWM/Dir
 

Posting your hal/ ini files would help to pin down the issue.
 

Hi all,

I'm planning a gantry router build for machining composite panels into cabinet components. Looking for advice on machine choice and stack.

Material

- Sandwich panels: 1mm aluminium skins on both faces, polyurethane foam core
- Total thickness: ~60mm nominal, but varies ±1mm across a batch
- Panel size: up to 1500x3000mm

Parts and operations



- Cutting outlines
- Pockets and step joints on panel face
- V-scoring the aluminium skin to create precise fold lines (score-and-fold)

These operations require multiple tools in a single job (end mills for pockets and joints, V-bit for scoring), so automatic tool change (ATC) is a hard requirement.

The step joints are the critical operation: they create mechanical overlap between mating panels so cabinets assemble with tight joints. A 1mm thickness variation in the stock translates directly into a gap.

Workflow

probing → generate Z map → process map (Python) → adjust G-code geometry (XY and Z) → send corrected G-code → machining

- Fusion 360 CAM produces nominal G-code
- Before cutting, I probe a grid of Z points across the panel surface
- A Python script reads the probe map and rewrites the G-code: step depths and joint profiles are adjusted to the actual measured local thickness — for both the panel being cut and its mating counterpart
- This is not just Z surface compensation: XY profiles are modified based on the probe map so that mating joints match regardless of thickness variation

Why LinuxCNC

- Workflow already tested with LinuxCNC + MESA cards (7i96/7i77) on an entry level router.
- Plan to use the Python socket interface for probe data collection and G-code rewriting — tight integration between probing and post-processing is central to the workflow

My questions

1. Are there manufacturers selling new gantry routers with these specs who ship with LinuxCNC, or sell mechanics separately from the controller?
   - Working envelope: ~1600x3200mm
   - HF spindle: 18k+ RPM
   - Integrated vacuum table with independently switchable zones
   - ATC (tool magazine or rack)
   - Probe input

2. For a retrofit path: which used industrial gantry platforms have the best LinuxCNC community experience?
   - Main concerns: ATC integration and vacuum zone management via MESA I/O

3. Any experience with probe-map-driven G-code modification beyond simple Z surface mapping?
   - Currently planning G38.x + Python
   - Is there a better pattern for this use case?

Thanks

 

Phew, its taken a few years, but my irrecoverable account has finally been deleted and I have been able to re-register under my usual username,hoorah!

While trying to troublshoot a CNC router that has been running just fine for years and suddenly can't find its 5i25 card ... it occurred to me ... does a Mesa based install even need a base thread?  Surely just a servo thread is all thats needed?

Can I comment out the BASE_THREAD in [EMCMOT], remove the thread start in HAL and move any HAL things that were on the base thread to the servo thread?

I w

In your INI file look for a KINEMATICS entry. Change XYZ to XYYZ to tell it you have two Y joints. Further down you end up with [AXIS_Y] but [JOINT_1] and [JOINT_2]. PNCCONF should have set this up for you.
The other important thing is that the two Y motors can't share a homing sensor input. You can share X and Y1 or Y2 and Z but not Y1 and Y2.
You may also need to reverse the rotation of one of the Y motors. How you do this depends on your hardware, of course.

1. Over the winter I modified my DYI Router Mill adding a tandem Y axis and rebuilding my Z axis support with a 2-DF gimbal  to true the spindle to the table. Today, I attempted to home the machine however, when the Y axes homed, one triggered before the other causing LCNC to complain about not being able to home one axis while the other is moving off the the home position.

What the the best way to resolve this issue such that both axes travel together, both for homing and moving off the home switch.

2. Using PNCCONF for configuring LCNC with tandem Y axes, when testing the Y axis only one of the steppers responds. Is there something that I missed in PNCCONF that will allow both Y steppers to be tested together?

3. What is the .ini PARAMETER that tells LCNC that two axes are in tandem?

Kind Regards,

Stell doch mal ein Bild ein.
Stuttgart ist arschweit weg. 
Sitze in sachsen

So whilst trying to install you effectively had no internet connection
Same result that myself and friend of mine experienced