Let's perform another trace like we did earlier, looking through all of the systems and components involved in the stages before printing really begins in earnest. This time, we will explore the control system, looking at both the interface and the control board subsystems. First, let's trace the impact of the interactive interface subsystem. Interface subsystem. As we discussed in the 3D printer hardware anatomy lecture, the process of running a print actually starts earlier with the creation of job file. The instructions machine will then follow. That's the focus of module four, and preparing the machine with the right materials, accessories, and configuration for the job, the focus in module three. To focus our attention on this electronic sub-system, we're considering those elements already carefully and successfully sorted. Also, note that while it is possible to virtually trigger a job via 3D printer host tools such as Cura, or the Ultimaker connect plug-in, 3DPrinterOS, AstroPrint, MatterControl, or Autoprint. For today, we will focus on starting a job the old-fashioned way, by working physically with the machine. Our electronics interface subsystem story begins with approaching the machine. Previous to this job we, used the material panel to load the PLA and we confirm that it was loaded properly. Now we use the control dial to activate the print menu. Within that menu, we select and trigger the job filename for the job we want to print. The interface electronics indicates the Ultimaker two plus machines, that includes the SD card file management subsystem. The interface electronics are now able to spool the G-code file to the main board electronics, initiating the printing sequence. The main board electronics detects from the G-code file that the job is compatible with the machine and the loaded material, and executes the pre-print sequence. It then posts a message to the interface, allowing the operator to know that the printing process has begun. Even within similar machines with a similar Marlin base firmware origin, you may see variations from vendor to vendor, and even model to model, as to precisely how the pre-print instructions are triggered. With most 3D printers, there are specific starter G-code, and in that G-code regions are the job files that list out the G-code at M-code calls for most of the pre-print and post-print instructions explicitly. This is how the Ultimaker three functions for example, triggering a homing sequence, auto platform calibration, and pre-heat process specific for the job and the materials used in the job. More in this, in module four where we will look at a few examples of regions of G-code to see how different approaches meet this challenge. However, sometimes manufacturers will build more of these repeated every time elements into the firmware itself, restricting the job instructions to a more specific path and configuration settings selected by the operator, with the Ultimaker two plus family, for example, the firmware managed a larger number of pre and post-print steps to make it easier to run the same paths at the temperature, flow rate, and retraction settings for whichever material was specified by the operator at that time. The auto G-code flavor job files have been trimmed back to pass with certain breakout variables such as speeds, flow rate, retraction, fan speeds, and temperatures that are tunable on the fly from the interface. But regardless of how this is managed, what the operator sees at this stage are details posted to the interface display that indicate print preparation has begun. This includes information like heated bed and hot end temperatures. For many print jobs, this heads up display style data stream is all that the operator needs from the interface electronic sub-system until later when it posts an update that the print is complete. But should anything happen during the print, the interface subsystem delivers significant value to the machine experience. For example, you might need to stop and address an underlying problem, or you might want to execute an advanced technique like pausing a print to swap materials, or inserting a component into the print job that will be sealed into the finished part when the print resumes. With the active print display on an Ultimaker, it is possible to pause a board or otherwise tune the behaviors of the machine. Common examples of what you might need to do would be raising or lowering the temperatures, or speed to improve success with a tricky feature, changing the speed of the part cooling fans in response to the operator's observation of printing progress. Pausing to dislodge loose strands of filament that might have been deposited where they weren't intended to fall, and pausing a PLA print for a few minutes, or even a few days. Once the print has been completed, the dialogue requests for the operator to confirm that they have retrieved the part and reset the machine. It also serves the function of letting the main board and any networks listing of the machine know that the equipment is ready for the next job. Now, let's switch perspectives from the interface to the control board itself, from outside the machine into deep within the belly of the beast. Electronics control subsystem. Now, back to our story, our robot mascot print systems trace. Picking up the systems trace, we start with the main board receiving notice from the interface subsystem that a job has been selected by the operator, as well as delivering the job instruction file to process. As mentioned in the previous lecture, there are a few ways that that pre-printing stages can be accomplished, depending on the aims of the machine manufacturer. But most significant elements are these, validating the job file, is this file compatible with this machine, materials, and other configuration elements? Power handling electronics, components such as the FETS, et cetera, allow the low voltage MCU driving the control board to divert high amperage, high voltage power to the heaters, a particular importance when raising a printer from cold resting temperature to hot active printing. Triggering the pre-printing process, whether all of the instructions are pre-baked right into the job file, or whether the firmware already hosts the needed instructions within itself isn't as important as that the steps taken happen in right order, and are confirmed as completed before the paths of the print job begin. Triggering homing process: The breakout in stop boards report back to the control board when their sensor button is toggled. Thus letting the main board know that during this homing movement that tool head reached this intended position, triggered the end stop. Validating this mechanical move during the homing sequence then establishes that from that point forward the position for that motor can be known. The control board can then count X number of steps forward or back on that axis indicated by the Java file referencing that known value. Bringing together the path planning established by the slicer with the physical machine. Running auto platform calibration: If needed this needs to happen at a particular time and the nature of the auto calibration technique determines if the bed and tool head need to be hot or cold when it happens. Similar to homing, this stage sets the baseline for where the machine believes the build platform is located. More on this in the Motion Mechanical System lecture. Activate preheating sequence: While it makes sense that you need to get the extruder elements to print ready temperature with material loaded and ready to process at the start of every job, the nature of working with heat and materials that can ooze or resist extrusion that may or may not be subjected to other ambient temperature and humidity content, means that it can be tricky to bring the extruder up to target temperatures quickly and efficiently in all contexts. Especially given all the other elements of the machine that need to draw a lot more power in this first stage than basic material operation. As a result, the stack of instructions to the control electronics during this preheating period can be complex to a counter-intuitive degree, relying on precomputed G-code and delay strategies that come together to ensure that the machine is ready in all of its parts to print right when the print is needed. Purging the tool head: To help eliminate unpredictable ooze and make sure that material flow can be more easily predicted when fabricating the intended object, there is typically a purge stage where a little bit of the material will be processed through, perhaps coordinated with travel movement to get the machine in position for the start of the print job. Getting to the starting blocks: Finally, the start.g-code instructions to get the tool head into its right [inaudible] place ahead of insertion of the instructions that will be followed to print the part. Bring it all together: With most of the processes we have reviewed so far, you'll never really need to intervene nor truly notice. The sequence can pre-break temperature ramps and step offs etc, are the territory of the machine developer, to establish the baseline for the experience with the machine ahead of the stage of printing the part itself, where the operator typically plays a larger role. Let's resume the trace now from the beginning of the paths assigned the slicer for producing the object itself. Finally, now begins the part printing process itself. The job file by convention has a front start.g-code section that sets a lot of the ground rules and an end.g-code section that includes some details about the movements just after the part is printed. But for the most part, the instructions are a long boring items listing of travel loops when the tool head moves without extruding materials and extrude moves when the printer is actually laying down plastic. These instructions are issued line by line by the control board electronics. It sends the permanent signals to each of the separate subsystems within the control board that then act upon them. These instructions typically instruct the tool head to move at this speed, to this location, while advancing or retracting the material this amount and targeting this or that tool head or build plate heat. Thousands of these kinds of instructions. So for thousands and thousands of instructions per printed part, those instructions trigger the X-Y gantry motors to move this medium millimeters and extruder motor to advance or retract this many millimeters, and the tool head and heated build plate to heat or cool towards this target temperature. Not every line addresses each of these elements. In fact with 8-bit systems, most of these lines only address pairs of axis at a time, movement within the X-Y build plane paired with an extruder value and then bumping up. Searching through the instructions, you start to see a few lists you can immediately discern as a pattern. When all of the paths are completed on a flat X-Y build plane. There's listed a Z-axis adjustment to raise a tool had enough to start the next layer. Some layers, like the lowest layers might have unique layer height increments, but most typical prints that don't use variable layer height settings will keep incrementing by the operator-selected layer height resolution all the way up the design. We will talk about G-code in greater detail later. For now, let's focus on one interesting fact. The path instructions for G-code are typically issued in millimeters and in terms of Cartesian values, but the stepper motors themselves don't actually speak in millimeters. They're operated in terms of steps and micro steps rotating clockwise or counterclockwise. This fact is made even more clear when considering that Cartesian G-code job files are also used to drive delta printers. Machines that don't map to an X, Y and Z motor, but instead drive carriages up and down on A, B, and C towers. So what's happening here? Well, there are resources within the control board that are taking these Cartesian instructions referencing the values typically stored in firmware with factors for step per millimeter and issuing those instructions as the right sort of pulse over the H bridge to the corresponding stepper motor. Delta-friendly firmware is able to process A, B, and C tower moves on the fly to eliminate the need for the geometrically longer set of direct instructions that would be required for the job file itself. It's stipulates every single movement on each tower. There are other instructions peppered throughout that turn one set of fans and lights on off and other tool codes that trigger pulse width modulation PWM to set specific values of LED brightness, or color, or fan speed, and the temperature command set in various regions within the instructions might declare a target temperature, but they don't declare the amount of voltage over time used to accomplish this goal. Instead, this number is fed into the PID control loop, which addresses at what interval that's in what power on the fly to approach the target values. The job instructions therefore are a combination of tool commands and values that require the separate subsystems within the electronics to interpret the requested data into terms and voltages that the printer electronics can follow.
