Project: APrinter firmware

I'm creating this thread for general discussion and announcements related to my APrinter firmware.

The full feature list is on the wiki, but here are some things I would like to highlight:

• Highly configurable design.
• Runtime configuration system with configuration store.
• Delta and CoreXY support. Actually adding a new geometry is rather easy.
• SD card printing (only sequential blocks).
• Custom packed gcode format support for SD printing.
• Synchronous stepping of multiple steppers as a single axis (e.g. dual Z motors on separate drivers).
• Multiple-extruder support with extruders acting as separate axes (E, U, V). A gcode translator in Python is available to support gcode using tool switch commands.
• This kind of multiple-extruder support enables full color printing.
• Fan support, any number of fans can be added if hardware is available.
• Portable and ported design based on a custom HAL.
• Supported boards: RADDS, RAMPS-FD, RAMPS, Melzi, Teensy 3, 4pi.
• Written in C++ with a heavy dose of template metaprogramming.
• Does not use the Arduino libraries.

Currently, compilation requires Linux, but the build system is capable of installing most of the dependencies. For Atmel ARM based boards however OSX should work too.

The runtime configuration system is a new feature. It would be great if it got some real testing!

Hi all,

I have done important development for APrinter since. New features include:
- A web based configuration GUI with a service for compiling the firmware.
- FAT32 read support for SD card printing.
- Laser support, or more generally, PWM outputs with duty cycle controlled proportionally to the speed. You can also hook it up to a fan rather than a laser.

Please feel free to try it out and provide feedback! You can find the documentation for all the new stuff in the readme.

Edited 1 time(s). Last edit at 04/17/2015 03:13PM by ambrop7.

Hi,

I have been meaning to try your firmware but I was initially challenged by what seemed to me a complex compiling environment, compared to the relatively simple Arduino IDE.

I am quite experienced with Linux, but I would appreciate it if you could please give me some tips and the required steps on how to install all the bits and pieces to compile your firmware. I am using Ubuntu 14.04 on my workstation, but obviously I can install any Linux distribution in a VM if needed.

Also please can you tell me on what 3D printers has it been tested?

Right now I can test your firmware on Cartesian (a Prusa i3 variant) and on delta (a Rostock variant) printers, both are equipped with Arduino Mega 2560 + RAMPS 1.4 but both can also be equipped with Arduino Due + modified RAMPS 1.4 for Due.

Thanks!

Edited 1 time(s). Last edit at 04/17/2015 06:43PM by AndrewBCN.

Hi Andrew,

Thanks for the interest. The online GUI allows you not only to configure the firmware, but will compile it for you with the click of a button. You receive a zip with the binary that you flash to the chip.

And yet, I have made it particularly easy to compile it yourself - not only that, but to run the web service locally. You will need this if you want to develop the firmware. The prerequisite for this is a Linux machine (or VM) and the Nix package manager. You probably have not heard of it, but this is the essential piece that makes everything else so easy. Once you install Nix (which is simple, just use their installer), you can, with a single command, build a firmware, and even run the web service locally. Plus it's all totally manageable (won't pollute your system). More specifically, all things downloaded/installed end up in /nix/store, and the Nix garbage collector can be used to delete unneeded things that have accumulated.

Just to make it terribly clear, this is all that is needed to run the web service locally (note, the forum software messed up the URLs):

$ curl [nixos.org] | sh   <-- if it fails trying to create /nix, it will tell you a command to run as root, do it, and run this again
$ git clone [github.com]
$ cd aprinter
$ nix-build nix/ -A aprinterService -o ~/aprinter-service
$ mkdir ~/aprinter-service-temp
$ ~/aprinter-service/bin/aprinter-service
Point your web browser to [127.0.0.1] and enjoy!

The current supported boards are, as is written in the readme, RADDS, RAMPS-FD, RAMPS1.3/4, Melzi, 4pi. I don't know about particular printers, but it should be easy to see if the firmware provides the features needed by the printer (see the feature list in the readme).

Quote

Right now I can test your firmware on Cartesian (a Prusa i3 variant) and on delta (a Rostock variant) printers, both are equipped with Arduino Mega 2560 + RAMPS 1.4 but both can also be equipped with Arduino Due + modified RAMPS 1.4 for Due.

The only problem will be running the delta printer on an AVR, it will perform poorly. With Due it should work well. You would create a new Board for your modified RAMPS thing in the GUI, specifying the pins and stuff, starting from the existing RADDS or RAMPS-FD board configuration (hit the Copy button). I can certainly help you with that if you provide details about the connections.

Edited 3 time(s). Last edit at 04/17/2015 07:05PM by ambrop7.

Hi,

Many thanks for your fast reply and detailed instructions!

I will be attempting a compilation this weekend and probably will give your firmware a try on the Cartesian printer first, which has an AVR + RAMPS 1.4 combo. I'll be sure to report back in this thread.

Hi, If I understand well, the APrinter firmware is modular, so it is not so difficult add a new printer geometry. I ask if it is possible control a robot arm with 4dof or 5 or 6dof with this firmware (4,5 or 6 stepper motors). It works with 32bit boards, so the math with formulas and float numbers is not a problem (I hope!). So, knowing the right formulas of forward and inverse kinematics, is possible to implement the firmware?

Quote
alegiaco
Hi, If I understand well, the APrinter firmware is modular, so it is not so difficult add a new printer geometry. I ask if it is possible control a robot arm with 4dof or 5 or 6dof with this firmware (4,5 or 6 stepper motors). It works with 32bit boards, so the math with formulas and float numbers is not a problem (I hope!). So, knowing the right formulas of forward and inverse kinematics, is possible to implement the firmware?

Hi alegiaco,

I'm not really sure how the "extra dimensions" would fit. The firmware is modular to the extent that you can add new X,Y,Z (Cartesian coordinates) to A,B,C (steppers coordinates) transformations, or in general, N Cartesian axes to N steppers. I suppose you could implement something like an (X,Y,Z,angle1,angle2,angle3) -> (A,B,C,D,H,I), though the result is probably not exactly what you want. The firmware would understand all the 6 axes in first set as a 6-dimensional Cartesian space, for the purpose of computing the distance of moves - this affects how much automatic segmentation is done, and how the F parameter is interpreted. It might still work sufficiently, especially if you don't use F for specifying the speed, but the very recently introduced T parameter (see here).

If you want to try adding a new geometry, you need to do this:
- Write a transform class, like this: [github.com] (also see other transform classes like CoreXY and RotationalDeltaTransform).
- Add support to the generate script (which generates the C++ main file from a JSON config file), like this: [github.com]
- Add support to the configuration editor, like this: [github.com]

I may be able to do certain smaller changes to support your use case, if we establish exactly what is needed.

Hi all,

I am pleased to announce that Ethernet connectivity is now implemented in Aprinter (at the moment on Duet only). Specifically, Gcode console over TCP is supported, which can be used by Pronterface.
Instructions for use are in the readme.

Edited 1 time(s). Last edit at 10/27/2015 06:07PM by ambrop7.

About the ethernet part: could we theoretically use something like 3$ ENC28J60 for boards that do not have ethernet on board?..

Quote
toxuin
About the ethernet part: could we theoretically use something like 3$ ENC28J60 for boards that do not have ethernet on board?..

Hi! Yes, theoretically that would be possible, if someone writes the driver for it. It should not be too much pain because I made a hardware abstraction layer for the Ethernet port.
I cannot do this myself at this time, but I can support you in implementing a driver. Here's some hints:

• The current driver for the Due is here. It is not a complete driver but a MAC driver. The complete driver is produced by using this which uses the former as a back-end, in combination with this which commnicates with the PHY through the MII management interface (this is needed for stuff like configuring auto-negotiation and detecting when the link is up/down.
• The ENC28J60 also has an (internal) PHY which is visible though the SPI interface, with a standard set of management registers that are accessed with special commands sent through SPI. So perhaps that same implementation approach can be used here. But since the ENC28J60 does not support auto-negotiation (of duplex mode) and the extended management register set, in this case the GenericPhy code would have to be extended to support this.
• I already have SPI drivers many chips (on the Due, both for the SPI peripheral and USART), so the driver should use this.

-

would implement the driver yourself,

This sounds like an interesting project! My32-bit electronics is on the way and I do not have the aforementioned ENC28J60. I'll get one I guess and we'll see how it goes.
I believe having a web interface on Due-based electronics for +$3 absolutely kicks ass! I don't think any other firmware has that.
I am not that great with C++ though and seeing how awesomly strict your coding style is I start to think I should not embarrass myself... :-D

Quote
toxuin
This sounds like an interesting project! My32-bit electronics is on the way and I do not have the aforementioned ENC28J60. I'll get one I guess and we'll see how it goes.
I believe having a web interface on Due-based electronics for +$3 absolutely kicks ass! I don't think any other firmware has that.
I am not that great with C++ though and seeing how awesomly strict your coding style is I start to think I should not embarrass myself... :-D

I never said there was a web interface, just a g-code console over TCP - not yet at least.

Hey @toxuin,
I figure it makes more sense to pick a chip with an integrated Ethernet MAC, and attach a proper PHY (over MII/RMII interface). This should be almost plug-and-play if using the SAM3X8E, but otherwise requires just coding the MAC driver. I have just ordered two of these and I'll try to get it working with the STM32 dev boards that I currently support.

Hey this is nice! I've ordered one so I would be able to give some feedback once it arrives.
Check out my ESP8266 thread. It needs 3 commands (M408, M20 S2 and M36) on firmware-side to give you a full web interface with temperature plots and file uploads. Just saying

Hey,
You ordered the Ethernet interface, for use with which board/chip? Are you planning to wire it to a plain Due or a custom made board with the SAM3X8E?
That's a very nice achievement with the ESP8266. I'm thinking about adding support for that same OrmerodWebControl web interface directly in Aprinter - to host the files from the SD card and implement the required API requests. I already have infrastructure for the Ethernet/TCP/IP networking so it shouldn't be too hard.

I have one of ENC28J60 coming in a week or so and recently ordered one DP83848.
I am using an Arduino Due. I heard that you have to solder some traces or even chip legs to be able to use ethernet on Due. Is it true and really necessary?..
About the web control from ormerod: your code is "All Rights Reserved" as far as I remember and web control is GPLv2 (v3?). Am I wrong or does this make those two licence incompatible?..

The Due has the Ethernet pins exposed on a small connector; looking at [www.arduino.cc], it's the one above the "www.arduino.cc" label. You can also find the connector on the Due schematic. So my thinking is, we should just connect the right wires together and see if it works

My code is BSD 2-clause license, a very liberal licence. I don't think the licence of the web control code matters much, since they wouldn't be combined. The web control code would reside on the SD card and just be served by the (upcoming) embedded HTTP server in Aprinter.

Edited 1 time(s). Last edit at 11/21/2015 06:48PM by ambrop7.

Hey @toxuin, turns out I was wrong, the original Due does not have Ethernet pins exposed. If you'd like Ethernet, you would have to connect directly to the pins on the chip some way (which is doable, see what I did here with the Teensy), or buy a Due-like board that has the Ethernet pins exposed, e.g. this.

Edited 1 time(s). Last edit at 12/04/2015 03:54AM by ambrop7.

Quote
ambrop7
Hey @toxuin, turns out I was wrong, the original Due does not have Ethernet pins exposed. If you'd like Ethernet, you would have to connect directly to the pins on the chip some way (which is doable, see what I did here with the Teensy), or buy a Due-like board that has the Ethernet pins exposed, e.g. this.

It's good to see this board. I never understood why the designers of the Arduino Due used an expensive Ethernet-capable chip without making the Ethernet port available. If they didn't want to provide Ethernet, they could have used a much cheaper chip such as the ATSAM3S4C.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yes, it's a waste to have the MAC without the ability to use it. Anyway, on the same page they also offer an Ethernet module that directly connects to this new Ethernet header. It's a little annoying that their module obscures some of the headers on the board if you connect it directly. But presumably any other RMII compliant PHY should work, or you can put the Ethernet module on a cable.

Hi I just came across your firmware and googled it to reach here.

I know this is an old thread but I'm curious to know of the current status of the firmware. Does the firmware support a display?