LinuxCNC testing on a 3D printer shows it should handle laser cutting and engraving too

I have LinuxCNC on a Raspberry Pi controlling a $45 3D printer controller board( SKR v1.4 turbo or MKS SBase v1.3 ) and as I learn more about LinuxCNC I find things to test features and capabilities. For example, the Trajectory Planner handles lots of things dealing with acceleration, deceleration, etc and it does so by looking at the next command/move and many others coming up. It is one of the oldest and well tested open source TP’s out there. These videos show what happens when the TP look-ahead is disabled. A good way to show it is with circles having many straight lines. The Arc Blend feature of the TP optimizes motion when it can. I created the file using LightBurn by creating a circle, setting the speed to 200mm/s and then set the feature type to Offset Fill with a 1mm offset per line/circle. The speed with the 50 segment look-ahead buffer shows that this LinuxCNC setup should also work fine on the K40 laser cutter.

Here are 2 videos showing LInuxCNC arc blend buffer testing.
One with a 1 segment arc blend buffer size(arc blend disabled):

and a video showing LInuxCNC with a 50 segment arc blend buffer(arc blend enabled):

4 Likes

FWIW, I already have an MKS Sbase v1.3 running Smoothieware in the K40 and I started testing LinuxCNC/Remora on 2nd MKS Sbase v1.3 board so it already has to jumper wire hack to get the SPI signals all on one connector so it’s a drop-in replacement I’ll be doing soon.

In the video, I have a SKR v1.4 turbo board with TMC2208 stepper drivers. That board is not only smaller than the MKS but the SPI signals are already accessible in the EXP2 connector so making a simple board to use the stock display ribbon cable was pretty easy. I plan to make a PCB layout in KiCAD so others can just order a board, some connectors and be plug-n-play.

Information on Remora and be found here:
https://remora-docs.readthedocs.io/en/latest/intro/intro.html

4 Likes

I made some PCB cable adapter boards in KiCAD for both the MKS Sbase v1.3 board and the SKR v1.4/v1.4 turbo boards.

I uploaded and ordered boards today so not yet validated. “should” be ok since I made them to mimic the boards I made for the SKR board using perf-board and connectors listed in this schematic.

https://dirtypcbs.com/store/designer/details/13122/6524/remora-mks-skr-adapters-zip

2 Likes

When Machinekit forked from LinuxCNC, I thought LinuxCNC was explicitly not going to support non-x86 processors, and figured that Machinekit was going to be where this kind of work would land. What you are doing is making me realize that I don’t understand the relative state of LinuxCNC and Machinekit. Now I know that I don’t understand the LinuxCNC / Machinekit fork at all, so I have no sense why the fork exists or how one would choose which side of the fork to start from. Did you start with long history of using LinuxCNC (so why change to a fork?) or did you evaluate both and choose LinuxCNC here? I’d love to learn more!

1 Like

I will do the best I can explaining but by no means am I more than a LinuxCNC or Machinekit beginner. I’ve only been able to get it running on my machines with the assistance of many of the experts in both camps.

From what I gathered 5 or 6 years ago when I built my Machinekit/CRAMPS delta was that Machinekit forked from LinuxCNC due to developers refusing to move the code to anything but RTAI realtime kernel. A branch of Machinekit was created which supported other realtime kernels(Xenomia and RT_PREMPT) which allowed good performance yet not requiring applications to run as root like LinuxCNC/RTAI required. RTAI was a stale realtime kernel and took lots of extra build steps to create a working system.

One of the side effects of using current/supported realtime kernels and simplier build configurations was that the Machinekit branch/fork could be built for other architectures(Linux is very portable). The BeagleBone Black(BBB) was a great platform for Machinekit because it has builtin realtime micro-controlers which could be put to use for dealing with stepper motor control(hard realtime stuff) while the rest of the computer running on the realtime kernel did trajectory planning, gcode magic etc. It was the goto platform outside of x86 platforms LinuxCNC was tied to because of the RTAI kernel.

The Machinekit devs also made efforts to componentize Machinekit into a kind of client server system with QtQuickVCP GUI capabilities to replace the aging Axis GUI interface. I’m fussy on this but the just of it is the Machinekit devs were doing more outside-the-box development while LinuxCNC devs were doing lots of smaller bugfixing and less adventurous modifications/upgrades.

I believe this was all happening roughly 10 years ago. At one point, the person who helped me later in getting Machinekit setup on my delta and who developed the CRAMPS cape for the BBB, Charles Steinkuehler, created a branch of LinuxCNC which compiled with RTAI, Xenomai and RT_PREEMT realtime kernals. This allowed LinuxCNC to use more modern Linux kernels and more current Linux distributions. It probably became a bigger issue as more consumers were getting home CNC machines and wanted to use their CNC computers for more than a dedicated CNC control system.

FYI, latency using the RTAI kernel is still king but with advances in CPU designs/speeds and FPGA offboard stepgen controllers like Mesa and now Remora, that super low latency on the application side isn’t so critical.

I think it might have been with the rPi3B or rPi3B+ that the Raspberry Pi became a thing for LinuxCNC adventurers since it could remove a large box in the shop and home shops can use all the space they can get. Remora was created by Scott Alford 5 years ago but unfortunately very few found it so he’s been the only one using it. Others have been using the rPi running LinuxCNC with Mesa FPGA boards over ethernet interface. It’s used to take $200-$300 of Mesa cards to work and now I think it’s just under $200. Still not something to throw some spare funds at just to experiment.

Scott used LinuxCNC when he did his development and probably because they were working with rPi while Machinekit devs were not doing anything but x86 and BBB. Scott was building LinuxCNC on the rPi so theoretically he could have been building Machinekit since it was forked to be more cross platform to begin with. I spoke with Charles Steinkuehler about Machinekit / LinuxCNC and Remora and he said there’s nothing stopping it from running on the rPi , that there are improvements to Machinekit which would benefit LinuxCNC but likely not get used and basically that the LCNC forums were more active than Machinekit forums(my observation also).

So I was going to just build LinuxCNC on the rPi as Scott Alford’s documents mentioned when I found a current pre-built image and gave that a try and it worked. LinuxCNC also has support for custome GUI applications via QtVCP and QtpyVCP. From my understanding and a but of playing around, QtVCP is similar to QtQuickVCP in that there’s lots of QtXML configurations and bindings which make the display happen instead of binary compiled code. But QtQuickVCP acts more like a browser app in a client server kind of way. ie you run a QtQuickVCP app on your desktop, phone, tablet and it renders and makes control choices of what ‘browser’ display you want to run. I believe it will continue to run your app even with the client display shutdown. A bit fussy on this but the gest of it is, LinuxCNC and Machinekit have different ways of creating client user interfaces but both are cross platform using Qt development tools. There are many LinuxCNC GUIs to pick from too.

I was fine with using LinuxCNC when I saw how quiet the Machinekit forums had become and how active the LinuxCNC still was.

I will say, what Scott Alford has done with Remora is fantastic and amazing and it’s getting too little recognition. But LinuxCNC is not for everyone as it’s currently setup out of the box. It’s like a Lego Mindstorm kit vs a Barney the Dinosaur Lego kit. Far more powerful and you can do many customized things with it to make it fit your workflow/needs as opposed to specifically built systems with just a few clicks of buttons to get standard output. But I’m the type who picked Slic3r over all the other slicers(I tried most of them) because Slic3r had so much of the configuration options exposed in the UI. I know many who pick other slicers because there are few options.

I currently run my LinuxCNC setup on the Ender3 over VNC and it works great. VNC is already installed on the rPi image of LinuxCNC 2.9 and I already had the VNC viewer on my desktop. Today I will make a hand wired SPI cable adapter board and power up the K40 off LinuxCNC. The cool part is, after the one wire mode to the MKS Sbase 1.3 board, I can switch back and forth between Smoothieware and Remora by just moving firmware.bin/config.txt files on the uSD card.

I’m also looking forward to adding closed loop stepper motor control to the systems to see how fast they can go and still not miss a beat using little $15 magnetic encoders. The boards mount on the back of the stepper motors and the magnet gets glued to the flat motor shaft. Like the as5047 based boards: AS5047P 14-Bit Rotary Position Sensor - ams | Mouser

3 Likes

It’s WORKING! I was having problems with LinuxCNC parsing so many small moves( at 254DPI each move is 0.1mm ) and did lots of tests at 25% power, 15% and 5%. When there was parsing problems even 5% power was burning deep black lines instead of surface etching.

It may not look like much but it’s at 5KHz PWM, 5% power setting, 200mm/s dithering of a 75mm x 50mm image but it works. I can see Walter and Donny, can you?

Here is the original image:
lebowskibowling

I thought I was being fancy by using both the synchronous M67 command and the asynchronous M68 command. Turns out, putting the M67 command on the same line as the movement was the magic which resulted in the motion speed needed to allow there to be variation in power levels which can present variations in image perception.

I’ll do some tests changing the PWM frequency and then see how this handles grayscale.

2 Likes

I still haven’t played with LinuxCNC but this has piqued my interest.

Does LinuxCNC have resonance compensation where you can hook up an accelerometer and have it measure system resonance and compensate for it?

I don’t know enough about LinuxCNC to even know whether “posting a config” is a meaningful thing here; if it is I’d love to understand what it takes. Beginners intro to connecting a laser to LinuxCNC? I do think I’ll start with Klipper because I can do it through USB instead of needing SPI, but I would like to understand what it would look like to switch. Given that my approach to acquiring a laser was to design and build from scratch, I can imagine that I might grow to appreciate the level of control LinuxCNC provides… :grin:

1 Like

I don’t know about that but there are other forms of feedback and compansation in LinuxCNC which you don’t find in the ‘buffered firmwares’.

I have some connector boards arriving soon which will make SPI connection simple. ie it uses the IDT ribbon cables used for connecting displays to these 3DP boards. Just need to solder a 10 pin header pin connector and a 10 pin socket connector.

I had 4 different control systems on the machines I have which are all basically the same(3DPs, lasercutters, CNC) and was hoping for a single solution. As a maker you can appreciate the desire for elegance, improvement and efficiency and so when I was looking for a solution which used LinuxCNC and found Remora it seemed possible. To me, it always seemed like the ‘buffered firmwares’ were growing to be like LinuxCNC on the least expensive hardware available. But then LinuxCNC became enabled on the low end by rPi3B+/rPi4 with Mesa boards and now Remora on standard 3DP boards. LinuxCNC is so darn flexible and configurable it just seems like the goal everyone is aiming for yet it’s already here. I see why Tormach went with it and their own custom UI. There’s lots to figure out if you want to be doing the integration though.

1 Like

I just figured out how to make the laser PWM stop when the program stops so I think it’s done and ready for use. I’ll do a pull request on the repo to add the k40 configuration files.

1 Like

I created some GLCD ribbon cable adapters for the SPI connection with either the MKS or the SKR boards and the rPi. I’ve validated they work on both of these boards.

Remora MKS and SKR ribbon cable Adapters PCBs

Here are some pics of the boards, boards with 2x5 socket and 2x5 header pins and installed on a MKS board.


PXL_20210708_215835664.PORTRAIT


1 Like

Most of the PREEMPT-RT patch set (72 patches!) looks like it will go into the 5.15 Linux kernel. Good news for long-term upgrades for LinuxCNC systems!

https://lore.kernel.org/lkml/20210815203225.710392609@linutronix.de/

1 Like

This work has in fact merged into Linus’s kernel for 5.15, after about 17 years of development.

3 Likes