Advanced Search

There are so many things that force a system upgrade, Components fail, new drivers needed and so on.
Without upgrades you would miss out on so many amazing improvements to LinuxCNC. QTplasmac and QTdragon are cases in point and running master branch with them is almost mandatory. What about 9 axis look ahead or S-curve jerk limited trajectory planning?

You just need a plan and a fall back position, I generally create a new config in Mesaconf or stepconf with very rough settings. Then once motion is confirmed, cut and paste all of my original ini and hal settings accross. That gets me running. Then its just a matter of adding all the new nice to have features. 3D probing, spindle torque display and so on. It only takes an hour or so.

Sorry but I like to stay pretty current. It makes support much easier. 
Did I tell you I get a bit annoyed when people say I have this working machine on 2.5 and it broke when I upgraded to 2.9? The truth of the matter, it broke several times all at once. Have you any idea how old 2.5 is? I've been using LinuxCNC for over 10 years. 2.7 was where I started but 2.8 came out before I finished my first config, so I upgraded straight away because It had features I wanted. I'd venture to say you will have less downtime if you stay current as you only make small steps at a time. upgrading 4 versions? you might as well adopt Mach 3!

EW_CNC wrote:

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.

I don't have a press brake anymore, but the one I had was retrofitted with a commercial CNC bending controller. It was so awesome!
I'd love to see a solution where all the maths was applied to a bend list. eg, define  tool,  knife,  material for that list, then it would be a simple matter of setting the desired angle and backstop position for a list of bends. The maths is well known and every CAM program I used knew it.

Realteks became a problem with Bullseye (5.10 kernel) but we never released a version on it so the first issues were found with Bookworm (6.x kernel) when the kernel NIC driver architecture changed.

I think the minimum spec is i5 (4 core ) with Intel NIC.

People became a bit blase with PC specs until the recent kernels as above, but when I started with Mesa you had to compile the kernel to get the required  PREEMPT_RT we took a lot more care with PC selection...

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