There are way to many changes to put here in one post for these two projects since my last update. I will very quickly just go over some changes. With AtCore we now detect plugins better. Provide a more flexible deployment configuration and and have a Homebrew script for Mac in the KDE-mac tap. (log) AtCore is getting ready for a new release v2.0 this will be required to build Atelier. This will be the topic of my next post. Where plan to cover the journey and changes from AtCore 1.0 to AtCore 2.0.
Atelier has gotten the lions share of the work since the last update at least a diff a day! These include using all AtCoreWidgets for the common items shared with the test gui. Supporting drag and drop to open files. Having the 3d View tracking on the gcode files open the in editor so you can preview the open file. Improvements to the gcode editor. Quite a few more that I am not remembering all while cutting down on the code where possible and making parts leaner. (log)
It has been over a month since my last progress update. Here is what I’ve done.
D10813,D10845,D11185,D11252,D11702,D11565,D11381, D11403, D11345, D11024,D10299,D11772
AtCore will now deploy libAtCoreWidgets. Sd card support is working for repetier and marlin. I can not assure you it will work for any other firmware correctly. Command injection is now done (D11024).
Atelier Update :
General UI Improvements.
- Remove “Profiles” and “New Instance” from toolbar by default.
- Show Profile dialog upon connection attempt with no profiles created.
- Embed fallback icons with awareness of Light / Dark Theme
- Instance now get filelist on creation
- Show the print actions only if a file has been opened or printing from sd.
- Use AtCoreWidgets.
- Clean up toolbars for atcoreInstance.
- New Instance Button on tabWidget.
- Close Tabs, if more then one tab open.
- Rename Test Gui to atcore-gui
- More build switches for gui/documents and test
- Cleaner disconnects from printers
- Cleaner deployment of devel files
- Added an extruder control to the axis control
- Better checks for CONNECTING state.
- More Readable and easier to expand GCodeCommands.
Things being worked on.
A few users have asked for Sd card support and hopefully the basic version of that will be merged soon. This feature appears to be a more firmware dependent so it may take some time before each of our target firmwares has full support for SD Cards. The other feature that is being worked on is command injection. I have been thinking about adding this for a long time and I finally have a decent set of changes to support this feature in atcore. I can hear some of you out there asking about what exactly I mean by command injection is so I’ll explain. This feature will allow you to place specific commands for atcore into the gcode file. There is no need to worry about the commands breaking your gcode file since they are added in a way that makes them invisible to other hosts. You can trigger temperature changes, speed changes, pauses and more in this way. Using a few injected codes I was able to modify my test code that I print into a print that was made of abs with a tpu core. I didn’t have to touch atcore’s gui other then to resume after the auto initiated pause(s) and I can make prints with multiple colors and materials.
The Raspberry Pi3 is a small single board computer that costs around $35 (USD). It comes with a network port, wifi , bt , 4 usb ports , gpio pins , camera port , a display out, hdmi, a TRRS for analog A/V out. 1GB of ran and 4 ~1GHz armv8 cores Inside small SOC. Its storage is a microSd card they are a low cost and low power device. The Touchscreen kit is an 800×480 display that hooks to the Gpio for touch and dsi port for video. To hold our hardware is the standard touch screen enclosure that often comes with the screen if you buy it in a kit.
Most of the time it is sufficient to run Raspian the official distro that is made for the raspberry pi. raspian is a fork of debian as much like debian it has some old packages. In order to build AtCore (with the gui) you need at least qt5.8 raspian comes with 5.7. This is not a show stopper but compiling qt does take quite some time and can easily take a week if we were to build it on the rpi itself. Setting up a cross complier will save you a lot of time but even on my fastest machine it will still take some hours to build qt for the pi. I decided it would instead be faster to install a completely unsupported OS on the device. I was going to install install arch linux on the rpi. Arch is a rolling distro that ships with qt 5.10.
Arch linux on the raspberry pi is what you might call “doubly unsupported” That is that the raspberry pi foundation does not support running arch on the pi. You only get support from the arch community. Arch Linux is not officially supported on platforms other then x86_64 the rpi running on arm. Worry not for the Arch community has some forks such as archlinux-arm this is what we will be installing. Like most things arch you get some instructions. After getting the os installed its still arch so you only get a cli interface on your first boot and are left to set up the rest of the system.
For my system I installed plasma-meta , xf86-video-fbturbo-git and sddm. With those I was able to have a working plasma shell. I also installed dolphin, kate and konsole as well as the few atcore dependencies. I then added my user to the uucp group so I was able to r/w to serial devices and restarted. When all the dependencies are installed you can proceed to build atcore. Since this is arch we can simplify the building part just by using atcore-git from the aur. Im Happy to say it took only minutes and 48 seconds to build atcore-git on the rpi. I then used pacman to install the atcore-git package and it was time to see how our gui was looking on such a small screen.
At first the contents of the atcore-gui spill off the screen due to the way our docks are tabbed, however since they are docks you can just adjust them to make a quick usable interface. After adjusting the gui AtCore worked exactly the same as it does on other systems. Below you can see a picture and video.
Can do better
There is lots of room for improvement. Atcore-gui does not save any settings. You’ll need to move the docks around each time you launch the program. Atcore-gui can not automatically connect to a device on launch. Again for reasons of not saving settings This gui is of course not really made for use on a touch screen and it does seam to work good enough to use. Some non atcore changes on the system itself would be nice. A few services running on the pi would improve this over all. Mjpeg streamer or another method of streaming video from the attached camera on my printers extruder. Uploads are done via stfp that’s not always easy for everyone. The pi does not launch atcore-gui on start up . Small stuff like this could easily be adjusted. I was really just playing around to see how atcore ran on the rpi. I was very happy when this worked well.
Today I would like to announce the release of AtCore 1.0.0. This is the first stable release for AtCore. Since its the first release and we have not written a “real” client for it yet we include our test GUI. If you own a 3D Printer you are encouraged to try AtCore for at least one print job.
Using AtCore Test GUI
Using the AtCore test gui is really easy for Linux you only need to make the AppImage executable then run it, On OsX you run the .app file and for Windows run AtCoreTest.exe. To do anything in the application you must first connect to a printer. Use the connection tab in the top area left area of the window. Select your Device and Baud then click connect. If for some reason your firmware is not able to be autodetected or you wish to speed the connection up you can select your firmware from the drop down list. If you don’t know what firmware you have try using repetier. You can find more information on the Test Gui if you view its User Guide. If you are intrested in hacking on/with AtCore you may want to check the Api Docsumentation.
- The test gui’s log will show an extra set of I/O for each connect/ disconnect you have done while its running (fixed)
- If your printer does not restart upon connection with AtCore then AtCore will not send the firmware request correctly. If this affects you just select your firmware plugin from the list, or send the command M115 from the command tab.
Be sure to Report Bugs that you might find.
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.
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.
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
add -DBUILD_TEST_GUI=ON to build the test gui and set up its install
come join us on freenode in #kde-atelier ;