LinuxCNC for 3D printers and similar...

Hello....

I just got few moments to got little thinkering.
In my future plan is to build some kind of 3D printer too.
I look for available electronics and I can tell just that sucks. So many board's wires, different mcu's etc etc...
So there are some success with LinuxCnc too. As Linuxcnc can run from raspberry and similar... And not so new laptops....
.. I got the simple idea to allow use of not so good computers (mostly laptops) with bad lattency or SMI and similar problems.

So My idea is to put one cheap micro to the printer port (or even USB) or fast serial..
But the micro does just easy task to be FIFO with some kind of PLL and expander. It receive pinstates, and time mark and puts it on own pins so even 80C51 can do that, or cheapest AVR. (Just get big enought to have many free pins)

As bitstream can be lagged (FIFO, Serial, USB or whatever, bad jitter) the LinuxCNC should do little more..
The stepgen routine should be little changed. As only stepgen.makepulses is called in base thread this is point where change is needed. Instead to call it in base thread we call that in servo thread. (the base thread is not needed at all).
now the makepulses need to prepare data fo be sended.
What changes is needed.
- the makepulses need one more loop to simulate for example 50 calls as it should be if there was still base thread at 20us
- the period parameter should be incremented for 20us for every pass of loop (to mimic base thread)
- on end of each loop the motor signals are buffered to some internal FIFO.
- on the 1'st call (every 1 us of servo thread) the timestamp is added to fifo too

that's all about filling FIFO.

on the other side we need to read that FIFO and send it to external MCU. So new component should be made. As I playing with my pendant and check response time I see that even userspace component is reacting fast enought to send data to port. I don't know if USB/Serial is supported in realtime comp.
So the read component should have access to fifo buffer made with stepgen, and grab some bytes and send it over IO channel. Maybe simple protocol to check if some error are present and make retry if necessary. The component should expose other IO pins too as all can be pass trought external controller.

In that case the LinuxCnc should work, but it have limitations. No rigid tapping and similar stuff. Even limit switches is delayed but should be no problem. We get little more overshoot and if backoff speed is low enought the precision is not disturbed. Same is for probe if installed. If move slov then should work. As steeper can got pulses delayed for few miliseconds the safe speed for such thing is just around 100 to 200 pulses per second. But moves can be done really fast and accurate! (probably simulating 10us basetime is possible)

Does someone view some problems on that?

andypugh wrote:

This is how the Beagle-Bone PRU-based stepgen and the Mesa and Pico FPGA-based stepgens work.

Huh.. I didn't check the code for that. I was thinking that step calculations was done in fpga and not in PC.
I need to check that too. If $2 microcontroler can do near same as Mesa...

And need to check how bad the usb lattency is. So if we can solve problem with that there is a lot wider spectrum of computer (mostly laptops) for small desktop machines.. Netbook and Reprap or even small desktop cnc could be so nice. Maybe even android table can be used for that...

I think Andy led you slightly astray. I think what he meant was that hardware based step drivers don't use a base thread.
They indeed do do the step calculations in the hardware.

What you are suggesting is to buffer the step commands send them to a microcontroler then send them to a stepper driver using the microcontroller to assure the period rate of commands by adjusting according to time stamps. Am I right ?

The is a fork of liuxcnc that uses USB to connect to a mesa 7i43. They do this by putting the trajectory planer in the 7i43.

Buffering commands has never been a popular idea for the project. As you pointed out it limits what can be done or ties you to a particular piece of hardware.

Not to discourage your idea, but to put it in perspective...
To me it seem a lot of work to produce a limited piece of hardware that is not likely to be incorporated into linuxcnc.
PC hardware is really not that expensive and the future is bringing products such as the beaglebone black that is cheap and small.

not sure if you have seen this:
wiki.linuxcnc.org/cgi-bin/wiki.pl?Emc2HardwareDesign

Chris M

I know that Hardware design page, and I know that I violate them.
.. but I can't stop thinking to that.
If I use beaglebone or raspbery or similar.. They have small ram, small storage they need external display...
And cost is somewhere from $50 to $100 and another $100 for lcd monitor.

In the other hand the 5 or 10 year old laptop has more computing power and cost way below $200. And has display already. And relatively big drive and.. waiting to be used.
The bootleneck is that this laptop probably HAVE very bad lattency. I had 3 of them "on stock" and one has 18us latency and rest about 50us. As base thread should be higher than lattency figure (probably by factor of 2) the acquired steprate is just to slow to be usable.

So if there is chance to preprocess all data in realtime on PC and mimic base thread of 10 us the steprate should be high. And as I see there is no big overhead for external controller. It should not take to much development time. Wee need to create realtime component (heavily based on stepgen, writte to software FIFO instead pins), Another component to send data to the hardware, and of course hardware itself. (Basically that functionality is very close to the streamer component). For hardware cheapest AVR (the only requirement is to have at least 512 or better 1k of ram for buffer) can be used as breakout card then. I really need to do some test to see if syncing PC clock and AVR clock is doable. (overrun will kill motion and should be treated as hitting limit switch for example).