The enclosure post

I would like a enclosure for my printer for a couple of reasons. I Print In ABS a lot and I would like to negate effects of the enviroment on my prints. I looked around a lot to see what others have done and many people use Ikea’s Lack table to create an enclosure. They are inexpensive and work well for making a box frame. I must have looked at 3 dozen different enclousers and one printer all made from these tables while looking around for what I wanted. The one that came closest to what I wanted to do was this one I was planning to make real plans and a full tutorial for what I was about to make but one day my friend dave was over we decided to just build it we went to the local hardware place and got some MDF and a plastic panel for the door, some metal hinges and 90deg brackets. Unfortuantely my printer is too tall to fit inside with the tables just stacked on top of each other. I was going to print something to extend the tableleg but since I had found enough wood to make four legs I made legs at 19″. The legs were very carefully drilled out in center and the Ikea provided double screw could then be used to secure it to the table just like the lacks real legs.

The first leg

Next the walls were mesured, cut and screwed onto the outside. I want to keep the build as modular as possible this way the panels can come off if needed.

Painted and ready.

 Every thing was painted a flat black and after drying it was time to start assembling the enclosure.  I first put the lack table down and placed the printer on top of it and cut a small slot for the cabling to sit between the top table and the bottom one. Since the cabling was now recessed enough to place the top on I installed the 3d printer and secured the control box to the bottom of the lower table. Some of the final things like the hole for the filiment feed had to be done after the printer was installed so I could see where things lined up. Then a hole was drilled and a filiment guide installed and finally the top table attached to the bottom one.

It was then time to work on making a the door assembly.Cuttng the  plastic is difficult and I would recommend not only having the proper tool but also someone to help you keep it from moving as you score it.(thanks again dave)  Drilling thru the plastic very carefully we made holes for the hinges, door latch and handle in the plastic. Put it all together and its looks and works pretty good.IMG_20170526_183740

There are some things planned for the future on this such as getting my lighting properly wired into the control box for power instead of on a seperate power source. An Exhaust is needed still and there are currently no cameras in this enclosure. I need to re install my extruder cam as well as a PI  (w/camera) for enclosure control. For this I plan to make a fake walls on the sides and hide all the electronics and filters in that space . i will have a 1x24x24 space on each side to hide this all . This will help to keep the clean look it currently has with little change to the inside.


Moving from melzi to ramps

I have been very happy with my printer except for one thing my printer uses a melzi board. The only issue is there is only one firmware for melzi. This makes testing firmwares in AtCore more difficult since I can’t test on a real machine. In order to do that I need to move to a RAMPS kit. This will allow me to flash just about any firmware that I want. I will keep the details to a minimum for this post would be really long otherwise.


After ordering the nessasary parts all the extra stuff I needed to complete this project I can finally begin. The first step is to build the ramps kit and then install some firmware with a sane configuration. For the first firmware I have decided to go with Repetier 0.92 since its the same as my old firmware.Using repetiers web configuration tool I ran thru all the steps only changing the required items. I was able to download and build this firmware and flash it in no time. The first test of the firmware and the screen didnt show anything. Checking the config I can see that I picked the wrong screen. With that fixed I could discover my next problem the control knob moved backward from what I was used to, it was to fast and had to high a repeat rate . So after a few more configs attempts I was able to get everything worked out and my board was now loaded with firmware.

Mid board swap

Time to take the old control box apart and wire up the new one.. There is only one problem the plugs dont all fit on the new. Every wire needs new connectors. I made all my crimps, wireed the new board and fired up the machine. But there were problems. Y moved in the wrong direction and the Z motors were spinnng wrong. It didn’t take long before I had these issues fixed. With the motors all checked and working I was ready to try the heaters. That was when the fun really started, almost instantly you could see smoke and the mosfet for the bed was burning up. This killed that ramps board so i had to order another.

After a few days of waiting I receved my new ramps board and an external mosfet for the heated bed. With those installed every thing was ready to be put into the old case. I had to made a ramps holder that didn’t push the reset button . I did this by printing a few ramps holders and chopping them up and glueing them back together in way that worked in my case.

Boards mounted in the old case

After that hack job was assembled I still needed to mount the mosfet board. Luckly I was able to find another mount and modify it to mount on the two unused melzi mouning posts.I also needed a way to get some space inside the case and a place to put my usb B external plug so we can plugin the ramps nicely from outside the case. I modified a 120mm fan adaptor to include space for my usb port and put the whole thing together to test. Its been working fine for about two weeks now and its printed about half of its new homes parts.

May ’17 AtCore Update.

Its been some time since I’ve posted any progress for AtCore. Some may wonder what we have been up to ..

  • Implimented a Comand Queue

We would like to get some info from the printer while printing we need to have some method of flow control. AtCore now uses a command queue to send all commands. With the command Queue in place we have to handle stop and Emergency stop differently . For example Emergency Stop should skip the queue and be sent as soon as the button is pressed.

  • Requesting Temperatue from the printer

After you connect to a FW plugin every 5 seconds a m105 will be send to the printer and the temperature results are put onto a pretty graph that Patrick made. In order to make the graph work we need read the M105 return and extract the data from it. While our current methods of parsing this info work its very specific to each firmwares return . Since these string can be differnt between fw versions it can crash so we are working on a way to do this better.

  • Cleaned up the test Client Gui

The test clients GUI needed some love. All the widgets now live within a dock and the docks can be arranged how ever the user likes. I’ve also added a status bar to show the status of AtCore. We’ve also added a print job timer and remaining print time estimate. A Seperate axis control for relative was asked for by a user and I’ve added one that Lays wrote some time ago . It works well and allows for movements on 1, 10 or 25 units

  • Fixed the windows build so that It builds and deploys correctly via craft

Lays has been working hard to get atcore buildable via craft. Now we can build and deploy AtCore (and testgui) from craft. After building we had a problem of not finding the plugins on windows and them not deploying to the correct path.I added some instructions for deploy and tweaked plugin detection on window. Everything is now working well.

AtCore: Printing with threads

When connect to a 3d printer with your compuer you are really just connecting to a serial device.  There are some commads you can send it in the form G# and M# commands . These commands do all kinds of stuff every thing from homing the axises to feeding filment and moving the head around. When you slice your model and generate that gcode file you are making generating basicly a long list of comamnds for the printer to follow. The gcode files are plain text and have to be sent out thru a serial device to the printer. Its not complicated to parse the file you just send a command and wait for the printer to  return a message indicated its finished the comamnd and then send the next command. We have had this working for some time using a QEventLoop and a while to keep the loop going until the printer is ready for a new command. This was working wonderfully Untill we realized that we were having some blocking problems when printing. After some discussion tomaz , patrick and I decided the best way to fix this is for us to split the printing to its own thread so it can no longer block other parts by hyjacking the main event loop while printing.

Since I have been done the print function to begin with I figured that I should be the one to move it to a thread. The first thing that I did was move the print function to a new class based on Q_OBJECT. This is the new object that will be our thread. Moving to a thread ment we had to redo how the firmware plugin lets us know the printer is ready for a command. All the communication between the threads has be to done with signals /slot connections so the firmware plugins now send a signal when the printer is ready for a command. This means that we can now process the temperature returns when the machine is not printing. The rest was not to hard. I moved the logic to its new thread and it had to be rewritten to no longer use the QEventLoop but instead use Signals and Slots between the main thread and the print thread. The main logic for print was broken up in to a few smaller functions. The parts were connected with the various signals and slots and thigs begain to work.

Not everything was perfect the first time. It took time to get this all tested and not crashing. This is my first time multithreading so I was a bit conserned about getting it right. I had some typos that made me loose way to much time looking in the wrong place. Quite a few other crashes and problems that were just a result of me being new to threading. However I was finally able to get everything working in the same way it was before only now each print job will have its own thread.

Progress update for AtCore.

A few days ago we hit a milestone in our development of AtCore. We are now able to properly install the libary for general use. Not only is installing a necessary for a libary that you plan to use within other stuff it also means that we can now focus our attention mostly on Atelier. We have now entered that magical time in development when the real world usage begins to drive its development. Thanks to everyone efforts we are almost ready for the next stage. Patrick has been doing reviews on every pull request. While he has been unable to help with as many commits as he would have liked to. His advice and direction in his reviews has been really helpful and has kept our style and code quality at a high level. Tomaz has been busy fixing up AtCore to be a proper KF5 libary with all the cmake deployment parts to go along with it. Most all of the cmake stuff has been written by Tomaz. Lays has been working on Atelier setup and getting all the non AtCore parts working. Thanks to her effort we are now able to use Atcore from Atelier!

As for me i have been adding stuff to AtCore. Since our last progress update a few new things have been added. Emergency Stop this simply allows you to stop the printer using the emergency stop code.It also cleans up any the command queue. Pause/Resume  when paused we store the current location of the head that that way after resume you can move your print head out of the way to access the model.Pause supports a comma seperated string of commands to be sent after pause. For my printer i use "G91,G0 Z1,G90,G1 X0 Y195" when pause this move my head up 1 mm and then pushes my model out toward the front fo the machine. This is useful if you want to maybe put a nut into printed part or change filament durring print and even to corrrect print defects while printing. We have also started to do lay ground work for more status info being picked out from the serial chatter. Setting of the firmware plugin can be done durring connect to force a specific plugin. A progress bar for printing progress. Some cleanup for autodetection of the plugin. There is still things to add to AtCore but it should provide enough for most use cases already!

I have made a package for Arch Linux on the aur (atcore-git). Other distro packages as well as a proper alpha release tarball will hopefully come in not to long. We are currently working on getting a more defined release plan so that we can get user testing as well as have AtCore deployment ready since its a prerequsite of making Atelier. Currently the package comes with the A test panel “AtCoreTest”. You are encouraged to try it out if you have a 3D printer and report back.Since AtCore will be doing all the communication bug testing here is very important.

Even if you don’t have a printer Installing the package and running the test gui to see that it works and the plugins are shows under the firmware combobox correctly will help us.

For anyone wishing to help with packaging. its simple to get install set up

in the root of the source.

cmake -DCMAKE_INSTALL_PREFIX=$(qtpaths –install-prefix) -DCMAKE_LIBARY_PREFIX=lib CMakeLists.txt


make install

add -DBUILD_TEST_GUI=ON to build the test gui and set up its install

come join us on freenode in #kde-atelier ;



Firmware plugins for AtCore

In AtCore we need to be able to talk to several different firmwares. Each has the possibility of being slightly different, but overall, they should be mostly the same. Some will support commands others don’t, and some will want specific commands with some extra info. This has lead us to decide upon a more modular plugin system in order to allow us to do any firmware specific stuff when we need to. Since my last post, we have added a few firmware plugins currently support the following:
  •     Repetier
  •     Marlin
  •     Teacup
  •     Aprinter
  •     Sprinter
  •     Grbl
They have all been tested on Arduino and the printing seams to work just fine. The Teacup and Marlin firmwares were hacked together while Lays was visiting some printers, so those, while not loading automatically at the time, have also been tested on a fully set up printer. We could just ask the user what firmware they have, but we don’t expect the user to know this all the time.
In order to figure out what firmware we’re on, we have decided to use M115. So far, while some have said its not the best idea, the only reprap type firmwares not to support it seem to be Smoothie, Grbl, Machinekit, and (according to the wiki) Makerbot (Sailfish). When your machine supports M115, you will get some text back about the machine’s capabilities and firmware. For example:
Now, it’s pretty simple to tell from there what firmware name is in the string and load that one… It gets a bit more complicated when the M115 returns:
FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Wait. What happens here? Since when do we have three different firmware names on this printer. Since our firmware check only checks if the firmware name matches a plugin name by using QString::contains() the above example will pretty much try to load any of them since Marlin Sprinter and Grbl are in the string. Whatever one the plugin loader sees first will be loaded. Grbl is not the correct firmware for this printer, and that could be really bad if you’re trying to do some firmware specific stuff. Its looking like we are going to have to trim the string up to extract the firmware name from the string. Again not really a problem. By simply using QString::split(“:”), we can extract just the stuff after Firmware_Name:. After that, a simple QString::resize(QString::indexOf(‘ ‘)) will get us to remove anything after the first space. Now it works well. Then it came time to add support for Sprinter. M115 on Sprinter returns:
At first, that might look okay, but notice after the : there is a space, meaning that in our existing name, extraction will fail. Because we will resize to the first space, our name will be ” “. Okay, not too bad to fix. Just check for and remove any leading space. Then another issue: what if the string has no spaces? Well in that case we might as just have just called clear. But that doesn’t happen right? Oh, wait, here comes aprinter:
😦 . Not only does it break our check of QString::startsWith(“FIRMWARE”) to tell if it’s the firmware id string. It also has no trailing spaces. After all that, our current firmware detection does the following: Check if the message from the printer contains “FIRMWARE_NAME”. If it does, split the string at :. Keep the second one, and if there is a leading space, remove it. Then if there is a space after that, resize the string to there. It’s not too complicated yet, but its starting to get there.
And then there’s Smoothie. I was not intending to do this plugin yet because I don’t have hardware to test on, but I talked with a developer of smoothie in #reprap on Freenode. They were able to provide some interesting information about it. First off, it is not purely reprap-like. That means that it doesn’t follow all the guidelines for reprap firmware. For instance, they do not send start when the printer connects. This is important for us because it lets us know when to send the M115 command to the firmware. They also do not support M115 to get a version string. You must send the version command. Other then those two things, it works like any other reprap firmware. However, in place of start, they send a string of “Smoothie Running @ (speed)”. I suppose we can check for also Smoothie and start, and if we see smoothie, we know we need to load that plugin. This would also require revamping the way we check for firmware, since we now have at least one case where we don’t want to use our current method for checking.
There are a few other firmwares that I have not looked at since i don’t have the hardware to do the tests. This Hardware includes a MakerBot for sailfish, an ImpPro3d to for ImpPro3d, an Arduino Due (reprap fw), a Smoothie board (Smoothie), and a Beaglebone black (Redeem).

Round two of Atcore Testing

It has been about two weeks since I last wrote about AtCore. In that time Tomaz has commited a few changes that allow us to use a plugin system so that AtCore can specialize in speaking your firmware!? Or something like that. Really what It means is that we should be able to keep most all of the common stuff within the AtCore object and use the plugins to give us firmware specific stuff when needed.

Did someone say Test?.

The test is pretty stright foward and that is to evaulate how well AtCore is doing at sending print commands to the printer to do this really we just need to be able to print an object that takes some amout of time.

Late nights printing tiny pyramids

I’ve been awake all night watching this thing print is working as expected. First I had to find a decent model to print and I came across this cool Fractal pyramid

Model by ricktu



Mandatory hardware pictures ?

Two computers.. one to record and play host while the other keeps my sanity durring the nights print.It would be along print the slicer estimates the print to take around 5 hours. Ok time for the mandatory hardware pictures of stuff Check out the computer that will be hosting the printer and recording video for later.In this Set up we will have

chairs eyeview

Two cameras extruder cam and an overview cam. Sadly my 3rd camera didn’t want to play along it was

time for a new floor?

just unable to get a decent focus on the printer LCD so we will have to go without this time.


 Watch the Timelapse video ….7 hours later…..

After 7 hours of printing we have it completed. The Best part i have saved for last when printing



i have used glow in the dark filiament. To quickly charge up the glowing i have placed



the model between the lights of some very bright led lamps. Unfortunately the Camera didn’t do such a great job picking up the detail with the model glowing in the dark



So how did we do?

Well the print was a success! The RAM usage was a bit high for my liking but is most likey due to our text log. We will do further tests to check that. The Firmware Plugin for Repitier seams to be printing stabily for any lenght print I would call that a success!



AtCore test

AtCore itself only has some limited functionality planed and will just handle the communication between Atelier  and the printer. We have most of the basic functionality working and are starting to work on printing. And today we reach a milestone There is enough code working for me to print! Below you can watch the test print. Sorry there is no sound.

Hello World

My name is Chris, and I’m currently working on the new KDE Printer host Atelier. Atelier, as some of you may have heard, is the new incarnation of Br-Print3D. I will just briefly say its been very exciting to work with the other team members, and I look forward to contributing further.

I guess I should tell you all a little about myself. I learned C++ in high school computer science, but that was long ago. Since then, I have never stopped programming toys for myself and others. I have been a Linux user since around when I started in computer science and have used KDE as my main DE for just about the entire time. Around 2003, I switched to purely open source software. You see, I had always dabbled, but I just was not really ready to stop using the other proprietary operating systems. Then, in 2005, I started to become a fairly active member over at the Kubuntu forums. I started mostly doing it as a fun way to expand my knowledge base while helping others.

I started my first open source project, Black Chocobo, and would never look back. It was my first real Qt project, too. Eventually, I had some contributors and was helping other programers who were using Qt to make other tools for the same game. This led to my second project, ff7tk: A toolkit written in Qt designed to make it easier for people to make tools for FF7. It’s been a long process with lots of time spent and skills learned. ff7tk and Black Chocobo ended up being some amazing projects. You might be asking why even mention these projects, as they have little to nothing to do with KDE other than being Qt based. It’s because I started that first project to get better with Qt with the goal of one day being good enough to help improve KDE.