Anyone tried to make a 3D Printer controller?

What are you developing?
victor_pv
Posts: 1739
Joined: Mon Apr 27, 2015 12:12 pm

Re: Anyone tried to make a 3D Printer controller?

Post by victor_pv » Sun Sep 10, 2017 4:32 am

There is already 2 Marlin HALs for STM32, one that I am working on, based on libmaple, and nother one from Chriss Bar based on the GENERIC core.
Mine, depending what options you pick, fits in about 90KB of flash, so can run on a CB (or a C8 with 128KB). The biggest issue with those MCUs is that they don't have enough pins for everything, so you have to pick what you leave out.
So I'm testing mine in an RCT6 board, with 256KB of flash and 48 of RAM, and so far fake printing works fine (no steppers connected). I have tested the same print takes the same time on my HAL on a STM32F1, as in the LPC1768 HAL that runs in the Re-arm or smothieware boards, so the stepper code is running at the right pace. I still ned to plug it to a printer and run an actual test, but I am still working on other parts of the HAL.

Normally you need at least this many pins:
Min 4 steppers, 3 pins each (DIR, STEP, EN): 12 pins
Min 2 thermistors: 2 pins
Min 2 PWM outputs for heated bed and extruder
End stops: 3 pins
USB 2 pins
If you use sdcard 4 pins
If you use an LCD, 4-6 pins, depending which.
If you use a rotary encoder for navigatins menus, 3 pins.
Beeper 1 pin

That gets you a basic printer, but not much special about it, other than should run smooth at fairly fast speeds. As you start adding up pins for all those things, you may not have enough in a C8 MCUs.
If you want to use eeprom emulation for the settings, that uses some extra flash, or if you want to use an actual eeprom, you need 2 pins for i2c
If you want to use bed levelling, or more steppers, or any other input or output, you can see how the c8 mcus won't have enough pins.
I found a nice excel table with all the pins for each version of the MCUs (48/64/100).

With 100 pins you can drive 8 steppers, plug pretty much anything you want, or run less steppers and a few other input outputs, including pins for i2c eeprom, pins for sdio sdcard, 2 SPI ports free for other things (the 12864 grapihc displays controllers have a hardware defect and can't share the SPI port).

Scientist
Posts: 2
Joined: Sat Sep 09, 2017 8:33 pm

Re: Anyone tried to make a 3D Printer controller?

Post by Scientist » Sun Sep 10, 2017 8:14 am

Thanks for the explanation. I was aware of your port and that of Chriss Bar.
I definitely want to give your Marlin-STM32-libmaple ( https://github.com/victorpv/Marlin-STM32-libmaple ) a try on the C8.
So it's nice to hear, you didn't fall into problems till now and "fake printing works" - ok, may be, I am earlier, to connect steppers.
Right, I/O-Pins is an issue. But, if you remember NanoHeart (http://reprap.org/wiki/NanoHeart ) - for most simple 3D-Printers, it's enough.
I/O-Pins are different quality: Sure I2C, should be open to extend, interconnetion(USB) a must, Step/Direction-for steppers are most important, AD for Sensors (thermistors) are important.
Nanoheart enables all XYZ-Motordrivers in common. End-Stops are simple stuff. (Somebody already mentioned here, can be used as R-Network on an AD-Pin).
Sensor-Readings may be muxed with Enable-IO and so on, if you get in need for another stepper-motor. SDcard SPI has CS - so potentially shareble. Local Operating & display has many options and they can be implemented with a bus or completely remote (Smartphone ... ).
I myself prefer, reducing wiring of sensors (or noncritical On/Off-Signaling) by using simple 8pin-AVRs distributed in the cable tree. (cable costs and organisation is an issue).
Conclusion: Its nice to have a hundred IO-Pins at the uC - so, you don't have to think about and count the pins. For a 3D-Print-Controller from point of IO , I think, it's also feasable with the C8. (Your List counts 35 + 2 for I2C - that's all of the C8 + LED to share). May be, if you need extended features, you have to think about Sharing IO-Pins or simple Multiplexing. IO may be also sophisticated distributed (Simple Bus and peripheral uC-Nodes) with some other useful effects, if Firmware would implement hooks for this. If it comes to more features, from my point of view, it's also a nice idea to have a sister-Pi ( Rasp.Pi Zero or Orange Pi Zero ) on the Printer.

But first, I am interested, to get a C8-FW running reliable.
One point on Teacup: It's said, much higher stepping rates are possible.

alce
Posts: 6
Joined: Sun Jul 30, 2017 8:30 am

Re: Anyone tried to make a 3D Printer controller?

Post by alce » Mon Sep 11, 2017 11:19 pm

xebbmw wrote:
Thu Aug 31, 2017 4:02 pm
alce wrote:
Fri Aug 25, 2017 8:20 pm
Ok, short update on my stm32f446re plan.
I got the ramps 1.4 board and it turned out the arduino connector on nucleo board does not populate all the necessary pins so I ended up having to add about 20 dupont cables.
The wiring I did turned out pretty neat so not much of a deal breaker for me. I got all motors working, 3 endstops, fet. I ended up grouping all the motor en pins together just to make my life little bit easier.
I switched SD card to 1 bit SDIO mode which boosted write speed to ~1mb/s from 200kb/s SPI. Smoothieware uses some uip lib to do tcp/ip in software and since W5500 does it in hw it occurred to me
that it would be faster for me just to boot the whole network module and do a very simple telnet and sftp myself. Which I did and it takes about 80 seconds to transfer 4MB gcode file which I suppose is not bad but I think switching W5500 to SPI DMA should at least triple transfer speed.
I dont think I'll bother with any kind of web ui since it seems like a quite a bit of work. The way I would probably go about it though would be to export gcode interface to javascript(something like ajax) and then do all the interactive stuff in js.
BTW, if marlin folks need a basis for network code you could use this one. It is about 1K of code for both sftp and telnet using the wiznet libs. I think the telnet could also be used as an display replacement. Think github.com/hanzi/telnetris

Now unfortunately my nucleo board started acting weird(rebooting when transferring files via sftp) yesterday and today it stopped working altogether so I did not get to print tests quite yet. Suspecting ESD damage...
Fortunately arrow.com sells NUCLEO-F446RE for about 15 usd w/ free DHL shipping so I should get to it next week.
Did you publish somewhere your changes? It becomes interesting ...
On Smoothieware forum it seems the developers are working more on new Smothieware 2 (at least this is my conclusion from http://forum.smoothieware.org/forum/t-2 ... 32-support)
I have not published anything yet. I find this ramps board a bit of a nuisance to fiddle with because the pins are not labeled and have to go through schematics to track down the pins. I am leaning towards wanting to replace ramps 1.4 with a 4 channel fet driver(off ebay), motor driver pcbs and a little bit of electronics for the temperature sensors. I think this kind of setup would be more suitable for the esp32 module later on. Also the W5500 ethernet module seems to have some compatibility issues with some routers so looks like I have to swap it to ENC28J60.

xebbmw
Posts: 15
Joined: Tue Aug 02, 2016 3:34 am

Re: Anyone tried to make a 3D Printer controller?

Post by xebbmw » Tue Sep 12, 2017 10:13 am

alce wrote:
Mon Sep 11, 2017 11:19 pm
I have not published anything yet. I find this ramps board a bit of a nuisance to fiddle with because the pins are not labeled and have to go through schematics to track down the pins. I am leaning towards wanting to replace ramps 1.4 with a 4 channel fet driver(off ebay), motor driver pcbs and a little bit of electronics for the temperature sensors. I think this kind of setup would be more suitable for the esp32 module later on. Also the W5500 ethernet module seems to have some compatibility issues with some routers so looks like I have to swap it to ENC28J60.
When teacup firmware was ported to Nucleo-F401RE the author used an Arduino CNC shield instead of Ramp 1.4, it is not expensive on ebay. It fits very well in the Nucleo board just need to configure the pins properly. Maybe you could use the same for your tests.

alce
Posts: 6
Joined: Sun Jul 30, 2017 8:30 am

Re: Anyone tried to make a 3D Printer controller?

Post by alce » Sun Sep 17, 2017 1:14 pm

Okay, I managed to get the wiring somewhat right for a test print. Unfortunately uart crashes soon after the fast moves start. I do think it is probably caused by the fact that some of the pins are shared by the nucleo debug interface that provides uart to begin with. I have not found exact docs on how exactly did the wire the thing and I would not be surprised if the info is fine printed page 241 of some manual. It is a bit difficult for me to proceed without eth and cnc shield so I guess more waiting it is then.

Anyway if someone wants to give it a shot fw is at https://filebin.ca/3ahQAie012Lv/main.bin . Put it in msd of stm32f446re nucleo . There is a built in configuration in the firmware which is set to baud rate of 115200. The temp sensor is hard wired to PC1 and all temp sensors you define in config will read from this pin. I poked the code a bit to support endstops tied to one pin trying to home with delta, corexy etc. probably is not going work unless you disable itrim_homing in config.

sd card(in sdio mode):
mosi pd_2
sck pc12
miso pc8

w5500 ethernet:
SPI2_MOSI PB_15
SPI2_MISO PB_14
SPI2_SCK PB_13
SPI2_CS PC_6
ETH_RST PC_5

victor_pv
Posts: 1739
Joined: Mon Apr 27, 2015 12:12 pm

Re: Anyone tried to make a 3D Printer controller?

Post by victor_pv » Mon Sep 18, 2017 3:38 am

I may have misunderstood you, but I think you are looking for the Nucleo 446 schematic to see how the stlink onboard and the 446 are wired?
That's available here:
http://www.st.com/en/evaluation-tools/n ... 446re.html

Search for the word schematic and it's there. All the nucleo boards are wired very similarly as far as I know.

ag123
Posts: 796
Joined: Thu Jul 21, 2016 4:24 pm

Re: Anyone tried to make a 3D Printer controller?

Post by ag123 » Thu Sep 21, 2017 3:12 pm

i'm halfway wondering if marlin or more correctly both marlin and 'gcode senders' if there are any desktop 'g-code sender' that routes g-codes to multiple 3d printer controllers

i found at least this
http://winder.github.io/ugs_website/

but i'm not too sure if the more popular variants e.g.
http://octoprint.org/
https://www.repetier.com/
after all does that

if it does we can possibly have multiple BP/MM doing different things, they can after all be hooked up on a same usb hub via usb-serial.
e.g. we could have one BP/MM dealing with the xy motors and maybe endstops, another deal with z motors, z endstop and extruders
then yet another deal with heating, temperature monitoring and maybe handle an ILI9341 display

https://www.simplify3d.com/support/arti ... -tutorial/
an issue is like if there are 3 gcodes e.g.
G1 X0 Y0 F2400 ; move to the X=0 Y=0 position on the bed at a speed of 2400 mm/min
G1 Z10 F1200 ; move the Z-axis to Z=10mm at a slower speed of 1200 mm/min
G1 X30 E10 F1800 ; push 10mm of filament into the nozzle while moving to the X=30 position at the same time
some protocol is needed to keep the 3 controllers BP/MM working in sync

victor_pv
Posts: 1739
Joined: Mon Apr 27, 2015 12:12 pm

Re: Anyone tried to make a 3D Printer controller?

Post by victor_pv » Fri Sep 22, 2017 7:09 pm

I get a feeling all that complication would not be worth it when an RCT or a VCT MCU have many more pins and cost almost the same.

I am in the process of building a 3d printer controller board around an STM32F1 or F4 daughterboard (Vxx MCU, replaceable).
I am basing my design off the many other existing open designs, such as RAMPS, RAMPS-FD, Smoothieboard, etc...

6 steppers, pololu format pluggable (but allows up to 8 with little modification, pins are already accounted for it).
4 thermistors (more optional)
4 high power FETs (bed, extruders...)
2 low power FETs (fans)
SDIO + SPI SDcards support.
LCD + rotary encoder +button for input (SPI2 port and USART ports available in the same pins, so more advanced displays and inputs can be used with the same pins in different function mode)
EEPROM onboard for settings + I2C connector for anything else in I2C.
USART1 connector
Several pins left for expansion, to be used for IO or analog inputs, including PWM functionality, an SPI port, and USARTs
SWD pins available for debugging (not using them for any other function)

All that is possible with the 100pin MCUs (Vxx) carefully planning what pin is used for what function, if jumping to the Zxx 144 pins MCUs, it would be possible to do all that, plus leave a lot of pins and ports for future options.

An Rxx MCU would have enough for a basic printer if the ENABLE pin is shared by all steppers, otherwise there would have to be compromises here and there (forget the LCD, or forget the SDCard), but then the point is, why build a basic printer board? there is already a ton of them available for cheap. Could be ok just for testing code and individual functions, but I'll rather use my time in getting as much as possible out of the STM32 MCUs.

There is a Marlin HAL for LPC1768 mostly working (although with some issues, some people report the boards hanging midway thru the print, I have had issues with some sdcards...) that I have been helping with a bit as I can.

I think given the nice cores we already have, that an STM32 printer board would work better, with less issues, and allow features to be added more easily. I have my libmaple HAL already working with the core functions, need to add the eeprom support, and test LCD display, sdcard, but all those things are already working with our cores, so should not be an issue at all.

And I planned all STEP/DIR pins in the same GPIO port, so if at some point it Marlin can be modified enough, write those with DMA from a buffer, a single DMA write could set and clear all STEP/DIR pins at once, rather than the individual set/clear that's done in Marlin at the moment. But that's looking at the future, since currently Marlin does the GPIO wirtes in the same ISR where it calculates when they should be done. All that could be decoupled to a function that writes to a DMA buffer, programs the DMA and a timer trigger to the right frequency, and fires the timer. While that's sequence is outputting with DMA, it can be calculating the next moves in a second buffer and fire it as soon as the previous DMA is over. So separating the output part (managed by DMA+Timer) from the steps calculation part, that just prepares the buffer.

ag123
Posts: 796
Joined: Thu Jul 21, 2016 4:24 pm

Re: Anyone tried to make a 3D Printer controller?

Post by ag123 » Sun Sep 24, 2017 5:30 pm

unlike the more elaborate stepper motor controllers from ST, many of the A4988 RAMPS stepper motor controllers are rather basic
https://www.pololu.com/file/download/a4 ... e_id=0J450
and it would seem that it wouldn't be possible to share the step and dir pins as there isn't a chip select pin on those a4988 controllers.
as to sharing /enable my thoughts are that it may be possible but that it would depend on how marlin is programmed. if it expects /enable to be independently controlled, there may be a catch in that marlin is trying to control a single motor and it pulls up /enable which causes all the motors to be disabled simultaneously instead
this would mean having 2 independent pins for each motor at least, in terms of microstepping resolution my guess would be that it can be set at a constant 16 microsteps, so that would mean we'd need at least 2 pins step and dir for each motor, and if /enable can be shared, that would save a couple of pins.

while using dma is attractive, it probably isn't really necessary as the step signals would probably be in the hz ranges as we are moving motors which can't literally respond faster than that. i think the motor controls isn't literally 'blocking' for that matter, in a sense that the gpio pins for step and dir is pretty much 'fire and forget'. lets just say that we pulse step for 1 ms, between one microstep to the next we may need to provide 10s of ms at least for the motor to complete the move, so in between steps the mcu can already perform lots more other processing including parsing the next command , doing the calcs, optimizing the next move etc and there may still be plenty of time left till the next step needs to be taken.

i.e. with ramps type of boards, we'd need to use a mcu with adequate number of pins to run it which things like vet would probably adequately meet that

strictly speaking the other way that we can do it is that instead of ramps we can use ST's rather pricy stepper motor controllers / driver L6470
http://www.st.com/content/st_com/en/pro ... l6470.html
http://www.st.com/content/ccc/resource/ ... 255075.pdf
https://www.ebay.com/sch/i.html?_from=R ... 70&_sop=15

this stepper controller is actually much better than do the A4988 with 128 microsteps, it may literally make rather 'silent' 3d printers
the L6470 uses SPI for the interfaces which in effect reduced that to 3 shared pins (MISO, MOSI, CLK) and one independent CS pin for 3 xyz motors + 1 extruder that reduces the total pin count to a mere 7 pins running the motors. however, there are still the end stops and temperature control and thermistor) there may be 2 sets the hot end 1 heater + 1 thermistor and the heated bed 1 heater + 1 thermistor
unfortunately the L6470 is pricy

an alternate is to get st's own (rather pricy) 3d printer driver board which sports a stm32f401 along with L6474 motor drivers (16 microsteps only though)
http://www.st.com/content/st_com/en/pro ... 001v1.html

victor_pv
Posts: 1739
Joined: Mon Apr 27, 2015 12:12 pm

Re: Anyone tried to make a 3D Printer controller?

Post by victor_pv » Sun Sep 24, 2017 11:45 pm

The steps are normally in the range of 10s of Khz in the AVR, depending on what speed you are moving and how many microsteps per full step, but in the AVRs, people is hitting the limit, at which point the moves become jerky when the CPU can't keep up with the required number of steps. But that's at 8 or 16Mhz. So even though at the moment I don't think just moving motors would hog the CPU, when you add to that reading from an SDCard, or reading/writting to USB, plus a diplay, plus bed leveling calculations (those are cpu intensive), then CPU usage goes higher an higher.
At the moment Marlin has trouble keeping up with certain speeds when bed levelling is enabled. I am sure as the 32bit platforms become the norm, more features, more precission, etc will be added, until again reaches a point where the CPU alone can't keep up.
So that's why I'm planning ahead and making sure hw peripherals and DMA can be used in the future.

Just to give you an idea where Marlin is right now, some displays use software SPI... just because the AVR have a single SPI port, and there is some LCD displays that can't share a port (no matter how CS is managed).

In the Re-ARM board, which uses an LPC1768 with 2 SPI ports, one is dedicated to an onboard sdcard, which is not used for printing, then the second port is used for the SDCard in most LCD panels. And then the LCD displays that use SPI, have to use software SPI... That just so an SPI port is used for board itself to save EEPROM values.

I'm trying to plan ahead for all those limitations, or at least the ones I can avoid. I reserved 1 SPI for the SDCard, 1 SPI for the LCD, and 1 SPI is still free, so if in the future I device to use steppers with SPI control, I have that hardware port free for that.
Same with USARTs, 1 broken out, another one shared with the LCD pins, so if instead of using a normal LCD panel, you use a Nextion display (uses serial), you can connect it to a hardware serial port since the pins were reserved for LCD.

About STEP and DIR, I think the same, those can't be shared. About ENABLE, seems like Marlin can take it being the same for all steppers, but I also think that wouldn't be ideal.

That's why even though I am testing code in a RCT6 board, I'm designing my own for an VET MCU, so I have enough pins for everything.

The step control part is an ISR, when it's doing it's job, it blocks everything else other than interrupts with a higher priority, so if the stepper code can't keep up with the pace, the printer just becomes sluggish.

Post Reply