Advanced Search

Yeah, Realtek had/has issues with 6.x.x kernels, a lot, but worked fine with older kernels.
Probably due to power saving options being implemented everywhere...

I am far from a LinuxCNC expert, but I like to think I have decent troubleshooting skills & from what I saw the MeLe Realtek NIC was the biggest issue.. There may have been some other power-management issues as well, but it really looked like the NIC would drop out just long enough to cause a problem...

A quick Google said:
Burgmaster turret drills are well-regarded for automating multi-step machining. They house a cluster of spindles that automatically index and rotate to the next operation—such as drilling, countersinking, or tapping—without requiring manual tool changes.

So my question is, is the turret under CNC Control? was this broken with the Mach3 conversion? Can the function be restored? That's the LinuxCNC opportunity.
Seems to be designed for drilling and tapping so caveats around milling would be similar to that for drill presses.

 

- Used business-class Dell/Lenovo/HP mini PC
That is what we usually advise here, and by now there are plenty of PC's and some laptops tested and working fine with LinuxCNC.
In general, 4GB and up, Core2Quad would be the absolute minimum usable, avoid i3 Intel's although some do work fine, no spinning hard drives, and no NUC type PC's although some do work fine.
Also, i had/have plenty of new builds, some quite powerful that do work fine with LinuxCNC but would be overkill for a machine controller only, so can also do CAD/CAM on the same PC.

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.

Sometimes I think prior knowledge of other Ethercat environments just adds to the confusion. Twincat is useless to me.
Does the XML you provided work?
It looks like it should.
If there truly is a 14 byte offset, you just need to add some dummy registers to account for them.

Please take the time to format you replies, the data you provide is very difficult to read.

Yes I remember these short comings.
Patches are always welcome.

Yes, It is possible. I am regularly using the press brake that I retrofitted in this thread.

forum.linuxcnc.org/30-cnc-machines/42100...ons?start=100#228476

The homing still has issues, but the ram functions good. I use the backstop only on occasion if I am bending a high quantity of parts. I just calculate the offset from the backstop's start position without homing it. I believe it could be fine tuned to work better, but for the low volume of parts that I bend at a time, it does the job.

You can force a version in the Synaptic package manager.

Or grab the new 2.9.10 .deb from Github.

Some information about the nature of the machine might help prompt some more advice.

What type of motors does this use? Steppers, DC Servos? Brushless servos? (linear motors?)

Are the existing drives working, and do you intend to keep them?
The same for the motors.

What feedback do the motors provide to the controller? Is there also feedback from the axes (linear scales, for example)

Is there a toolchanger? How many spindles does it have?

Maybe attach a picture to help us visualise the project.

One thing to be very aware of is that the potentiometer on the KBIC controllers is at a very high voltage. It is referenced to DC+ so has 100V or so to earth.
If your digital potentiometer can't handle this then you might have problems.

I used this circuit to run a KBIC using PWM, which might be a better plan. Any logic-output (push-pull) optocoupler will work, but you probably need optical isolation to avoid letting the magic smoke out (DAMHIK)

photos.app.goo.gl/BpBKZob1TomX1gtSA

(It's shown with a VFD but it's basically a PWM-controlled potentiometer emulator)

Sorry, been changing PC's and laptops a lot lately, had this set to reply and lost track.
Not much i can help with, but, since you are modernizing everything, you could do without schematics, either way it will require a bit of "hunting for signals" to figure out the remaining wiring, probably the relay boards for interlocks and/or tool changer, the rest is being replaced.
Here is my lathe and a bit of info on how i go about when no schematics is available:
forum.linuxcnc.org/show-your-stuff/32784...-15-retrofit?start=0
And a Hurco BMC-20P mill that i had only a single page of schematics for it:
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit

I was involved in one of the threads, and I don't know if the chap with the machine ever got it going.

I confess that for me it was an exercise in making a LinuxCNC-controlled system that didn't require G-code. It might be simpler to actually use G-code.

forum.linuxcnc.org/30-cnc-machines/42100...ions?start=10#204844

During the development of that, one thing I realised is that using LinuxCNC axes gives you homing for free. Though I think that some kind of special handling for following-error on the press axis might be important.

The special component in that setup above was designed to be largely pressure-based.

Anyway, I think that the GUI might be a useful start, even if you end up changing the stuff behind the scenes.

Snowwy, i am sure i have not formulated that very nicely, to much that makes me loose my marbles there, but mostly the "fear everything" mentality sweeping the world.
And i am for sure the most paranoid one here, yet i have to ask not to update as it is an ongoing hassle for many users.
-
I would really appreciate if someone else would write something about this, and i will gladly delete this.
-
People with a single machine that their business relies on, should really never update/upgrade, unless they want to risk it, others are welcomed to and even encouraged to as it provides invaluable feedback.
But most important, explain they do not have to and it is not a must, as they have been conditioned to from microshaft and it's useless code and non existing code auditing.

This sounds like a lot of fun, unfortunately all I can do is offer good wishes with the project. But keep us informed, and maybe there will be other questions that are easier to answer.