Probably should clarify my setup, I have steppers on my axis and am going to add linear encoders on each axis. Spindle will be a VFD on a 3 phase motor, with an encoder to check the speed.
The reason I was going towards the 3 boards is also so i get all the IO i need. And since its in stock now I can start wiring it all up over summer/christmas leave

Hi all, I’m planning a LinuxCNC retrofit of a small mill (HM‑46B, a RF-45 style machine offered in NZ & AUS)  and want to confirm a Mesa combination before I order. Ive done what I can with reading the Mesa site and here, + a bit of help from claude. 

What the machine needs:

• 4 step/dir axes (X, Y, Z, A), external stepper drivers
• 6 encoders: one per axis, one MPG and one spindle encoder
• Analog 0–10V spindle to a VFD
• About 20 inputs and about 10 outputs at 24V

Planned hardware: 
Ive got 2 options in looking at, which ive called A and B:

• A -  7i96S + 7i85S + 7i84U + DB25F-IDC26 cable
• B -  7i95T + SPINX1A + Modbus relay
I would greatly apreciate it if anyone can comment on if either setup would work for my machine, and if the firmware already exists for this setup. Im leaning towards A as it keeps everything running on mesa, and the 7i95T is current out of stock (So is the 7i76EU ).Ive already ordered a HP i5 Mini PC, the specs are : Processor: Intel Core i5-8500T (6 Cores)Memory: 8 GB RAMStorage: 256 GB Fast SSD  

To put it briefly, I was forced to leave my home workshop behind due to the war. But since I love working with machine tools, I later bought myself a couple of used "baby" CNC machines — a Wabeco lathe and a Wabeco mill. I immediately set the stock control systems aside.
The Wabeco lathe has been up and running for over a year now, powered by LinuxCNC + Mesa 7i92 + Chinese 400W servo motors.
As for the Wabeco mill, I’ve rebuilt it, repainted the enclosure, and so on. Right now, I'm very slowly putting it together using the stock stepper motors and a Chinese XC809D controller (which was a gift). To be honest, it hasn't really impressed me so far, so it might just be a temporary solution.
I don’t have an urgent practical need to switch to EtherCAT.
My main driving force is pure curiosity and a desire to figure it out to the point where I can work with it effortlessly. Naturally, the first question that came up was: what is the most elegant way to handle encoders? As a backup plan, I'm considering installing a second network card and running EtherCAT alongside Mesa simultaneously (using Mesa to handle encoders: one for the spindle + manual pulse generators for each axis).
So, here is what has been done so far:
• Installed the IgH EtherCAT Master (EtherLab) + linuxcnc-ethercat + cia402.
• Ordered a Lichuan LC10E servo kit with a 23-bit absolute encoder from AliExpress (currently in transit).
• Bought locally (and quite cheap) an Omron NX-ECC201 coupler (1 pc), ID5342 digital input modules (3 pcs), and OD5121 digital output modules (2 pcs).
The Omron hardware should arrive in a day or two, so I’ll start experimenting with EtherCAT using that, and then the servo kit will arrive. First, I'll take it step by step to learn the ropes, and later I might convert the lathe to EtherCAT. But the ultimate goal here is self-development and the enjoyment of learning something new. The practical benefits are taking a back seat for now, but they might come in handy for future retrofits. Once everything settles down, I really want to bring a small CNC lathe with live tooling over from Europe.

Hi Shu,

Thanks for the info and the servo tuner script. I had to take a break from working on the mill for the moment.

At the moment all the axis are moving and the servo spindle runs (still need to check the config on it). I am working on the lubrication system at the moment. It is making a huge mess so I have to figure that out before I work on the movement more.

Thanks for the help

Hi tuxcnc,You are absolutely right that the simulator cannot know which physical tool has been installed if that information is never provided.I think I didn't explain one important part of our concept clearly enough.The simulator is not intended to receive all its information exclusively from LinuxCNC. It should eventually have its own virtual machine operator interface.Think of a real CNC machine with a manual tool change.LinuxCNC requests T5, moves to the tool change position, and waits for the operator. But LinuxCNC cannot physically verify which tool the operator puts into the spindle.Our simulator should behave similarly.The user would be able to select and install a physical tool through the simulator interface. That tool could be T5, but it could also be T3 by mistake.The simulator would then use the actual geometry of the installed virtual tool, independently of the tool information stored in LinuxCNC.The same principle applies to workpiece positioning, tool lengths, and eventually fixtures and collisions.Of course, this requires a virtual tool library and an operator interface, neither of which is implemented yet.Your example of the M6 REMAP moving to a toolsetter is particularly interesting. The simulator already receives the axis movements through Stepper-Ninja, so those movements do not need any special G-code handling.Once we have physical tool geometry and a virtual toolsetter, we could also simulate the actual contact with the sensor and return its signal to LinuxCNC.I agree that additional communication might be useful for automatic tool changes and other machine functions. However, I would prefer to keep the original Stepper-Ninja protocol unchanged if possible, and investigate a separate interface for simulator-specific interactions.The main idea is to simulate the physical machine independently of the controller's assumptions, including situations where the operator makes a mistake.Thank you for challenging this concept. These discussions are very helpful for defining the architecture before implementing the next features.

Hi Peter,

I am building a small 3.5-axis mill/drill with a 7i96S and five STEPPERONLINE A6-RS servo drives (step/dir + Modbus RTU). Current setup: LinuxCNC 2.9.10 uspace on Debian 13 (PREEMPT_RT), 7i96s_pktv3.bin flashed. hm2_modbus to one A6 on TB2 works without errors (115200 8N1, rxdelay 40 / txdelay 45 / icdelay 20, about 7 ms per single-register read at 1 ms servo period).

I would like to ask for a custom bitfile with the following configuration.

TB2 and all on-board I/O: identical to 7i96s_pktv3
- StepGen 0-4 (X, Y, Z, W, spindle), QCount 0 with index (spindle), PktUART V3 on TB2 with internal TXEn, SSR, OutM, InM, PWM unchanged.

P1 (W6 set to GND, a small interface board sits directly at the header):


Notes:
- All PktUARTs V3. No TX enable pins on P1: the three Modbus ports use RS-485 transceivers with automatic direction control (e.g. MAX13487E); the lever link (PktUART 3) is full-duplex RS-422 with the driver permanently enabled, 2-5 Mbit, one packet per servo period in each direction.
- Instance numbering as in the table, please: PktUART 0 stays on TB2 (so existing configs keep working), StepGen 5 and QCount 1 are the highest instances, so I can turn them into GPIO with num_stepgens=5 / num_encoders=1 when they are not needed.
- If it does not all fit into the T20, please drop in this order: QCount 1 first, then PktUART 4, then StepGen 5. PktUARTs 1-3 are the ones I really need.

Questions:
1. Does this fit (5 PktUART V3 in total, 6 StepGens, 2 QCounts)?
2. hm2_modbus without a TX enable pin: is the receiver masked while we transmit (RXMASK driven by the internal drive enable), or should the transceiver's receiver be disabled during TX to avoid the echo?
3. Lever link: for full-duplex use I plan to set the drive enable bit statically and the auto bit off in my own HAL component. Is that the right way with PktUART V3, or would you configure it differently?
4. Is the 7I87 expected to be available again?

If it is easier for you, I can also build it myself with Efinity from the 7i96s sources - in that case a hint which PIN file to start from (PIN_7I96SD_PKTV3?) would be much appreciated.

Thank you very much for your support,
Thorsten

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!

Hi,

I've been working on a standalone CNC machine simulator for LinuxCNC and have now published the first experimental version.

The main idea is that the simulator does NOT interpret G-code itself.

LinuxCNC remains responsible for G-code interpretation, trajectory planning, coordinate systems, offsets and compensation. The simulator sits behind LinuxCNC where real motion hardware would normally be connected.

Currently I use the original Stepper-Ninja HAL driver and its UDP protocol as the interface:


The important part of this approach is that the simulator sees the motion that LinuxCNC actually sends to the virtual hardware instead of trying to reproduce LinuxCNC's trajectory planner.

 

Communication is bidirectional. The simulator can also send virtual machine inputs back to LinuxCNC. I can already use this for limit switches, homing and a simple configurable probe plane.

The current version also contains a sparse voxel workpiece and persistent material removal. Tool movement is processed as continuous swept volumes rather than just removing material at individual sampled positions.

One interesting problem was performance during curved motion. LinuxCNC can generate many small motion segments. Instead of approximating those segments with a larger chord, I batch the actual swept segments for a short time window and calculate the union of their removal volumes. This keeps the resulting voxel state identical while greatly reducing repeated work.

At the moment the simulation is still quite limited:

- flat-end cutter only
- no geometric stock probing yet
- no toolsetter yet
- no spindle/holder model
- no general collision detection
- no rotary material transform

The next area I would like to work on is geometric contact detection. My idea is to use the same contact system later for workpiece probing, a machine-fixed toolsetter and eventually collision detection.

Stepper-Ninja is currently just the interface between LinuxCNC and the simulator. A physical machine does not need to use Stepper-Ninja hardware. I chose it because an existing LinuxCNC HAL driver and a small bidirectional protocol already existed, so I did not have to invent another LinuxCNC hardware interface.

This is my first public release and I consider it experimental development software, not a machine safety system.

Source and v0.1.0:
github.com/FredericM88/linuxcnc-sim

I would be particularly interested in feedback about the architecture. Does placing the simulator behind LinuxCNC at the hardware interface make sense to you? Are there LinuxCNC behaviours or use cases that would be especially useful to test with this approach?

Frederic

Hi New guy here...

I am trying to get a 3 axis mill up and running. I am using three CL3 57E drivers for the axis(es) and have a A6 750w Servo motor for the spindle. 

Debian is up and working and Ethercat is installed. The cia402 is also integrated. Everything boots and looks good. I am running Linuxcnc 2.9.10.

UI is qt_dragon. Slaves are all there and go over to OP when linuxcnc starts... There are no errors other than a 5000 ns time out for the CL3 57Es no time out error for the A6 though? The Stepper motors do not energize... No buzzing, nothing and can be moved by hand. 

Button for the coolant work in the UI but the motors will not (just the CL3 57Es) activate and move. I don't know if I have missed something... I have spent the last 3 days searching the forum looking for answers and trying different things. It would be great if you guys could take a look at my config  files and let me know what I missed.

Thanks 
  

There are a number of applicable standards. I am no expert on them. Aside from local country specific standards like AS4024 here in Australia, International standards include ISO 13850, IEC 60204-1 and IEC 60947-5-5
on a home machine, often a 2 pole estop button is used. one pole cuts mains power to spindle and stepper motors and the other is low voltage circuit wired to linuxcnc to tell the controller estop has been pressed. But this does not safely bring heavy machines to a stop so it gets more complicated. Also its not helpful if you have the control panel at one end of a plasma table and you want to place an estop at the other end where the console is. One approach might be to run a pull rope right around the table but running mains power to another distant switch clearly adds its own safety risks.
I suspect estop-latch predates the standards but it does allow you to create an estop chain in software. It is somewhat complicated to understand initially and I find its best to draw it on paper as a series of boxes (one for each estop-latch) each of these boxes has an OK-out pin which needs to connect to the reset pin on the next in the chain with the last OK-out connected to iocontrol.emc-enable
Each latch will have either a fault-in or ok-in pin attached to the estop button or door latch or whatever that needs to be safe before the machine will start. Finally, the iocontrol.user-request-enable pin is attached to the reset pin on the very first latch. So when the user requests the machine to be enabled (usually the orange button in axis), a short pulse is sent to the first reset and if all faults are clear, the sigal to start the machine arrives at linuxcnc. The beauty of this approach is that you can just as easily use a momentary push button to act as that reset signal if you wish.   

Taking that into the standards says the controller can have no part in the safety circuit, and every sub-circuit and every contactor needs to have  dual redundancy so a fault will not trigger anything and both circuits need to work before something's enabled. Also if there is a power outage, the machine cannot become live again when power is restored. You need to press that reset button. Also every contactor and every relay needs to be a force guided one where a non conducting pin is forced between relay contacts to guard against them welding closed from an arc.. Aside from that the safety circuit or safety relay does the same thing as estop-latch. It won't enable the machine until every component being monitored is safe.

I’ve recently acquired an older AXYZ 4008 CNC router and am in the process of replacing the original AXYZ controller with LinuxCNC and a Mesa 7I95T.

I thought I’d document the conversion here, both in case it helps somebody else and because I’m very interested in advice from anyone who has already converted one of these machines.The intention is not to gut the machine unnecessarily. Mechanically it appears to be a very substantial router and much of the original electrical hardware looks perfectly serviceable. The aim is therefore to replace the obsolete controller while retaining as much of the original AXYZ hardware as practical.The machine is an AXYZ 4008, approximately 2007 vintage, with a roughly 3 × 2 m working area and an ELTE spindle. X and Y are rack-and-pinion driven and Z uses a screw.Motion is provided by Vexta/Oriental Motor PK299-F4.5A 2-phase steppers, rated 4.5 A, driven by the original Pacific Scientific 6410 stepper drives.The 6410s are particularly encouraging because they accept fairly conventional step/direction control. The existing AXYZ controller feeds the drives through DB9 connectors. We initially considered reverse-engineering these signals with a logic analyser, but having found the drive documentation and previous AXYZ LinuxCNC conversions, that now seems largely unnecessary.We have bought a Mesa 7I95T, which should give us considerably more I/O than we immediately require and leaves scope for additional axes/tools later.The rough architecture we're aiming for is:
  One interesting discovery has been the AXYZ connection board inside the cabinet.Rather than simply removing it, we're investigating whether it is worth retaining. It appears to handle quite a lot of the machine-side infrastructure, including limit sensors, tool sensor, E-stop-related connections and various auxiliary functions.It is associated with a substantial toroidal transformer and appears to provide several control voltages including 5 V, 12 V and 18 V.The board has conveniently labelled connections including:
  There are also connections elsewhere on the original controller for the vacuum pump, dust collection, inverter(s), ATC controller and RS485.So at the moment we're considering retaining this board as the interface to the existing machine wiring and taking the appropriate signals from it into the 7I95T, rather than rewiring every sensor and auxiliary device individually.One difference from some of the documented Mesa conversions is that the 7I95T doesn't provide the convenient 0–10 V spindle-speed output found on boards such as the 7I76. We'll therefore need a separate interface for the VFD's analogue speed command. Spindle run/enable should be straightforward using an isolated output/relay.The other area we're treating separately is the E-stop system. The original E-stop appears to have been interpreted by the AXYZ electronics, but for the retrofit we want an appropriate hardware safety chain rather than relying on LinuxCNC software alone.Our initial milestones are deliberately simple:

1. Get LinuxCNC communicating reliably with the 7I95T.
2. Connect one original 6410 drive and establish STEP/DIR operation.
3. Jog X/Y/Z correctly.
4. Identify and interface the existing home/limit sensors.
5. Implement a proper hardware E-stop.
6. Start/stop the existing VFD/spindle.
7. Add 0–10 V spindle-speed control.
8. Make the first test cut.

After that we can tackle the tool sensor, vacuum/dust control and eventually the ATC.We have already found the earlier AXYZ 4008 retrofit thread here extremely useful, particularly because it demonstrates that retaining the original AXYZ steppers/drives and interfacing them to Mesa/LinuxCNC is quite practical.I’m documenting photographs of the machine, original controller, connection board, drives, motors and mechanical drive system on our workshop site here:continuumkit.org/workshop-inventory/axyz-cnc/I'll add wiring diagrams, Mesa configuration and anything else we learn as the conversion progresses.If anyone has experience specifically with the AXYZ connection board, Pacific Scientific 6410s, or interfacing an AXYZ spindle/VFD to a 7I95T, I'd be particularly interested to hear how you approached it.

hi Group

I just purchased a boxford 250pc lathe in a hardely used immaculate condition; however, as per the norm, it has no brain and the internal electronics, although pretty much unused, will be changed over to new stuff so I eliminate any issues and get going properly first time.
I will then likely use all the removed bits for other projects.

• controllers
  At the moment, I am considering LinuxCNC, Mach 3/4, poss arduino,  and Centroid Acorn
  So can anyone advise if LinuxCNC on a Raspberry Pi will be powerful enough and good enough to use on a Boxford 250PC lathe with 2-axis, a tool changer, homing limit switches, spindle encoder with z values for threading, spindle speed control, a pump, E-stops, and the potential for another two-axis as well?
  
• I like the idea of Raspberry Pi as it is small, adaptable, and can be built into cases, etc.. but would I be better off using a PC?? 
  or is the Raspberry Pi the way to go?
  or will Arduino be even better?
  
• I am pretty good at doing stuff, and learn quickly. I have had some experience programming steppers from an Arduino before, but with LinuxCNC is there lots of help information available on the web and youtube etc, and is the forum friendly, helpful, and resourceful when needed?
  
• What does the linuxCNC use for lathe control software (i.e like mach 3/4 or centroid CNC12)?
  Does it work well?
  is there any links to see it in action on YouTube?
  can it be messed about with to map out the control screen as i would like?
  Can the control screen running the lathe control software be used in portrait mode on a reasonable-sized screen?
  
• With LinuxCNC on a Raspberry Pi, are there any limits to motor sizes in both stepper and servo motors?

I look forward to any input/feedback

Z

Hello All,

  I'm attempting to retrofit a 90's vintage Intelitek Prolight 3000 lathe.  This is a small slant bed CNC lathe marketed to high school and technical college programs, and originally controlled by proprietary electronics and a desktop PC.

The plan is to use LinuxCNC on a Raspberry Pi 4, mated with a Mesa 7i76EU board, along with TB6600 stepper drivers to control and X- and Z-axes as well as a stepper driven 8 position tool changer.  The spindle motor speed is analog controlled 0 - 10 volt signal input.

I have zero experience with most of this and would appreciate any coaching on:

- which Linux distro to load on the Pi 4.
- any resources for configurations, etc.
- any other stuff I don't even know that I don't know.

Thanks in advance!
 

Hi everyone,
I'm working on a KEGEMA-branded CNC router (1300x2500mm working area) that currently runs on a RichAuto DSP A11 handheld controller. I'd like to bypass the handle and control the machine directly from a PC (jog, home, run G-code, start/pause) — similar to what was done in this thread:
forum.linuxcnc.org/30-cnc-machines/35371...troller-richauto-a11
I've read that thread carefully and it's been very helpful, but my setup differs in one important way: my machine uses AC servo motors, not steppers.
Machine specs
Working size: 1300x2500x200mm
Spindle: 6kw HQD air-cooled
Spindle inverter/VFD: 7.5kw Fuling (brand: Folinn on the unit itself)
Axis motors: Leadshine 750W AC servo motors + matching Leadshine AC servo drivers (model marking "L7", 750W, one per axis: X, Y1, Y2, Z — Y1/Y2 appear to be a dual-motor gantry setup)
Reducer: Shimpo (Japan)
Control: RichAuto DSP A11 handheld controller
What I've already confirmed
Inside the control cabinet, the A11's interface board has clearly labeled screw terminals (not just a blind 50-pin harness like in the thread above):
INPUT SIGNAL row: X1 (XH/X-home), X2 (YH/Y-home), X3 (ZH/Z-home), X4 (TS/tool setter), X5-X8 spare, 24V/GND/SHIELD
OUTPUT row: Y5-Y8 + GND (relay outputs — dust collector, water pump, etc.)
Separate 4-pin terminal blocks per axis labeled X_AXIS, Y_AXIS, Z_AXIS, C_AXIS, each with 5V / PULSE / DIR / SHIELD
Each axis terminal block has its own cable running directly to its Leadshine servo driver's CN1 connector
Since these are screw terminals (not a sealed connector), my plan is to add a second wire in parallel at each terminal (tap-off) rather than disturb the existing A11 wiring, so the A11 handle stays functional as a fallback.
What I'm unsure about / looking for help on
Pulse/Dir signal type from Leadshine 750W AC servo drivers (L7 series) — are these standard 5V single-ended step/dir inputs, or differential (like the RS422 signals in the referenced thread)? Trying to confirm from the datasheet before wiring anything.
Recommended motion controller for a 4-axis (X, Y1, Y2 as dual Y, Z) AC servo setup — Mesa 7i96 vs 7i76e vs something else? Do I need differential drivers (like the AM26L31CN used in the referenced thread) between the A11 board and the controller card?
Dual Y-axis (gantry) handling — should Y1 and Y2 be wired as one LinuxCNC axis with a single driver output, or does anyone have experience keeping them as two synced axes?
Spindle speed control — my board also has S0-S3 speed-select terminals (7-speed selection, not analog 0-10V). Anyone dealt with converting this to continuous VFD speed control from LinuxCNC/Mach, or is it easier to just leave spindle speed control on the VFD's own panel?
Any gotchas specific to RichAuto A11 + AC servo (vs. stepper) retrofits that I should know before starting?
Happy to share more photos of the interface board and servo drivers if useful. Any pointers, schematics, or "here's what worked/didn't work for me" experiences would be hugely appreciated.
Thanks in advance!