Advanced Search

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.

There is a new release (2.9.10) that reverts this change.
Unfortunately it's not yet available from our repository as I am having trouble with the archive signing key.
However, you can manually install .deb files from here:
github.com/LinuxCNC/linuxcnc/releases/tag/v2.9.10

Sorry for the slow reply, I haven't been able to find much time recently.

I think that the carousel component could be used for this, but you would need two instances of the component and I think that limitations of LinuxCNC (can't have two tools in the same pocket number) would mean that you would need to do some processing of pocket number in HAL to feed the right numbers in.

Luckily I did consider the possibility of multiple carousels being used, so you just use
loadrt carousel num_pockets = 10,10
to load two 10-pocket carousels

for example you could use pockets 0-10 for one carousel and 100-110 for the other. Then in HAL you would check the pocket number (comp component) and if >= 100 enable one carousel, and if <100 enable the other. Then pass pocket number - 100 to both carousel components (only the one that was actuated would move)
The sequencing could be done in any way that works for you, but G-code is one way. See the sim config configs/sim/axis/vismach/VMC_toolchange for an example that runs the tool magazine with the carousel component and handles the rest of the sequence in a g-code routine. You could equally well use classic ladder or a python script if that suits you better.

On the other hand ... I've gotten tons of invaluable feedback from those brave/patient enough to adopt the latest version and provide bug feedback ... much of it coming from people running a business with said machine (some of the best feedback is from folks who actually use it constantly).

1. Not important as everything is changed, except the metal parts.
2. Looks quite sturdy so it should do lite metal milling, depending on the toolchanger
3. Nothing to retrofit, just install LinuxCNC and make a new config for it.
4. Leadscrews have backlash, so that will limit precision, LinuxCNC has the compensation, so can be tuned.
5. Seems to much for here in Europe, so that is something we can not help with as it might be cheap where you live.