Advanced Search

Rykagon wrote:

Hello All,

- which Linux distro to load on the Pi 4.

 

Sounds like a fun project. 
Download the SD card  image at this page .
That should be a good start Pi4 + Mesa 7i76EU + TB6600. I've played a bit with the Pi, never used it in a retrofit, but I read people doing it regularly on this forum.

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!

I wanted to share my experience from the last several days in case it helps someone else planning a Mesa Ethernet / QtPlasmaC plasma retrofit.

This is not a complaint about LinuxCNC, far from it. After working through the issues, I am still happy to be moving forward with LinuxCNC and QtPlasmaC because I think the plasma feature set is excellent. But I do think my experience shows that the “PC side” deserves more attention than I initially gave it.

My setup:

- Home-built plasma table conversion from MASSO to LinuxCNC / QtPlasmaC
- Mesa 7I76EU
- THCAD2 planned
- Ethernet Mesa connection
- QtPlasmaC
- Separate camera-assisted project running alongside LinuxCNC during some tests

One of my reasons for moving away from a closed standalone controller was that I wanted to experiment with a camera-assisted tracing/scanning workflow, somewhat similar in concept to SheetCam’s Scanything. I have been working on a small project I call FabScan, which uses a USB camera mounted to the machine to help trace parts/templates and eventually export geometry. That type of experimentation is much easier on an open PC/LinuxCNC system than it would be on a closed standalone controller such as MASSO.

I originally planned to use a small MeLe mini PC that I already had. It booted fine, LinuxCNC installed, QtPlasmaC launched, Mesa connected, and the machine homed and jogged. At first glance it seemed usable.

The problem was intermittent realtime/Mesa communication errors. I saw errors such as:

- Unexpected realtime delay
- hm2 error finishing read
- Watchdog has bit
- Smart Serial communication error / timeout
- Smart Serial Port 0 stopped

The PC had a Realtek RTL8111/8168 Ethernet controller using the r8169 driver. I tried the usual tuning steps:

- Dedicated Mesa Ethernet interface
- Static IP, no gateway, no DNS on the Mesa NIC
- Disabled Ethernet offloads
- Disabled EEE
- Disabled coalescing
- Disabled Wi-Fi during testing
- Disabled power-management options in Linux
- Increased servo period from 1 ms up to 3 ms and later 4 ms
- Switched from r8169 to r8168-dkms

The r8168 driver helped a lot. The system would run longer, but it still eventually produced realtime delay / watchdog / Smart Serial failures. In my case, the MeLe was simply not boring enough to trust as a control PC.

I also found a separate issue that was not the PC’s fault. My generated config had PID loops driving Mesa velocity-mode stepgens, with DEADBAND = 0.0 on the joints. After homing or jogging, the axes would twitch slightly because the PID loop was chasing sub-step position error. Adding deadband fixed that:

X/Y/Y2:
DEADBAND = 0.0008

Z:
DEADBAND = 0.00025

That stopped the axis twitching.

Eventually I replaced the MeLe with a used Dell OptiPlex 7060 Micro with Intel Ethernet. With the Dell, I tested QtPlasmaC, FabScan/camera load, and NoMachine remote desktop while watching Smart Serial. The Dell stayed clean at a 2 ms servo period. Smart Serial stayed at:

fault-count = 0
port_state = 3
run = TRUE

For over an hour, the takeaway for me:

LinuxCNC can run on modest hardware, but for Mesa Ethernet I would not say “any old PC” is good enough without testing. I would now strongly prefer:

- Used business-class Dell/Lenovo/HP mini PC
- Intel wired Ethernet
- Good BIOS power-management controls
- Dedicated Mesa NIC
- Long latency tests, not just short ones
- Real workload testing: QtPlasmaC, camera, remote desktop, Wi-Fi if used, etc.

I am not posting this to criticize LinuxCNC, again, far from it. QtPlasmaC is exactly why I am doing this conversion. I just think new users coming from MASSO, Mach, GRBL, etc. would benefit from clearer up-front guidance that the control PC needs to be “boring,” not just powerful enough.

In my experience, horsepower was not the issue so much as the details. The NIC, driver, BIOS/power-management behavior, and long-duration realtime stability mattered a lot. I wish I had understood those details better up front, so I am posting this in case it helps the next person avoid a few days of chasing intermittent gremlins.

I have spent many hours searching posts and looking for answers. i just can't figure this out. I followed tommylight post on how to configure a wired ethernet connection. When I click save it comes up with a message "a gateway is incompatible with never-default.
The computer is a Lenovo m910q,  Intel Core i5-7500T . I am a total newb at linuxcnc, but successfully completed 2 mach 3 machines in the past. please help this senior citizen. Thanks

Kannst du das aug Google Drive oder woanders hochladen, so dass jeder Zugang dazu hat?

In dem ZIP Ordner sollten einige VHD Dateien sein. Die änderst du einfach um und machst den Doppelklick an der richtigen Stelle. Das Bitfile wird das im selben Ordner erstellt. Es gibt eh eine unnötig lange Anleitung dazu: forum.linuxcnc.org/27-driver-boards/4558...nix-bitfile-creation
Habe meine Datei als Beispiel angehängt. Vergleiche den Inhalt mit deinen Dateien aus dem ZIP Ordner. Falls die Benezandatei fehlt, findest du die dort, wo deine 7i92 Originalfirmware ist. Es müsste source.zip oder so heißen.  

hello..i have a problem with my plasma cutter..I am using a 7I76E. The plasma torch goes down, senses the work piece, rises to the pierce height , fires the torch up but does not maintain the arc to cutting flame. Because of this, it then goes off instead of moving to cutting height and cutting flame.

Hello PCW,

Thank you for your advice.

You were absolutely right — I did not need the 7I74.

I connected the 7I85 to the 7I76EU P1 port and then connected two 7I84U boards directly to the Smart Serial ports on the 7I85.

Everything is now working correctly:

* 7I85 is detected and provides the expected MuxedQCount resources.
* Both 7I84U boards are detected through Smart Serial.
* Inputs and outputs on both 7I84U boards have been tested successfully.
* LinuxCNC sees both boards after enabling the corresponding Smart Serial channels.

The final configuration is:

* Mesa 7I76EU
* Mesa 7I85
* Mesa 7I84U #1
* Mesa 7I84U #2

using the firmware:

7i76eu_7i76x1_7i85x1d.bin

Thank you for pointing me in the right direction and helping me simplify the system.

Best regards,
Roman

I can make 7I76EU  + 7I85 + 7I74 firmware but not sure why you would need the 7I74
as there are 6 available Sserial ports with just the 7I76EU (1) and 7I85 (5).

7i76eu_7i76x1_7i85x1d.bin is the firmware for a 7I76EU and a 7I85.

 

Hello,

I am using a Mesa 7I76EU board and would like to know if a firmware configuration exists that supports simultaneous operation with a standard 7I85 board and a 7I74 board.

My planned hardware configuration is:

* Mesa 7I76EU
* Mesa 7I85 (standard 7I85, not 7I85S)
* Mesa 7I74
* Two Mesa 7I84U boards connected through the 7I74

I have successfully tested the following firmware:

7i76eu_7i76x1_7i85x1d.bin

The firmware was loaded successfully, and LinuxCNC correctly detected all six MuxedQCount channels provided by the 7I85.

After loading this firmware, LinuxCNC reports:

* 6 MuxedQCount channels
* 1 MuxedQCountSel channel

The 7I85 board will be used to connect four RS-422 linear scales (X, Y, Z, and W).

The 7I74 board will be used as a Smart Serial Hub for two 7I84U I/O expansion boards.

While reviewing the Mesa firmware archive for the 7I76EU, I could not find a ready-made firmware configuration for:

7I76EU + 7I85 + 7I74

However, I found the following VHDL source file:

PIN_7I76x1_7i85sx1_7i74x1D_51.vhd

which suggests that a configuration for a 7I85S + 7I74 combination exists.

I would appreciate advice on the following:

* Is there an existing firmware configuration for the standard 7I85 and 7I74 combination?
* If not, is it possible to obtain such a configuration from Mesa or build it from the available source files?
* Are there any FPGA resource limitations on the 7I76EU that would prevent simultaneous use of both the 7I85 and the 7I74?

Any information or recommendations would be greatly appreciated.

Thank you.
 

I'm very new to this so please pardon the questions.  I recently acquired an INTEL NUC core-i3 with 8GB of ram. This is intended to drive a MESA 7i76e board on a plasma table.  

tldr; I'm primarily curious to know if the latency results I'm getting are going to work (if that's possible to advise).

I've downloaded the latest iso and  went through performance tuning.  I *think* I've done all the things.  It's sometimes hard to follow all the different threads on tuning.

1) Turned off things in BIOS (hyper threading, power management etc.). This left me with two CPUs
2) Grub configured (including isolcpus)
3) CPU governor set to performance
4) IRQ coalescing disabled (intel NIC)
5) CPU core isolated for LinuxCNC (cpu 1) (I am not sure how to confirm this is actually working as intended)
6) Ethernet IRQ pinned to isolated CPU (cpu 1)

The latency histogram as a result looks like this (6 glxgears & running YT videos):
 

~60 us of max latency.   Is this worth continuing to try to use or should I be looking at a better computer?  Any advice appreciated.

I have not hooked it up to the machine yet to try it.  Hope to be attempting that in coming weeks.  Thought I'd post this to see if I need a different computer first.

- Dave

 

Drives usually have only optocouplers on the inputs, so chances are low for it to short, higher chances of loosing sensitivity (light output as inside the is an LED and a photodiode).
Much higher chances of interference from the spindle and/or VFD that caused a spike, might even be moisture messing things up.

Also another thing, is that I have changed the stepper driver to a new one as I thought initially that might be the problem.

*possible* that the original is faulty and took down the output. Not prepared to test it on another channel though (:

Firstly made a minor mistake on the numbering i.e. 3rd stepgen therefore stepgen.2

This is a small cnc in my home so pretty clean environment using DM556 drivers.
Scoped it with the driver disconnected and hooked between gnd (first pin) and step+.
Figured that since the dir pin toggled when I jogged the Z up and down, that all programming was connect.
Scope looked fine on stepgen.3 and Z now works on that channel.

No, not a common fault at all, i am sure i have over 80 Mesa boards (more probably) and none of them ever failed, and they are mostly on industrial machines, and all are in use daily, some are never switched off, for over 10 years. And most are on plasma machines, by far the worst machines for EMI/interference.
What machine is yours?
Did you disconnect the stepper drive when checking with scope?