Just finished hacking in printrboard REV.F support into the latest version of Marlin.
Haven’t tested it yet, but at least it compiles. I have no idea if I did it to spec, but the hack involves adding support for the DAC that the printrboard uses.
I’ll be able to test it later this week.
Any arduino/marlin gurus want to take a look and make it official?
https://github.com/StephS/Marlin
Sweet! Tried to do it, but ran out of Flash with the tramming correction implemented 
The DAC code is messy. It’s an object, instead of a set of functions. It looks like the library is an off-the-shelf lib for the DAC. It could probably be cleaned up a lot to save room. How much were you over by?
Oh, that was in regard to an older version of Marlin that I tried to run (didn’t implement current control)
Just did a quick compile, and the line "mcp4728 stepper_current_dac(DAC_STEPPER_ADDRESS);
" in the stepper.cpp source file throws an error (‘stepper_current_dac’ was not declared in this scope) if it’s not enabled (can’t find that define)
I’d love to throw this version on my Simple if everything works out!
I had that issue too. I don’t think I configured the sketch correctly or something. It wasn’t building the mcp4728.cpp for some reason. Try going into add files, and add it again.
I found it, and fixed it. grab the files again. I forgot an include.
I know it’s not kosher but we just remove the LCD support to free up space. We are just playing around, but with the free space, we implemented an rgb led for status indicators, added e min and max for paste extruders using a syringe, and should soon have a working example an esp wifi chip and SF card add on that allows us to print using our cloud services and new software. I say this to complain about the lack of space available in Marlin (when using the AVR chip we chose).
Marlin would require an almost complete rewrite to implement best practices and trim the code down to sin levels. Imagine if all manufacturer-specific code was stripped out (including our own), and all non-Cartesian code, and crazy non-standard proprietary mcodes, and, and… It’s just a mess in there.
I just wish it was pure motion control and no LCD menuing, etc… If that were the base and you had to fork it to implement manufacturer specific needs (like ours) then it would have more life. We’ve had serious internal discussions about jumping ship to repetier (or other) that has a simple transition to ARM for the future. All our effort to twist Marlin to our needs seems more and more like water effort.
/end rant
You know what I would like? A board that has it all…heaters, thermisters, motors, WiFi, touchscreen and purpose built OS. The printer would be its own stand alone device. Yes I can do that with all sorts of lashups but If I can get everything that connects all the parts and turns them into USB devices then all of it goes into some sort of hub and voila. Yeah ok, I’m not all that sane but I can dream
@Samer_Najia , the closest you would be able to do now would probably be something with the BeagleBone Black running either a MachineKit or Redeem with the Replicape
It’s all being actively developed
Good morning how doing I really I love your profile
@Brook_Drumm I don’t really code, especially if the code base is not my own. Marlin just feels dirty. The new RC makes it easier to sift through and add functions, but it’s still ugly.
The preprocessor has to handle a lot of the code cutting. You should be able to design it so that all of the unused code isn’t compiled, but this gets really messy really quick. I’m not keen on code and compiler optimizations. I am looking to trim down the DAC library to just the used/required functions.
The amount of files in Marlin is huge. They need a totally new approach to how it is organized. Because program space is limited, some creativity is required.
I think the growing expectations of users has meant that Marlin is getting beyond basic AVR controllers. It originally fitted into 64k devices, you can shoehorn it into 128k devices but 256k is more suitable. Then there are still performance issues.
I am just beginning my next-few-years project. This is an ARM-based firmware to be written in Ada and verified with SPARK (a Formal Methods proof tool).
Initial development will be using a simulated hardware layer. Physical hardware will follow some time later (I want to balance software/hardware choices as I progress).
The use of a PC-based simulated hardware environment will permit the use of full runtime checks during development which can be relaxed at deployment after significant testing.
I think targeting firmware to a single piece of hardware is a good thing. Kitchen-sink solutions are frought with problems but a well designed intermediate layer between the high-level processing logic and hardware can make future migration easier.
This is a long term project for me and I am making some substantial changes to established practices. For one, although it will support it, the internal functionality won’t be based on G-code. It doesn’t really fit with the way the technology is progressing.
I am tentatively giving this firmware and associated hardware the development name “Fusilier”.
@Brook_Drumm as you probably know marlin started as a simple driver for 3d printers based on grbl which was a cnc gcode interpreter. Arduino was chosen as a basic low cost and simple platform. Nothing stops us to take the next step of taking grbl put it on a better platform and implement the 3d components again. Marlin misses an op system because of the low cost and it was aiming on hobbyist learner market. We have taken it a long way with marlin and the 8 bit controller so probably time to re implement an open firmware but now a bit more professional. Would love to pick that up as a hobby project. Any takers?
I’m grateful for and amazed by how far we have come with an 8bit AVR! Make no mistake. As bad as the code is, it does currently work. End users don’t know or care what runs on their printers. But, soon, I fear users will run for the hills if manufacturers don’t build printers with better UX… Namely, wifi, integration with phone apps, seamless ecosystem to get files straight to the printer w/o friction.
We are trying to lay the groundwork for all of this in the cheapest way possible. It might be possible to add an esp8266 to a printrboard and integrate with our cloud services (slicing, print cue, machine profiles) and software that runs the UI in a browser.
If we can’t make this work, we will have to jump ship from Marlin and move to tinyg. It means more money but it will bring both better UX as mentioned above and much much better motion control and headroom for more features. We are aggressively pursuing both avenues right now.
Brook
@Paul_de_Groot It’s not necessarily that simple.
My personal opinion on Marlin is that it has gone as far as it should. It has seen some clean-up and bug fixing recently but I believe it should now be put into Maintenance mode and just used to satisfy the needs of those building current generation hardware.
Future developments should be directed towards 32-bit processors and better design, coding and testing methodologies. Smoothie and Smoothieware are making good inroads but the project leads need to ensure they are not drawn towards too much diversity.
I have a vision of what I want to achieve. It is not evolutionary but revolutionary in its goals and I suspect that, before it is finally realized, I will need to do some significant patent research and avoidance.
I will try and implement a practical means of keeping everyone informed of my progress.
@Paul_de_Groot and @Brook_Drumm the idea of new firmware that does all people are going to want is an enticing idea I would love to play with. Sadly my expertise writong firmware is zero but I can code. The other thing I have is a printer farm and I can fiddle with hardware if need be. Maybe Brook you will be making a call for volunteers for Printrbot’s next super hush hush project 
@Brook_Drumm A esp8266 would be great integrated with a printrboard as they are cheap and are good for wifi iot projects such as this. Perhaps a more powerful printrboard in the future, a pi compute module or zero based printrboard would have plenty of power, and you can easily add stuff like wifi or bluetooth. Probably some problem with that that I did not think of.
@Alexander_Pritchard Pi running Linux is not deterministic and so cannot be relied upon for realtime response.
If it were entirely dedicated to just printing it might be possible but when you start adding other heavyweight processes you can forget it.
While we’re talking about upgrades, the community needs to seriously start talking about better motion control algorithms. GRBL is old and sad and built entirely around shortcuts to minimize processing load for 8bit processors. It’s a series of hacks and kludge as to get bare minimum acceleration control out of processors that aren’t powerful enough for rigorous dynamics. We need to stop porting the kludges to faster processors! Those shortcuts introduce all sorts of artifacts into prints, that become painfully obvious when you know what to look for. Better motion control algorithms would reduce ringing AND give higher average print speeds.
TinyG is one possible approach here, but I’m personally leaning towards taking acceleration off the firmware and switching from firmware reading gcode to an acceleration-aware language. (Several major printer toolchains do similar things already, such as x3g pre-computing motor steps for Sailfish.) Only step generation then needs to be done in realtime. Dynamics algorithms can be offloaded to a desktop as part of the slicing toolchains and then easily worked on / refactored / improved without worrying about breaking the firmware. And the motion planner segment queue can literally be the entire print. You get massive performance gains by doing this, so much so that an 8bit AVR running pre-accelerated motion commands will visibly out-perform today’s 32bit controllers running variants of GRBL.
@Ryan_Carlyle My intention here is to use stepper drivers with an integrated motion engine. You program the acceleration, flat portion and deceleration profile and tell it to go. The planner just has to match move start/end velocities the hardware handles the grunt-work. The drivers I am considering are STM L6470 chips which are SPI interfaced (in daisy chain fashion). They don’t employ current sense resistors instead you compensate motor voltage against motor Back-EMF.