Advanced Search

Honestly I work in technical spaces and I’m lucky to have the means to support companies that do this kind of work, and I’m happy to pay Mesa for their cards, given how much support they offer. I will return cards for RMA, and I don’t mind having spares.

Doing this build has been much more enjoyable than I expected so I figure I’ll probably also build an CNC lathe or convert my plasmacutter to Mesa control at some point. 

I appreciate the offer of a parallel card so I could boot my existing board but I’ll be able to check with the new control board that is coming and work is gonna consume me until those cards show up anyways

I have a skr1.4 turbo board. Would like to use ethernet to connect it to a pc instead of using a Raspberry Pi. Did see the demo of it working. Searched through the threads here and couldn't find how to wire and configure it.

I'm looking for a 4th Axis. Any links to a half decent quality 4th axis would be appreciated, I'm using pathpilot on a Novakon Pulsar mill so only light milling..

I recently struggled with getting my Raspberry Pi 5 to accept the estop input. On this forum, I asked the following question. 
I would like to know how to connect the GPIO to LinuxCNC’s E-Stop chain.
From this, I received some tips and advice that pointed me in the right direction, but no working answers. I used a YouTube video on installing LinuxCNC on a Raspberry Pi, but the advice was old and no longer valid. My assessment at this time is: If someone were to attempt what I attempted, I don't see a mechanism for them to follow in my footsteps because they would unlikely use the search term "estop" or "GPIO" to search the forum. So I would like to put together what I learned to make this happen. 
1. Not many users of this form are using Raspberry Pi computers - they have some limitations
2. The Byte2Bot hat does not create a parallel port. Rather is isolates the GPIO pins on the computer board and brings them out using a DB25 connector that is just like the parallel port on your Mesa card or computer. This allows you to use a parallel port breakout board. While a parallel port dedicates PIN2 to a dataline, with the output from a Raspberry Pi, one needs to refer to what is the GPIO line connected to that pin which is GPIO9 in this example. In your setup, you cannot refer to PIN2; you must only refer to which GPIO line it is. When someone sends you suggestions that look like  "=> hal-gpio.PIN12.out" - it won't help you. 
3. There are folks who can help you. The most valuable was the user "unkown". unknown provided this:
Below is a thread that is more or less an index for the Main RPi4/5 thread.
forum.linuxcnc.org/38-general-linuxcnc-q...l-images-only#325007
Has a section regarding GPIO and there is a working config if you follow the links.
They are there, you just have to look.
Just about everything regarding the Rpi4/5 is in this thread
forum.linuxcnc.org/9-installing-linuxcnc...official-images-only
4. The schematic offered by Byte2Bot had some notable omissions that is corrected in the Circuit3.jpg schematic from another user.
5. The eStop button should be NC (Normally Closed) - I did not correct that. The eStop button should be latching - mine is not. 
6. The *.hal file has changed significantly since the requirement of using the GPIO nomenclature
7. I have yet to control the spindle speed with the breakout board.
8. The StepConfig package in LinuxCNC is not intended for a Raspberry Pi with a hat. It is designed for a MESA board setup, which this is not. I'm not aware of a reason to use it, but it does create a *.hal and *.ini file for the machine name you select in setup.
9. If you want to search Google about eStop, do not search "Linuxcnc estop". You will fail. However, if you add the word "latch" to your query, you will have success. Don't ask. If you have a ton of experience, it may make sense. 
10.  When you submit a topic, hit the submit button and go have lunch. Nothing may happen for a while. I became impatient and hit submit again, and two instances of my topic were submitted. 11. How your question looks in the editor may not be how it looks online.12. I have more to learn.

SO
What do I have to promote the cause? If you use a Raspberry Pi 5 with a Byte2Bot parallel hat (it should be called a DB25 hat) with a parallel breakout board, you may have success with the following wiring and code.

Hi everyone!
I'm a long time lurker but first time poster.
I've been wanting to do something with LinuxCNC for a while now probalby 8-10 years. I've built/run several 3D printers as well as a Queenbee CNC Gantry router but using GRBL and ESTL controller has been way to simple to get up and running.
Meaning I've both been lazy and haven't really seen the need for using LinuxCNC.
I did plan on replacing the ESTL controller that is running the Queenbee router but it is working way to good for me to mess with it.

However!

An opportunity arose when I found a Kuhlmann mill on auction for next to nothing, probably since the controls where both partly missing and outdated, so i got it for an absolute steal, including service fees and tax it was less than 50 Eur.
So my plan is to retrofit it with LinuxCNC, convert it from steppers to Servos, and run both IO and servos on ethercat.

I figure I will use this a s a build log, I am also planning to film most of it but I have no idea of how quickly I can get any videos out.
It has been some time since I edited any video but I think it would be fun to get back to it again.
I hope to have updates here every other week or so, depending on life.

If you have any suggestions on hardware/config or any pitfalls to avoid, give me a heads up!  


The mill as it looked when I picked it up. It looks like is has mostly been used for cutting plastics, based on the debris Iv'e cleaned from it so far.

 
The  manufacturer as well as the original seller of the machine

   
The extremely outdated control system, a Berger Lahr KIM500. I have not found much info about it and all the stepper drivers are missing, the shop I got it from had several other Kuhlmann mills so my guess is this one has been scavanged for parts.

Berger Lahr was bought by Schneider Electric ages ago, before the internet was really a thing so there is not much info out there on them at all.

It was set up to use 5 phase stepper motors, and IF i had been able to find any drivers I might have used the orginal motors to save some money but no one seems to supply generic drives for 5 phase steppers.

So wish me luck and we will see when I have any more updates.
 

I hired someone last year to retrofit our K2 (KG5050) router after the K2 control board was fried. The primary goal (besides replacing the control electronics) was for it to be able to run LinuxCNC. After many false starts and wrong decisions made in the components to be used, and many, many hours spent wiring and re-wiring and testing things, it turned out that this project was too much for the young man I hired. He ultimately gave up after he failed to figure out the tuning of the servos/axes.

I have a computer programming background but I know very little about the world of electrical engineering and am hoping to find someone who can finish off the project - which according to the young man I hired, is just the tuning of the motors/axes, but which I suspect might require a bit more.

Ideally, I'd like to find someone local (we're based in Ventura, CA) but the control PC *is* setup with remote desktop access and a webcam on the table, so if you're confident you could do it remotely, with me on hand to E-stop/reset the machine as needed, I'd be okay with that option.

I have to admit that Linuxcnc is the only application I have that requires Linux. Like Andy, my engineering job requires almost exclusively Windows based programs, as do my family, for whom I appear to be IT manager.

@andypugh - could you suggest why your macros aren't showing up in my gmoccapy GUI? I've got no errors showing but clicking on the "cycles" tab doesn't change from the XZ preview.

thank you very much, I'll try it tomorrow, maybe the scale won't match because the input to the potentiometer is about 26vdc, but it's important that it works... maybe you can insert another potentiometer for jog override, i.e. jogging speed regulation, since this bosch wheel is not mpg, but the same potentiometer that they used, I assume, in the version with increments on the old controller, it's the same around 26vdc and could be attached  to analogin2?

Regarding Imperial vs Metric for accuracy.
Since Mr Johansson decide to use 25.4mm as the standard for 1 inch when producing his blocks, around the 1930's 16 countries started to use this as standard conversion, including the USA and UK. This was officially adopted world wide in the 1960s.
So basically an inch is defined as 25.4mm. Therefore it matters not whether one chooses metric or imperial to work with. As long as the machine is up to the task, ie in a state mechanically and to be pendantic tested and calibrated via a NIST certified testing facility you will get the required accuracy.
Another thing to consider whilst microstepping is great for smoothing movement it does not guarantee any linearality over a complete revolution. Another thing is the linearality of the lead screw it self, the stew itself may require mapping to help with commanded position and actual position reported by your scales.
Rolled ballscrews may not give the accuracy you are seeking.
So much to consider when aiming for um accuracy, without even thinking of thermal expansion of the cast iron vs lead screw material and all the boffin subjects.
But first port of call would be to assess the machine mechanically, check linearality and this should give you a baseline of what is realistic, then attempt progressive changes with much testing.
Your ideas do seem like a good starting point and only testing will confirm.

Thanks Tommy for picking up the slack in my less than ideal state of alertness.

One thing I would like the OP to confirm, is when using halcmd do you get proper comms with the board ? Just to confirm we aren't dealing with a hardware issue.

Once again I apologise for my lack of alertness.

I know that with the mesa 7c81 boards it is recommended to have a length of less than ~2.5" for the SPI cable length. So it just maybe the cable length is too long.
Dupont cables aren't ideal for SPI transmission at speed.
So ideas to try.
Ribbon cable with every second conductor a ground terminated at one end only, of course you will need a dedicated return ground. This may involved a custom bit of PCB at each end.
Shorter cable length for sure.
There's some other fixes I was going to suggest, but since the remora bards are "all in one" they would not apply.
But I guess a quality PSU, think Meanwell, might be worth considering.
My first port of call would be to reduce the SPI cable to the absolute minimum, preferably to under 2.5" max.
One thing of note is that I have the RPi5 can tolerate a longer SPI cable that the RPi4, the caveat being this is based on experience with a home made 7c81 clone.
I'm apologise if the references to the 7c81 is annoying, but it is entirely based on my experience with SPI as a communication medium. I honestly hope that some of the above suggestions will give you good for thought.

  I am sending you the corrected custom.hal file; I believe I had sent you one with some errors.

Hi all,I have a working Remora configuration running with Raspberry Pi (LinuxCNC 2.9), SKR 1.4 board (LPC1768), and SPI connection – but only using an old Remora component, because the recent ones do not support LPC1768 anymore (as Scott confirmed). The system works perfectly “on the bench” with just the boards and motors, but as soon as I connect it to my real machine, the SPI link becomes super unstable (“bad SPI payload / estop won’t reset” errors).Symptoms:

• Dupont wires or short IDC ribbon cable used for SPI (RPi CM4 → SKR1.4, <30cm).
• Works fine with just the controller and stepper drivers.
• The moment I connect “real loads” (motors, hotwire, power MOSFETs, or even touch the machine frame), SPI constantly fails.
• E-stop triggers, payload errors jump in LinuxCNC log.
• Even switching on the heater causes instant SPI dropouts.
• With ribbon cable it’s even worse (won’t leave estop).

What I tried:

• Multiple cables, power supplies, SD cards, re-flashing, common ground.
• SPI config is what works for old component – I can’t change SPI freq etc, I get “unknown command” if I try.
• System is totally stable on the bench, not with machine.

Limitations:

• New Remora components don't work – the SKR1.4/LPC1768 is legacy, so I must use the oldest one.
• This old Remora doesn’t let me change SPI speed, delay, etc.
• Hardware fix suggestions welcome, but software/firmware is stuck “as is” for now.

Has anyone solved this?

• Is it possible to get reliable SPI with legacy SKR1.4 + RPi, in a noisy CNC environment?
• Any proven hardware methods? (twisted pairs, shielded cable, ground, ferrites, extra pullups, RC on SPI lines…?)
• Is it possible to patch the Remora legacy component to allow lower SPI clock?
• Any old firmware/component version which allows SPI configuration and works with LPC1768?

Any advice would help – right now the setup works great “bare”, but physical machine (motors/heaters/vibrations) kills SPI instantly…Thanks!

Why would you be attempting to offer a LPT card in this instance ?

I tried what you suggested, it doesn’t work, it has erratic behavior. It performs poorly in 2.8, 2.94, and 2.97, it behaves erratically in all of them, I don’t understand what’s going on