Dan MaloneyWelcome all! We'll get started in about 15 minutes. Feel free to chat away
I hope to figure out how all this works...
*cough* Machinekit *cough*
isn't it the same things?!? already confused
:)
Ok quick question, how does one ask a question, and if it's like this then:
Can I use linuxCNC to hook up a two stepper motors and RELATIVELY easily make a cnc dremel?
Yes, that is exactly the sort of thing that LinuxCNC is for
Exactly my hope, thanks, I'm planning to attach cheap steppers to threaded rod (with nuts for the "trolley") and just have a go
What is the best information place to start learning from scratch
For the next hour or so, here. Then possibly the Linuxcnc forums
good answer, like a politian ;
It has to be admitted that, to an extent, the LinuxCNC docs kind of assume that you know what you want to do before telling you how to do it.
Will you be talkinng us through the config approach for Lcnc
So, I'm looking at the https://www.linuxcnc.org website now. It seems I can put that on a controller board to drive my --existing-- CNC machine. I have a commercial CNC with an HPGL controller which I don't really like (only Windows support). So I can replace it, or I can simply find better linux driver software (CAM?) which outputs HPGL and can control the machine manually. Zero-ing etc.
There are some pretty good YouTube videos of complete CNC builds that could give you a good overview
LinuxCNC is very extensively documented, but that comes with the penalty of it taking more than an hour or so to know it all.
Greetings all!
Hello, welcome! Getting started in about 10 minutes
I am sniffing for a "start here" url
@Axel Both ways work. One thing about LinuxCNC is that it's free software. That means that neither I nor any other developers care if you use it. We want you to use what is best for you.
G-code to HPGL seems like it should be do-able with simple software.
Beck from 10BitWorks Makerspace in San Antonio, Texas. We just got a used 4x8' CNC at our space and it uses LinuxCNC, or a version of it Control Commander?
@Daren Schwenke what're the main differences between MachineKit and linuxCNC, is the latter just more low level and machinekit more a highlevel management app or something?
machinekit looks to be archived looking at their github?
Of course, but I am here to learn if it is useful for me. Perl is free as well, so is C, but that does not mean it is handy to drive a CNC machine :-)
I'll let Andy field that one later.
Cool.
Machinekit is a fork of LinuxCNC. The folk on that project got annoyed by LinuxCNC emphasis on stability, and wanted a faster-moving project.
Fair, bleeding edge useful but dangerous
basically. :)
haha
Fundamentally Machinekit and LinuxCNC look much the same and work much the same. There are differences under the hood that only programmers would care about.
I'm still so confused over that, where LinuxCNC looks like a gui frontend for controller a CNC and MachineKit looks like..... I still dunno
But if you are starting from scratch with a PC to dedicate to the job, then LinuxCNC is easier to get going, as we offer a monolithic install image.
Someone got the integrated microcontrollers in the Allwinner ARM SOC's working with LCNC. So you can do what machinekit did with the Beagle Bone Black and software step using the internal micros.
I'd suggest youtube for people wanting a primer on LinuxCNC and where it fits in. You'll get a handle on it much faster than reading the documentation
@morgan There are (approximately) three layers to LinuxCNC. There are the GUIs that run in user-space like any other application. You can use any of them, or none of them, to control a machine.
it is the whole shebang. from the GUI (there are like 5 different ones), the gcode interpreting, the mid level management of stuff like trajectory planning, all the way down to generating individual pulses for controlling bldc motors or steppers.
(and, arguably, more than one UI is possible, using halui or a UDP connection to send commands to a running instance, but I digress)
I use it like a swiss army knife. I control CNC machines as well as robots, SLS, SLA and inkjet printers. We even use it to synthesize DNA and control PCR robots.
Re: BBB internal PRUs, wondering how much of that code if any, or how similar that is to what Centroid is doing with their Acorn controller
They're using a Seeed BBG on a custom breakout board running software that talks to an interface running on a PC via ethernet
@chorca I have no idea. I don't have any real incentive to look at Centroid.
OK, folks, let's get started "officially" -- I'll make sure to grab all this early stuff for the transcript too. My name is Dan, I'll be the Hack Chat mod today as we welcome Andy Pugh to talk about Linux in the Machine Shop.
Welcome Andy, thanks for your time today. Can you start us off with a little about yourself?
Feels odd to "start" now :-)
Right. I got in to LinuxCNC because I wanted to make a clock. O am an engineer really, not a coder.
But my dad always had a machine shop, so I have been using a lathe since I was seven
Lucky kid...
what kind of clock out of interest. sounds cool
I was setting up my own machine shop and decided that my lathe would be better if it was CNC, installed LinuxCNC and got it working relatively easily.
Hello everyone! :-)
Then I decided that someone should expand one of the LinuxCNC hardware drivers to support a new board from an already-supported supplier, and taught myself C...
nice easy way to learn c !
(I have been hobby-coding for a long time, I sold a few games for the ZX81 and Spectrum back in the 80s as a schoolboy)
Somehow "someone" always turns out to be you
@Adrian In some ways, yes. Kernel drivers are a nice, simple place to code. But when it goes wrong, you need to reboot. But Z80 machine code was just the same...
If anyone is interested, my day-job is developing Diesel engines, i get to drive around in cars covered in camouflage in exotic locations.
This was in the days before encrypted and signed kernel drivers probably
No, it's just the same now.
Cool
For one of the supported realtime systems that LinuxCNC supports, all the realtime modules are kernel modules.
(That's RTAI)
We also support Xenomai (a bit) and preempt-rt (properly)
So, I was describing how LinuxCNC is modular, and you can use all of it (most people do) or just use some parts.
Below the GUI of your choice is the Interpreter of your choice. As long as that choice is G-code. Pluggable interpreters are supported, but we only have one real one and a proof-of concept.
But if anyone wanted to write a Step-NC interpreter, it would be easy to choose to use it.
Then there is the HAL layer (my favourite)
Where you can send the outputs of the motion controller to your choice of hardware, optionally processing it on the way.
Which module is the motion controller, the GUI front-end, or the interpreter?
Man, I remember back in the day when it was called EMC, before they had to switch to LinuxCNC.
You can do an awful lot in HAL. For example I was messing about with a tiny (6mm stepper) a few weeks back, and got it spinning with about 6 lines typed at the command prompt, to load up HAL (by itself) and set a step-generator running.
And is there a CAM package involved as well?
I found the block diagrams of how LCNC works here helpful: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components
I forgot to mention the motion controller, but as it is a loadable HAL component, that isn't a total oversight.
Thanks @Bari
I think i've seen linux cnc works with some pci(e?) fpga cards, to drive motors? I'm curious in that mode of operation do g code operations get sent to the FPGA to interpret and then the FPGA sends the correct timing signals, or..
@anfractuosity There are some systems that behave as you describe. The Smoothstepper that is very popular with Mach3 users does exactly that. It puts a simplified interpreter and motion controller in the remote module.
The LinuxCNC FPGA "helper" cards do not do that. Let me explain, but start somewhere else.
cheers
doe the motion controller have to be a hal component? or can it use others ... eg. GRBL
LinuxCNC relies on a realtime system running on the Linux system. A number of realtime modules are called by the RTOS on a fixed schedule. Typically a slow thread running at 1kHz and (only where needed) a fast one running at 50kHz
@Adrian GRBL is an alternative to LinuxCNC really. Asking to use GRBL with LinuxCNC is a little like asking if you can use your Mini to do some of the work of your truck.
So, for a very basic system on a budget you might choose to use the parallel port (yes, I know, but if you _do_ have one, then it works well)
In that case the slow thread does all the motion planning and outputs a new position for each axis motor ever 1mS.
I have LCNC systems that use PCIe FPGA cards and parallel port cards at the same time.
Then (in HAL) you would connect those position commands to a step generator (or a PWM, or whatever) and then take the output of the step generator to the parallel port pon of your choice.
I have a rather old Pentium 4 PC laying around which still has a parallel port. Would that be sufficient, or is it better to use a more modern PC and use another form of hardware interface?
Or use a modern PC for the frontend and use that old one solely for driving the hardware?
Step-generation and the updating of the p-port pins happens in the fast thread. Depending on the PC hardware that can run at up to about 50kHz
Now, back to the FPGA cards...
@Axel I have it running on nearly 20 year old Via PC's and brand new Ryzen systems.
haha!
raspberry pi4 plus mesa spi nesting board looks like the way to go moving forward to me
Those take over the work of the fast thread. But don't do very much onboard processing. So, in HAL, you would connect a motor command to a HAL pin created by the FPGA card, and every 1mS that would get a new position to go to (in floating-point engineering units). The driver converts that to signal on the PCI (or ethernet, or SPI, or EPP) Bus and the FPGA uses that data to create the required number of pulses in the next 1mS period.
Pi4 + Ethernet also works.
I just like the look of that $89 card they have, but yeah, you don't get to move it to something else later on if you want to I guess
So, LCNC is always in the control loop, not simply drip feeding some mystery box to handle the path planning and control...
(Prior to the Pi4 the ethernet was on the USB bus. I keep mentioning this 1mS "tick". That is why USB is not usable by LinuxCNC, as the specification allows multi-mS delays while data packets are collected)
any pros and cons with ethernet vs spi Andy?
@Connor Yes, exactly.
I guess with ethernet your controller could be 50 meters away (150'), and SPI ... not?!
Ethernet travels farther than SPI. So the two boards may be farther apart using Ethernet.
LinuxCNC _could_ be made to do drip-feed, but that isn't what it is for. If it was a commercial system, and there was money in it, then it might have happened. But as it is we just accept that there are _better_ things out there for drip-feed to external controllers.
What is drip-feed? I only know it for plants.
@Axel Yes, for SPI you want to be inches away at most.
Yeah, SPI is an inter-chip bus.
Drip-feed is where a PC sends actual lines of G-code one line at a time to something that then interprets and acts on that G-code
theoretically SPI could be possible up to ~10m, depending on speed. but yes I guess the ethernet would be further
Ah! the original software of my CNC was drip feed then! Thanks. Controlled via the DTR/DTS line of the serial port.
Drip feed is sometimes called "DNC"
"Drip feed" is putting a new front end on an old existing control, like a modern computer pretending it's the old controller's paper tape reader.
It might be fun to have LinuxCNC punch _actual_ tape to feed to one.
Well, in my case, drip feed might work, as it already contains a 2.5D controller
Though flashing LEDs at the reader would make more sense.
GRBL and Smoothstepper could be concentered Drip Feed controllers.
Oh man, that sounds like a great project! Somebody needs to do this!
2.5D is a lot less useful that 3D, though.
Exactly! One of the reasons to upgrade!
So, let's take your system as an example to retrofit, and let other folk chime in with questions as-and-when
Me? Okidoki
Have you looked inside the box? Do you know if the stepper drivers are integrated with the control or are they separate units?
Ooh, that was at least 8 years ago.
There is a controller box which contains the stepper drivers on the board.
So, RS-232 in --> stepper signals out.
By "stepper" signals you mean the A and B phases to the motors?
That's similtaneously easier and harder. Easier as you should probably just decide to get rid of the whole board and replace with something that is probably newer and better.
Yes, the motor wires are hooked up to D9 connectors which go into the controller
Yes, replacing it has been on my todo list.
A standard PC like a Mini-ITX is pretty small. On my lathe I put the PC and several Mesa cards in the space liberated by two _rectifiers)
rectifiers! Hah!
I bet those were selenium stacks...
(Lovely old selenium rectifiers, I kept them safe)
And things like NUC are even smaller, before you go to the slightly-more-troublesome SoC systems.
But Pi4 is working nicely.
(I would still suggest conventional x86 PCs where there is space, though)
any particular reason for that, Andy?
I was just typing a question about Pis and if they were practical for Linux CNC work. Guess that answers that
Well I'm sure there is, but could you please expand?
Both of mine use Older Atom based PC's One with Parallel port, one with a mesa card.
I just looked at the mesanet website, and there are a ton of 'Plug & Go' cards with no explanation of what they actually do.
They run less-special versions of the OS, they have PCI buses, you can replace parts cheaply and easily
Anything special about the PCI bus here? Just a greater selection of cards to use, or better driver support, or something else?
Just that.
@Axel The main issue with any x86 PC is the BIOS. Some BIOS's are broken or leave out the options to kill all power management, speed stepping or virtualization. If these are left on they can delay real time tasks.
Second issue can be graphics...
Thanks @Bari
So, back to this hypothetical retrofit:
Not all PCs have low enough latency to be used (this is annoying, and a fair criticism made of LinuxCNC that it won't work properly on just any system, and it is hard to predict which ones it will work on)
So it is useful to boot a system from the Live-image (USB stick, or actual shiny spinny polycarbonate disc) to run the latency test. You can do this without upsetting the installed OS.
nice
This from a system I have had running in the background. It is actually a core-2-duo machine built for the UK schools market, an all-in-one unit with a carry handle.
I paid £100 for it.
what is good vs bad in max jitter?
That is demonstrating an ability to poll the fast and slow threads with a timing accuracy of about 7µS.
That one above is unusually good.
The PC's that have latency issues are very much in the minority. Most I have found with problems are 2 and 3-letter name brand office PC's sold off lease that have trimmed down BIOS features to lessen issues with tech support.
For Software stepping you want to be under 50µS, with a Pico, Mesa or General Mechatronics "helper" card you can get away with 500µS But less it better.
Others have been low budget motherboards with fewer BIOS options.
The screen shot above, incidentally, is using the almost-mainline preempt-RT kernel.
It does better still with RTAI.
Dang, that's a nice little machine..
But it's not a thing to get hung up on (A lot of users do, they tune their BIOS like they might a car that they run standing-quarters with). If you can get below 50µS configure the system and start making chips
Do you miss steps if the timing is too slow?
The PC in question is the RM-one, but as an all-in-one without a touch-screen it might not be the ideal workshop PC, I use it for hardware testing. It's got one of every type of Mesa card attached.
I just learned I somewhat frequently cycle past Mesa, their dumpsters will be thoroughly inspected.
@pdxalz If the jitter is too high then _LinuxCNC_ won't lose steps, it accurately counts every step it has made, and will make up for any that didn't fit in the servo-period.
But the _hardware_ might miss steps if the step-pulse speed is too far off the physical motor speed.
@pdxalz the timing controls the maximum speed at which you can send steps reliably. Yes, if you exceed that occasionally you could miss steps. Conversely, you can limit the maximum rate at which you generate steps to below whatever you can get on a machine, and it works fine, down to your hardware limitations.
So, I took some time to open up the controller from the old CNC. I hope I can upload an image here.
I see the three stepper motors and a controller board (on the right)
The controller board I would probably want to ditch.
motors --> stepper motor drivers
I suspect that the inver
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.