Porting to faster hardware

Therein lies the rub. There are a lot of paths through the calibration - quad/triangular, topfeed/bottomfeed, with/without z axis, varying frame geometries. Judging from the forum, there are a lot of ways to get off track, and that’s with pictures and text narrative at each step.

2 Likes

Personally, what I’d like to see is an app (phone, tablet, etc.) that can connect to the controller using bluetooth or wifi and be able to do everything from there. I’d rather the app not do anything but provide the user interface and everything run from the controller so if you lose connection, get a call, phone battery die, etc., it still completes the cut.

1 Like

the calibration has a few steps

hook up the chain to the first motor, feed it out, hook it to the second motor,
draw it tight, record the results

everything except record the results can be done in g-code (with some custom B
commands, but still a g-code file, including some pauses which could be done
with tool change commands). We even have a code that can report the position of
the left and right motors, but we can’t calculate the difference between them or
remember it currently. but this would be a pretty trivial command to add.

Then you hook up and feed out chain to the sled (again, all g-code), run a
series of cuts (recording where it thinks it is for the cuts), then measure the
cuts and enter a few measurements, then run calculations to compare where it
thought it was with where it actually was.

entering the measurements, knowing where it thought it was, and doing the
calculations are new things it would need to do. But if it has the machine
dimensions available to it, it should be able to calculate where it thought it
was again, and then one new command with the measurements as parameters could
tell it ‘do the calculations based on these measurements’

Having a good UI for it is a hard problem, but I’m not trying to make a pretty
UI for it, I’m trying to make it possible to do from a universal sender. Once
it’s possible (and not tied into having to use Ground Control), then making the
UI reasonable for different tools is the responsibility of the people using
those tools.

David Lang

2 Likes

@dlang I’ve been working on some UI, alternative calibration technique, and other things for Teensy3.x firmware. If there are any specific firmware features you want for the future, I’d love to hear about them and start work.
One thing I figured out just today is that a cheap Wii nunchuck has a nice thumb joystick, a C(cut) button. a Z(z axis) button, 3 axis accelerometer, arduino library, and a comfortable small form. That makes a good beginning for physical UI IMO.

2 Likes

We could try giving the due some eeprom (thank you Instructables )
Wouldn’t this be easier than porting grbl? And also, wouldn’t it be more futureproof? Since grbl is made for arm and if they start changing under the hood in future releases, it might be not so easy to port it.
Are there other drawbacks on due?

It’s been a long time since I looked at the Due, hard to remember. Open up the firmware in the Arduino IDE and change the board type to Due and see what happens. The compiler will give you some ideas about where to start looking :slightly_smiling_face:
Porting to grbl is non-trivial, and would bring a different set of issues.

Maslow will not compile on the Due - tried that last Saturday. dumps on I/O.

Fww

Thank you

@blurfl Are we any closer on the teensy 3.5?

Thank you

That’s how one knows where to begin digging… :grin:

Haven’t had time to work on that, it will be a month or so before I can get back to it. Sorry for the delay.

2 Likes

There’s a good chance that that is just due to pin assignments.

David Lang

1 Like

Funny, I had this the same thought. We can save some cost by integrating the atmega chip in the board. I would be happy to help out. I have developed a atmega based PCBs and have also got experience programming. One of the reasons I would like to do this is that I would like to make some more i/o aux pins available and perhaps even expose i2c.

3 Likes

The firmware and motor control board are open source, fork them and give it a go. That’s how the TLE5206 board was developed. You’ll get lots of input developing a list of desired features :grin:!

6 Likes

@Ned I know this is old but a couple of months ago I thought about the same thing but for 3D printers, laser cutters, etc. ie using step generation firmware on the 3D printer controller boards and let LinuxCNC talk to it. This is really what goes on with LinuxCNC and/or Mach 3 and those parallel port Mesa cards.

Guess what, I found an existing project and have been working with the developer and now have a Creality Ender 3 being controlled by LinuxCNC. I did have to use a 32bit 3D printer board instead of the 8bit AVR based board but cheap Smoothie clones are available. Anyways, the firmware used is called Remora( find it on github ) and the rPi communicates over SPI to the 3DP board.

I also found out that encoders are already supported and that got me looking at why Maslow wan’t being controlled by LinuxCNC. ie I’m back here looking at old posts for why Maslow isn’t run by LinuxCNC. I think LinuxCNC on the rPi has been around for 4 years running on top of the real-time kernel just like it does on full size PCs which run big machines like Tormach milling machines.

And if it just means wiring up an h-bridge or 2 a rPi Hat should be pretty cheap to make this work.
And with QtVCP the display should be able to run on desktops, tablets and even phones.

Maybe time to take another look at this?

1 Like

When I went looking at LinuxCNC, I was not able to get useful answers for how to
configure it (‘look at the code for the $$$ drivers’ type of answers). If we can
get examples of a setup that uses dir+pwm output / encoders input that would be
a huge help.

David Lang

I’m by no means even a LinuxCNC beginner but getting my feet wet again and again should help. But I am working with a guy who’s quite versed in it so I’m hoping for some guidance with getting those DC motors and encoders working. I even found a project which uses steppers on LinuxCNC so maybe it’s the basis if a technology demo. The encoder end of this is already implemented for chips/boards like the AS5048 so that’s a start and the LinuxCNC developer I’m talking to said it sounds like it’s really just setting up the PID processes which would drive the PWM and dir pins. This is what I’ll look at manipulate first. Kinda looks familiar. :slight_smile:

FWIW, I now have LinuxCNC / Remora running my Creality 3D printer and controlling my K40 laser cutter. Support for encoders is already in the working codebase and work on closed loop DC motor control is being worked on. Support for TMC2208/TMC2209 drivers work and TMC5160 is coming soon. One high speed encoder is supported which has been used for CNC thread taping which is very cool too.

Pretty darn good for a $39 rPi4 + a $45 SKR v1.4 3DP board.

I’ve got a few things to tiddy up the laser cutter workflow and then will move on to setting up my Chinese 3040T CNC which still has a parallel port input with an Arduino GRBL controller driving the parallel port. Will try to do the same with LinuxCNC/Remora or I will re-brain it with an SKR v1.4 board also.

it would be nice to run the entire maslow software on a raspi4.

There is already open sourced LinuxCNC kinematics for a drawbot so it’s not far away once the closed loop DC motor support is added to Remora. It’s time to ping the Remora software developer on this. He’s been building a new shop so time on Remora has been scarce but maybe asking will light a fire as they say.

1 Like

Are you saying that LinuxCNC is working on an RPi? I converted my LinuxCNC Zenbot Mini to grbl_ESP32 last summer after it sat idle for many years, and haven’t checked their forum for quite a while. The last time I checked lcnc on a pi was pretty sad

Has machinekit on BBB also fizzled?

Yes, LinuxCNC runs on the rPi3B+ and better on rPi4(mostly GUI perf related) and to drive hardware in realtime there are 2 options. Mesa now has boards which work with ethernet connections to the PC or rPi and I think it takes 2 boards(one comm/IO board and one driver board) or there is the Remora project which turns a standard LPC1768 or LPC1769 based 3D printer controller board(Smoothie, SKR, MKS, etc) into the realtime step gen with communications with the rPi over SPI bus. Welcome to Remora’s documentation — Remora documentation 0.0.1 documentation

LinuxCNC/Remora works very well. There is a HyperCube 3D printer and my Creality Ender3 running with it. I just got my laser cutter( K40 ) running with it and there’s a guy running his large CNC machine with it and even doing closed loop tapping. Remora supports closed loop encoders for motion and one high speed encoder for spindles.

As for Machinekit, when I thought about trying to use LinuxCNC for all of my machines I looked at Machinekit since it was already running one of my delta 3D printers. I was sad to see there was very little going on in the forums and development. It is not fizzled but it’s not as active as it once was. LinuxCNC finally moved to a modern rt kernel 3-4 years ago and that is what enabled work on ARM devices. Remora started about the same time but nobody knew about it and since I found the developer and he was excited to have someone using it and he ran it with LinuxCNC, I decided to follow his lead. The LinuxCNC forum is very active.

FWIW, the current planning for Remora is to clean up our development setups to move to more ‘production’ like setup and do videos of the systems to try and get the project more publicity and users.
After that, some work to get closed loop DC motor control working and then try to get getting this bipod working which should lead to a port to MaslowCNC.

This might look familiar: LinuxCNC Bipod Plotter - YouTube
Source code here: GitHub - Chojins/LinuxCNC-Polargraph: Drawing robot using linuxCNC

3 Likes