|
As tool changers have become more popular, we need to take a step back and look at our current work flow. We should ask ourselves how we have been nominally handling the boundaries and responsibilities of the firmware driving our 3D printers vs Slicers. Nominally, the boundary was clear. Slicers handed the path generation taking into account of material properties (temperature, requested print speed, retraction distance, retraction speeds, stringing mitigation methods and so forth). Firmware would handle printer kinematics, hardware configurations, max speeds/ accelerations/ jerk, tool locations and etc. With tool changers now growing in popularity, spurred by E3D's tool changer reference design. The boundaries are not so clear any more. Firmwares have not have been developed to provide a clean work flow. Slicers are even more infantile and have a lot of trouble handling the complexities of swapping tools. One of the key to a successful and clean print with multi-color or even multi-material is the proper handling of material properties in the firmware. But wait you say, isn't material properties supposed to be handled by the Slicer? Yes and No! Read on to find out more! As an example, we will be looking at the Duet controller board running ReprapFirmware (RRF), more specifically, we will be looking at the OpenCore, an implementation inspired by the E3D toolchanger running E3D's tool head and plate eco-system. For those unfamiliar with Duet or RRF, check it out at duet3d and duet3d.dozuki.com. For those that are looking to setup your tool changer and harmonize it with your slicer, I assume that's why you are reading this, continue on! A forewarning, any configuration files provided in this guide are to be used at your own risk and are provided on an "AS IS" basis. They are further provided without warranties of any kind, whether expressed or implied! For some basics: setting up RRF configurations, this is written for RRF firmware version 2.02. Future firmware updates will address some of the workarounds this guide provides. In our config.g file, we want to set up the usual kinematics and hardware properties. Set up how our printer connects to our network. Set up our extruder information as well as fan associations. Lastly we will load any config override parameters. Nothing really unusual or unexpected here. The RRF Configuration tool is a great starting point. Next we need to set up our tfreeN.g, where N is the tool number. Here we are going to setup how our tool docks. One of the issues seen in the current release of RRF is the uncertain handling of machine coordinate vs tool coordinate. More information can be found in the beta update and discussions over at the duet forums. Therefore as a temporary work around, we will use the offsetson.g and offsetsoff.g to explicitly.
For our tpreN.g, we are just going to leave this one blank. In tpostN.g, again, we are going to explicitly turn on and turn off tool offsets.
offsetson.g is provided. Please change these as needed to configure to the actual offsets of your tools! offsetsoff.g can be used as is. "Prime All" Macro simply selects each tool, without having to run through the tool pick up and drop off routine (using TN P0, where N is the tool number), and primes each nozzle. Once you have all your tools changing the way you expect it. Now it's time to setup your slicer. Here, I will be using KISSlicer. I am sure there are other slicers capable of doing this; I will be exploring Pathio next! Remember how I had you add G10 and G11 in your tpurge.g file? You might be wondering what all that madness was about. If you are happily printing PLA only, with multiple colors, this probably does not help you as much, but where this method really shines is in multi-material printing. This is where we are in a cross over zone between the slicer and firmware. The idea behind all of this is that whenever we swap our tool, the material tends to droll and ooze a bit out of our nozzle, to get the best prints, whenever we swap into a new tool, we should purge and prime the new tool, perform a retraction and proceed to print. With the proper tuning of each material, this tool change should be no different than a standard retract and jump in a single nozzle print. In the current implementation of RRF, when a line of gcode such as T0 is executed, the firmware actually performs a few actions and these actions CANNOT be interrupted by another line of gcode (exception of e-stop). These actions are the follows 1. De-select the active tool if one is active (runs tfreeN.g) 2. Run tpreN.g of the selected tool, then tpostN.g of the selected tool. No matter if you are running a dock flicker or a brush and purge area, you can benefit from this. In tpostN.g you are most likely executing a routine of tpurge.g or some variant of such. In the tpurge.g routine, you are most likely purging/priming your nozzle. How much you purge/prime should be based on the type of material your print, and makes a significant difference in your total print time, not to mention the amount of material you are wasting. There are two main ways I see this crossover region being handled; I will be discussion the latter. 1. Let your slicer handle your purge routine, this might involve moving to the brush, purging x amount, and retracting then moving back and forth against the brush. You can either hard code the movement or call a slew of .g files located in your /sys folder. Not a fan of this method, especially if you use tools of different length of needs different purge locations. 2. Let your firmware handle material purge length and retraction distance. Much less hard coding IMO! The secret to making this all work lies with G10, G11 and M207.
What we need to do is to pass the M207 settings of our material in our slicer to our firmware. We have already mostly tuned for most of these settings in the past with the only exception of un-retract. We are actually going to use un-retract as a method of passing the purge distance to our firmware. Some materials ooze more than others and require a longer purge. Other materials do not need to be purged as much and print time and filament waste can be significantly reduced by purging less.  Ok enough blabbing, lets take a look at how we can do all of this in our slicer. We need to setup our printer profiles. If this is your first time using KISSlicer, I highly recommend you check out some of the tutorials from Michael Hackney at SublimeLayers as well as the detailed guides from SnoLabs, while you are there, be sure to check out their filament, most of them have already been tuned for optimal printing in KISSlicer. In your printer gcode "Pre fix" tab, I typically set the following. Unit and print mode. Set all the extruder temperatures. Set heated bed temperatures and prime all my nozzles. One trick we can use to avoid heating up all the tools while we use less than 4 tools is to create a "Null" material; discussed later in this post. Notice the "Prime All" is a macro that I have set in my macro folder such that I can use that in my macro drop down list as well.  Next we will set up the "Select New Ext & Warm" tab.' This is where we will set up our M207 parameters we have talked about previously. This is also where the true powers of KISSlicer really shines. KISS allows for the use of "tokens" either some pre-assigned or custom created. The existing reserved ones can be seen on the left hand column. The first variable we will assign to the "S" parameter of M207 is de-string. This will tell the firmware how much of the current material we need to retract. Some materials more than others, but this allows for the flexibility of such. As discussed previously, we are going to leverage the R parameter to do an extra purge/prime for a given material after it has been sitting on the dock. As of now, in KISS 1.6.3, retraction speeds is not a reserved token and can not be easily passed to the F parameter, this can be handled as a separate token, a little messy, but can be parameterized. For now, I have just set a nice middle ground value. Lastly, the T parameter is going to be my purge speed, nothing crazy here. Once those parameters are set, we are ready to call our tool change with a T<EXT>. This will select the proper tool for the next path. During this, our firmware is going to deselect and dock the previously selected tool, select the tool we need, and purge/wipe the exact amount we have just commanded. You will find a few more lines of goodies. We will now command our machine to move to the nextx and nexty (these are the locations of the starting point of our next path), how convenient. Once we move there, we can now pre-prime our nozzle the appropriate amount based on how much we destringed (or is it de-strung?). We can certainly also set that "PRIME" token to the same as our "DESTRING" token, but we might set it to be a little less as material may have had some flow as we moved to our first print location; this gives us another degree of freedom! Lastly, we are going to set the "MATL" token. What KISS does with this is replace the token with the block of code found in the <MATL> section of each Matl G-code. This little bit allows us to run commands such as M220; allowing us to slow down our global print speeds for materials such as TPU.  One more section to set in the Printer Gcode Tab, that would be the "Post Fix" section. Here, we simply cool the bed, deselect any tools and cool all our tools. Lastly, I move my carriage as well as bed to a safe location, be sure to change this unless you are using our OpenCore printer, and turn off all motors.  Phewww, that was a lot of work, we are almost there. Lets check out the materials tab. Set up all your materials as needed. One extra material you can set here is a "Null" material. This allows for any unused/unassigned extruders to not have to warm up. Not really needed, but why cook the unused extruders? Here, set your extruders to have a nominal room temp of 25C and you should be all set. Other parameters should not matter.  Last tab, I promise! "Matl Gcode" this is the tab that gets a little tricky and you want to make sure the settings are consistent and set for all the materials you intended to use. If you miss a variable, unexpected results may occur (you have been warned)! In the <MATL> token box, I set the M220 variable with an S parameter to dictate if this material should be printed at 100% of global speed or less. For TPU, I typically set this at S50 for 50% speed. In the Custom Syntax box, this is where we will set of those previously discussed tokens; "XPURGE" and "PRIME". These variables should be tuned based on materials. Remember this is an extra purge on top of any purge we have already done in the firmware, should not need very much at all, course this can all be balanced to suit your needs. All done, give your models a slice and let me know how everything turns out. Is this a perfect method and union of firmware and slicer? No, far from it, but this is what we have now and what we can work with! If you have any suggestions, or comments, please let me know, in the comments below. I love to hear how this works out for you!
0 Comments
Leave a Reply. |
CategoriesArchives |
||||||||
RSS Feed