This is going to come a bit out of left-field...

3D Printing
,
1

This is going to come a bit out of left-field…

To be clear, I am a software guy, speculating about appropriate hardware, so adjust your expectations accordingly. :slight_smile:

The core problem of a 3D printer is four dimensions of motion (X, Y, X and extrusion). Even a cheap 8-bit controller CPU can twiddle four stepper-drivers, mostly fast enough for present-generation 3D printers.

On the upside there are outfits like Trinamic who come up with up with stepper-drivers that offer more smarts, when controlling a single stepper. Though most folk most of the time are not using most of the features.

What bothers me, as an algorithms guy, is that in model a 3D printer is a singular, simple state machine. In practice we have a slow CPU controlling each stepper individually via each distinct stepper driver. That means skew, in the motion of steppers. Maybe small enough we do not care. Maybe.

In my day job, recently joined an outfit that builds advanced experimental radars for the military. They use a couple of large/fast FPGAs to do very fast signal processing. As my present exercise, re-writing the Linux device driver for controlling the FPGAs. (The box has a bunch of high-end Xeons for more complex processing.)

So … learning about FPGAs. :slight_smile:

Wondering …
Is the usual partitioning of the control logic for 3D printers … wrong?

Older generation FPGAs are pretty cheap. An old/cheap FPGA looks more than adequate for controlling motion in a 3D printer (or other like robots…).

Need to bump up the small voltages (~1-2 volts) to the relative massive voltages required to drive stepper motors (~`24 volts and an Amp or so). Seems the requires simple “driver” chips. (For jargon, called up my father, whose work spanned from the first integrated circuits, up to current cell phone chips, ten years back.)

Maybe the optimal partitioning is a simple FPGA (for exact and integrated motion) hooked to a bank of simple “drivers” (for needed power)?

Maybe “smart” stepper driver chips are … silly?

(Watching videos about FPGAs. Seems they freak out hardware folk. As an algorithms guy, least bothered by the part that most bothers hardware folk.)

An FPGA is programmable hardware. Cool. :slight_smile:

Give me a board with a Xilinx Spartan-6 and adjustable drivers sufficient to power stepper motors, and I suspect we have an optimal motion controller.

(Or maybe something simpler/cheaper.)

Are there hardware folk in this group, who can comment?

2

Hi @Preston_Bannister the cnc control space shares some common ground with 3D printing and there is an open source project in that space that supports fpga’s - LinuxCNC. I have a large mill running it. The high speed functions run on an fpga (encoder counting, servo amp signal output).

3

Larger CNC routers often use a bus such as CAN where it is possible to time the commands, such that each motor starts the movement at exactly the same time.

Small systems can use SPI to program the stepper driver. It will not be perfectly in sync, but SPI is very fast. The system does not move much in the microsecond delay there may be.

4

You can look at planetCNC or PoLabs for controller…

PlanetCNC uses their sw, or linuxcnc…
PoLabs is ment to be used with mach3/4 over the plug-in…

I used pokeys57cnc with mach3 and ethernet connection, for plasma cutter.

5

I get the impression that you, again, try to solve non existing problems.
On one hand you write that a simple 8bit controller can handle everything. On the other hand you see a problem. But I don’t understand which one.
Do you think about replicating the stepper driver logic and combine it with the general printer firmware?
You know that trinamic put a lot of effort in their drivers? You’ll have a really hard time to copy this. The nice thing would be that you could “upgrade” your “stepper” via software.

Or do I misunderstood your point?

6

Is the idea to replace the drivers altogether and connect the stepper motors directly to a FPGA chip? If possible that might be cool but I do not think that it is possible. The drivers are not just logic but also analog power circuits, that are not possible on a FPGA.

7

There are primitive stepper driver chips that only regulate current — no indexing or smarts or whatever. They just do current sensing and PWM switching and run the MOSFET H-bridge required to drive bipolar coils. From there, yes, a single FPGA can easily do the indexing and outputting coil current level signals. Not difficult at all.

Historically though, people who try to roll their own drivers (like Makerbot’s 5th gen) put a lot of work into something that doesn’t perform any better than off the shelf driver solutions.

Where FPGAs make more sense is servo systems where you need to run high-speed feedback loops, possibly even nested feedback loops controlling different parameters. (Torque, velocity, position being the obvious three.)

8

Might create a slightly cheaper 3d printer if we used cheap dc motors with homemade servo control on a FPGA.

9

The main problem has been adoption of the technology.
If you follow Adrian Bowyer’s videos about 10 years ago, such control electronics weren’t available, and it was difficult establish a standard, for which everyone can work from.
Such became the RepRap project.

Once a standard is in place, it is really difficult to displace it, even when there are better alternatives

10

Can we program FPGA for free like we do with Arduino? It sounds like you just want to play with FPGAs.
If you want to do it, go ahead and make a proof of concept. But don’t expect anyone else to do it for you.

11

@Francis_Lee You cannot with Arduino IDE, but who really uses that.
PlatformIO should be able to program an FPGA, else the FPGA company should have IDE and ICP tools.

12

PlatformIO…not off the bat, but yeah it can be adapted with plugins for making an FPGA dev environment.

As for who uses Arduino IDE? People who want to program MCUs without needing to use the ICSP and memorizing cryptic avrdude flags.

I’m not suggesting that FPGA companies create an Arduino plugin, but something similar that’s easy for coders that aren’t hardware geniuses. I guess the answer for now (as per your suggestion) is PlatformIO together with a toolchain like IceStorm or FPGAwars?

13

The reason is why? Why would to make something more complex, more effort to develop? What is there to win? It’s not that the stepper motors don’t perform. They work great, and most manufacturers use over-powered steppers so the open loop system just works. Developing your own motor drivers will just add development costs and for what gain?

For CNC mills this isn’t an option, as the overpowered steppers would become expensive really quick, and thus serves make sense.

There is a lot more to win in the area of motion “planning” then actual motion execution. I recommend looking there…

14

To be clear, I am not interested in slightly cheaper 3D printers. Rather, I am more interested in the next jump in performance.

Motion-planning can be done on a more-capable CPU, and downloaded to … whatever … is driving motors in real-time.

But ideally you want to drive all motors in exact step. That argues against individual smart steppers, but calls for a hardware state machine toggling lines to each stepper, at once.

You can approximate something near to that microcontroller, with a certain amount of skew. (Which is where Klipper is interesting.)

Does this skew matter? Dunno. Suspect it might.

Even very cheap FPGAs look like they might be more than adequate to host the state machine. Clearly FPGAs cannot generate the voltages or currents to drive stepper motors. (In present, steppers seem to have a large price advantage to servo-motors.) Are there driver chips that can translate the small output from and FPGA and generate the large output for steppers?

Reading on FPGAs and how to program… :slight_smile:

15

You might want to follow Arthur Wolf, as Smoothieware is moving to FreeRTOS.
Marlon 2.0 with FreeRTOS maybe coming, but in all reality any 32bit controller will do.
Motion planning is one thing in firmware.

The other is to realise that as CPUs get more advanced, so does the inter track and space parasitic elements come into play and start to cause issues.

Level shift converters are common, and the only real issue is the added cost for the end user. A few bucks more is negligible IMO.

16

First you need to do the math. How far will the stepper move before the signal to the next stepper? Then compare that to the tolerance of the printer. The delay for even the cheapest microcontroller will be less than a microsecond and the movement will be practically zero.

You will find that there is no point to this. The point of using a microcontroller, instead of something like raspberry pi, is to implement realtime control of the stepper. Your thesis is that the microcontroller is no good for that and we need to go one step further to FPGA. But you haven’t done the math and basically are wrong. Sorry.

FPGA is fun and all. Don’t get me wrong. But you will not get a better printer by solving non issues and adding extra components just for fun.

17

If this comes down to two chips - a very cheap FPGA or CPLD, and a many-inputs to many outputs level-shifting power driver (which perhaps has a proper name) … then where are the economics?

View this as moving all the “smarts” from the number of smart stepper drivers onto a single chip, and loading the chip with only and exactly the algorithm wanted by the higher level software. Do we get a simpler design, upgradable in software, and superior in function?

An ASIC with the same design would be cheaper in volume, but the cost of design is high, and the size of the market small.

In any case, a question.

18

@Preston_Bannister a point of clarification… stepper driver chips are already ASICs. Why build custom printer ASICs when we can use off-the-shelf ASICs? There are driver chips that accept motion commands via SPI or other high-speed buses and will generate the entire velocity trapezoid for a move internally without any step pulses or precision timing from the MCU. Some folks have seriously looked at those, although it’s not widespread at this time.

There are multiple reasonable ways to split the load between the various computers and chips involved. Consider at a high level you’ve got to do:

  1. Slicing / CAM
  2. Gcode parsing & user IO
  3. Trajectory planning
  4. Position command transmission
  5. Motor indexing or encoder feedback
  6. Power MOSFET driving and current control

It’s pretty arbitrary which computer does what. #3-5 are the difficult real-time tasks.

  • Old-school parallel port CNC machines put 1-4 on the desktop PC and didn’t have an MCU.
  • Very early RepRaps did 2-5 on the MCU.
  • Most 3D printers today put 2-4 on the MCU.
  • Klipper only puts 4 on the MCU. Etc.

If you want to add an FPGA, that can do 4-5 really well, particularly when you want to run a lot of motors with cheap drivers. Where FPGAs make a lot of sense to me is high-speed encoder feedback servo systems. Or you can use a regular MCU with SPI ramp-generating drivers to accomplish the same thing. Just comes down to trade offs around cost and effort, like anything else.

19

Worth mentioning that the main reason people typically propose FPGAs in 3D printers is to generate very high step rates for a lot of motors. But why are we doing that in the first place? With modern stepper drivers that can interpolate microsteps or run in sinewave voltage mode (Stealthchop) there’s really no point to running 1/128 microstepping or whatever. And steppers are the wrong kind of motor if you need extremely high speeds. And there are other ways to transmit move commands than a frickin’ megahertz-frequency squirt of discrete position increments. So why are we trying to generate a hojillion step pulses?

The stuff MachineKit and LinuxCNC guys have been trying with FPGAs makes a lot of sense — running multiple nested feedback loops on torque, velocity, position per servomotor with precision encoders. That’s great stuff, but it would be insane overkill for a 3D printer laying down a noodle of plastic at <0.2 m/s.

20

If your root motivation is skew between motor controls, not much need to worry. The SW can calculate the signals for all channels in a control frame, and then present them simultaneously. Depending on the control board design, 4 pairs of step/dir signals can fit in a single write to a port. When when the motors are on different ports, back-to-back writes can hit them, with only minimal skew.