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.