@Neil_Darlow How’s the cost on those? There are lots of nice servo-based systems available that work similar to that, but they tend to be too expensive for broad uptake.
@Ryan_Carlyle Quite affordable. In the same price range as 8825s.
So, all this talk about how marlin is broken… But there hasn’t been a unified effort to design a replacement.
Yes, supporting 50 or so different hardware configs, plus the countless machine configurations makes for messy code, but marlins popularity is due to it. Any new firmware needs to have the same broad interoperability, but better managed. It can’t be designed for only a few configurations, than nobody will design hardware for it.
Anyways, I haven’t flashed this firmware to my board yet. I’d be curious if it works.
@Stephanie_A A matched hardware/firmware combination is viable. Much like an OEM component.
Sailfish is a good example of open source firmware designed for optimum performance with specific hardware. It greatly outperforms Marlin using the same processor, but is optimized for Cartesian printers running a small number of electronics options. (Mightyboards, Azteeg x3, and older Gen3 electronics.) Believe it or not, Sailfish has about as many users as Marlin, but almost nobody forks it or builds their own code, because it’s a complete, highly-optimized, and feature-rich firmware for a specific range of hardware. Minimal customization is done by editing a text file that updates EEPROM via host program. Sailfish has superior safety functionality, extruder volume control, acceleration control, and top print speed compared to Marlin, because it’s optimized for specific hardware instead of generalized for code legibility and forking.
Going in the other direction, RepRapFirmware (specifically dc42 fork) and Smoothieware are both effective “one build for all printers” firmwares. They’re configured at runtime by a text file on an onboard SD card. They can certainly be forked, but if a feature is good enough, it gets added to the main branch and enabled via text config file that is read at start-up. This kind of firmware model easily covers >99% of all printers.
I am paying the Tinyg guys to write the 3D printer portion now… It has been months in the making. It will be available early next year. This is the right path. The firmware is absolutely not notch- head and shoulders above anything out there. My cost will go up $25-$50 but it will clear the way for all sorts of improvements. It’s my move to future proof the electronics road map. It has been quite expensive but I think worth it in the end. I will be the first company to bring it to market but I won’t block anyone from using it- nor will Tinyg. We want to move things forward, and I’m willing to pay for it.
AVR still has a place in the short term when low cost is a big priority. I also think that the significant installed user base will benefit from wifi printing and the low cost of the add-on. Not sure what it will cost yet but it will be a board that mounts on the existing printrboard header pins. We are rewriting how Marlin handles serial connections to make this work and support usb, and the new full sized sd card. Proof of concept should be printing from our cloud software today.
This will be a big moment. In my opinion, it solves frustrations with installing drivers, the difficult to use micro Sd card we currently have, the lack of LCD screen (beautiful UI is on any device w a browser, phone or tablet), and the problem of when people leave usb plugged in and tilt their bots over and accidentally snap off their usb connector. That’s a lot of solutions for one small step forward with an inexpensive add on board!
Brook
@Brook_Drumm I for one will be first in line for orders to put on all my cartesian printers now running RAMPS or RUMBA boards. Thank you. I also will be looking at ways to use this board in my 3-in-1.
I guess I should add an ESP8266 connector to my boards.
@Ryan_Carlyle whats wrong with compile time optimization?
@Stephanie_A Nothing, why?
The kind of optimization I’m talking about in Sailfish is stuff like doing some of the dynamics math in v^2 space instead of v space to reduce unnecessary square roots. Compilers aren’t that smart.
@Brook_Drumm I’ve been wondering for a while why getting 3D printing support into TinyG has taken so long, can you comment on where the complexity is coming from? An approach like Smoothieware currently uses that just slaves the extruder to the XYZ axes seems pretty straightforward to implement.
Tinyg has several things going for it. One is that the extrusion is using volumetric calculations to eliminate retraction and oozing. Corners won’t have over extrusion. Another is the overall goal to make every movement a curve, instead of making a curve a bunch of straight lines. This exponentially reduces the complexity of the gcode. They have an abstraction layer that corrects bad, weighty gcode and simplifies it to correct all the bad decisions made in current slicers (Cura is the worst, according to them). Also, throwing out all the crazy mcodes and attempting to formalize a standard gcode for 3D printing motion control… The manufacturer-specific stuff is relegated to json. This is only part of it… But I am not qualified to speak eloquently about all of it 