Is there any interest in an improved controller board? I was a bit surprised that the TAZ used the old Rambo board that essentially uses an Arduino. There’s a lot more horsepower these days that can be achieved using the same general class of silicon.
The more modern STM32H7 series controllers can operate at 480MHz. I believe the Mega runs at 16 MHz. This opens up the stepper motor controllers from using the older A4982 that can only do 1/16 microstepping to 1/64 and up to 1/256. This offers a lot more control. This could even be expanded to having the micro load the gcode into off-chip memory and then all the steps being DMAed from memory though a CPLD/FPGA to command the motors. This way the controller just handles communication with the outside world, loads the commands, and then can opperate in paralell with the actual printing. If that’s the case then even when printing over USB you’ll never run into the situation where a sudden Windows Update, BSOD, etc could interupt the print. You should then be able to provide better telemetry back to Cura since the micro is just observing the print and events and can provide updated line counts and general information.
Folks have replaced the original board with a much-improved version, running the same Marlin firmware – reports are very positive about that. Search this forum for information.
Another alternative is Klipper (https://www.klipper3d.org/) which does the work of gcode processing and the math involved to handle the printer physics on a host computer rather than on the anemic built-in board. This results in the built-in board handling nothing but the steppers and sensors.
@mwester Is that the same RAMBo board, but with updated firmware? Same with Klipper.
I’m a design engineer and I’m curious if there’s any interest in designing and open-sourcing a much more modern design. Looking at the schematic for RAMBo, it’s rather… “long in the tooth”. It would be quite easy to put together something more flexible and with a substantial improvement in horsepower to improve reliability, accuracy, and robustness.
Why? Just get a raspberry pi and install octoprint and let it do all the heavy lifting, the arduino is quite capable of doing it’s job. An added benefit is you have much more power and flexibility than a new control board can deliver, additionally you have enough power to do many other things. Go to raspberrypi,org and find out what your missing. Your highest end is available with your tax already. Google “raspberry pi” and “octoprint” and it doesn’t get better than that.
@spike, the existing controller is really dated and not entirely designed for the specific application. I would classify the Rambo as a “firmware development PCA” for printers. Not a professional design for the lulzbot.
There are a lot better stepper drivers these days. More aggressive microstepping can allow for more precise stepper motor control and smoother movements. The existing Rambo board also doesn’t support encoders. For something that moves continuously for days really should have some feedback to be used to detect if the nozzle was bumped off so it can reset and retry the print. Or automatically abort.
The thermistors are just being read directly by internal ADCs on the micro and are being used to change a PWM output of the heating elements. This really should be an analog circuit where the microcontroller sets a voltage setpoint through a precision DAC and then an analog PID to do the actual control. This is significantly faster and more precise.
It doesn’t even look like the micro has a POR. Nor are the voltage rails being monitored.
There really should be two processors on this and some form of off-chip memory. That way the primary communication processor handles commands and debug information from an external source (your PC, a Pi, etc). Then loads the gcode into memory and then the motor control subsystem micromanages the stepper motors and DMAs the commands from memory. This allows for much tighter control loops.
Then the communication processor can supervise what’s going on. The temperature control should be “set and forget” using a DAC and an analog PID, but the processor monitors the whole system makes sure everything is in bounds, monitors the actual position of the motors with encoders, and can stream debug/system information much faster and more precise without bogging down or disrupting motor control. It’ll also allow for more up-to-date information in CURA. For example you would then be able to monitor the exact layer count and nozzle position in software. It also facilitates much more improved quality control and customer support since you would be able to set error codes more tightly (and more detailed) and have the entirety of the system monitored. Being able to see EVERYTHING that’s going on in numerical data has helped me a lot in troubleshooting significantly more complex systems by just remoting into the control software and watching the data. It also helps for QC when building so you can do automated routines for calibration and configuration. Plus more detailed POST routines on startup.
@edge, I would have to disagree on that. I would not pass the Rambo in a design review. There’s a decent amount of glaring issues in both the schematic and the design. There aren’t even version sensing resistors and although there’s some test points for the stepper motors, it does not seem to be designed-for-test with 100% test point coverage. It just doesn’t look like it’s designed to be a product, but a firmware testbed.
People can get too hung-up on this. For a desktop system (especially a large format one) the overall XY space for the board is fine. The board could probably stand to be a bit bigger to make wiring better.
Version sensing and design-for-test are things this is lacking. Plus the overall architecture is a bit prohibitive since a device like this really needs to support a supervisor setup in order to properly monitor and diagnose the device while in operation. The part of the system that’s operating the motors and the nozzle should be separate and isolated so that it’s fully dedicated to the task. Where-as the supervisor monitors the system and can relay that information back to the system.
Re: Enhanced function capability
To go along with improving the architecture, there needs to be more expanded memory on the system. It should retain a log of error codes for the system so that after a failed print you can go back and review the logs to determine just what happened. Are you looking at an issue with the system? Or was it just environmental or a filament issue? Moving to a more modern processor for the supervisor would also allow for more connectivity options. The device really should be able to operate over a network using Ethernet or WiFi and you should be able to send the entirety of the print data to the device at the beginning of the print. If your computer goes down whether your laptop ran out of battery, windows update, unplugged the USB by mistake, the printer should be able to continue with the operation and you should be able to load the software at any time to be able to see the status of the print or queue up the next action.
Re: Environmental Hardness
For starters, the stepper motor drivers and power mosfets should have heat sinks. The traces from the drivers to the motor connectors are a bit long.
Perhaps then you should redesign and improve the Rambo printer control board on all those points. Innovation and generational engineering advances are what moves societies forward. You’ll need a plan to capture marketing share and sales should you succeed. Don’t forget design to cost parameters.
But do note that the Rambo 1.3V I have in my printers - work fine…
BTW, “Good enough” is a valid strategy in design engineering.