Missed me? I know you did.   -     As the Ultimaker 3 is now known and will be shipping out towards people and, (don't quote me on this one) hopefully be in the hands of users by FridayNovember. So, I figured I will explain in depth technical details to prevent surprises and improve knowledge for you. I will assume that you are already experienced with certain things from the Ultimaker 2 or Ultimaker Original. I  hope this knowledge will help in understand why things work the way they do, and how to get the most out of your new shiny machine.   -     Other days: Day 2 - Remote access part 1 Day 3 - Remote access part 2 Day 4 - Electronics Day 5 - developer mode linux Day 6 - active leveling   GCode If you are reading this, and you don't know what GCode is, you should read up on that somewhere else first.   -     So. The Ultimaker 3 accepts GCode. Again. Just like the Ultimaker Original, Ultimaker 2, and almost every other printer. However, after much consideration, we decided to break backwards compatibility. So it is no longer possible to run Ultimaker Original or Ultimaker 2 GCode on the Ultimaker 3. We had good reasons for this, during testing we discovered it was quite easy to run the wrong GCode file and thus get bad/unexpected results, which resulted in wasted time and filament. This is also a lesson learned from the introduction of the Ultimaker 2 go and Ultimaker 2 extended. Where running files for a larger machine on a smaller machine could go very wrong. (Checks have been build in the firmware now, but for running extended files on a normal 2 this still triggers very late)   The header! So, introducing: The header. The Ultimaker 2 already had a tiny header, containing a few lines. The Ultimaker 3 uses a new header format. This header contains a lot more information, and allows the printer to make a better decision on if the print job is suitable for this printer. It also allows us to upgrade/improve this header in the future.   -     This does mean, that if you use a different slicer then Cura 2, you need to put in this header. Slightly unfortunate. But that's why I kick this "insider" posts off with explaining this detail. However, not to worry, we did think this one trough.   -     But enough talking, let me show you a header:   ;START_OF_HEADER;HEADER_VERSION:0.1;FLAVOR:Griffin;GENERATOR.NAME:Cura_SteamEngine;GENERATOR.VERSION:2.1.99-internal.20160623;GENERATOR.BUILD_DATE:2016-06-23;TARGET_MACHINE.NAME:FDM Printer Base Description;EXTRUDER_TRAIN.0.INITIAL_TEMPERATURE:210;EXTRUDER_TRAIN.0.MATERIAL.VOLUME_USED:2060;EXTRUDER_TRAIN.0.MATERIAL.GUID:506c9f0d-e3aa-4bd4-b2d2-23e2425b1aa9;EXTRUDER_TRAIN.0.NOZZLE.DIAMETER:0.4;BUILD_PLATE.INITIAL_TEMPERATURE:70;PRINT.TIME:474;PRINT.SIZE.MIN.X:0;PRINT.SIZE.MIN.Y:0;PRINT.SIZE.MIN.Z:0;PRINT.SIZE.MAX.X:215;PRINT.SIZE.MAX.Y:215;PRINT.SIZE.MAX.Z:200;END_OF_HEADER   That's a whole lot of information. Some information isn't used by the machine, but can still be useful for diagnostic goals. But let me go over each one in a few sentences.   -     START_OF_HEADER, END_OF_HEADER, these need to be included. Only the lines in between here are seen as the header, if these are missing, then the Ultimaker 3 will flat-out refuse the file. HEADER_VERSION Once again, this needs to be 0.1 for now. When we make incompattible changes we will increase this number. We are software engineers, so we start at 0. (yes, we had a 0.0) FLAVOR And another one of these. This indicates the flavor of GCode we generated. Griffin is the name for our Ultimaker 3 internal software stack. So this flavor name matches this. It indicates which GCodes are used for what. Which I will go on into detail later. Right now, this needs to be Griffin. (captital G) GENERATOR.NAME This field is required to be present. BUT you can fill in whatever you want. It is to indicate which backend tool was used to generate the GCode. In this case, it's the CuraEngine, still called Cura_SteamEngine as a wink to the past. GENERATOR.VERSION Also required to be present, but same as the generator name, this can be anything you want. It's an indication of which version of a slicer that was used. Useful for diagnostic goals. GENERATOR.BUILD_DATE Pretty much the same as the version, but needs to be a valid date in yyyy-mm-dd format. TARGET_MACHINE.NAME Optional field, filled by Cura in this case to indicate which machine was selected. But you can leave it out. EXTRUDER_TRAIN.{X}.INITIAL_TEMPERATURE Used to indicate to which temperature a hotend should be heated before the GCode file is started. Note, leave out all the EXTRUDER_TRAIN fields if you are not planning to use that extruder. This example is a single extrusion file, and thus does not has lines for the 2nd hotend. EXTRUDER_TRAIN.{X}.MATERIAL.VOLUME_USED When the initial temperature is set, this field is required. You are allowed to set this at 0 if your slicer cannot fill it in. Right now, it is only used to display towards the user how much filament is going to be used (same as the Ultimaker 2). EXTRUDER_TRAIN.{X}.MATERIAL.GUID This field is OPTIONAL. Good thing it is, as it indicates which exact material this file is intended for. As we are using unique codes that can indicate brand material type and color it's easier to leave this field out if you are not using Cura. The Ultimaker 3 will then not check if the material in the machine matches the one for the GCode. EXTRUDER_TRAIN.{X}.NOZZLE.DIAMETER A required field. While we only ship with 0.4 nozzles in our PrintCores right now. We did account for having future versions with difference nozzles sizes. A mismatch in nozzle size and slicing is bad, I don't think I have to explain that. BUILD_PLATE.INITIAL_TEMPERATURE Another required field. This one is important. Because heating up the bed takes a long time. Which is why we want to start heating it up as soon as possible. So we can level, and do whatever we need to do in the meantime. The file won't start till this temperature is reached. If you put this at 0, it will wait till the bed is cooled down before the print. PRINT.TIME Used for time estimates, same as the Ultimaker 2. This is a required field. But once again, put it at 0 if you cannot fill it. PRINT.SIZE.MIN/MAX.X/Y/Z Required fields. Used to indicate how large the print is. As you can see in the example, we just put the size of the printing volume in there. You can do the same. This does mean that a file prepared for an extended, even if it's not tall, will not be accepted on a normal 3.   -     So. So far the header. Most likely there will be questions.   The GCodes While the Ultimaker 2 supported a very wide range of GCode commands due to being Marlin based. We did strip out a whole lot of unused commands in the Ultimaker 3. So to make it extra clear, these are the commands you are used to and are still supported:   G0, G1, G4, M104, M109, M140, M190, M106, M107, M201, M204, M205, M302, M400, M117   While not obvious at first, the most obvious missing code here is G28. Yes, you are not allowed to home the head or the bed anymore. As this screws with the leveling correction code. The printer is homed before and after the print, so there is no real need to have this in a gcode file. So G28 does nothing.   -     Other absent codes are the M82/M83, relative E mode. I don't know if there is a slicer that depends on this. Due to some archtectual things in the code, these commands are difficult to support right now. (Note, I think they do something, but they might stop working in the future, or we will fix the bugs related to them)   -     I did not list T0/T1 yet. They are however, fully supported, they are more supported then supported. They are very important. As they switch between the different hotends. This means these codes activate the lifting mechanism. So if you want to abuse the lifting mechanism (and we have done this) you just need a long series of T0 T1 lines. It is important that the machine handles this. Not only improves it compatibility with other possible machines, but the "bay" in which the switching happens isn't 100% in the same location for all machines and thus is at a calibrated position, which only the machine knows. Fun fact, we've ran this lifting mechanism test for days and days in a row on multiple printers. I think we have machines with well over 100000 lifts and not showing a single sign of wear. This did take a few design iterations, as the first lifting mechanism prototypes wore out in 10000 lifts. I don't know our full testing numbers right now. But we abused the hell out of this thing.   -     New code:   G280   There is a new GCode command we added. It primes the nozzle with whatever priming strategy the printer has. As we are tracking the position of the filament in the nozzle, the printer has better information on how to properly prime the nozzle. You are not required to use this, but Cura does.   -     Other codes might still work, but are not officially supported, and we could break/remove them in the future. However, let us know what you miss so we can make sure we are not breaking anything.   Compression .gcode and .g are the traditional file names for a gcode file. We are still supporting and using those. We are also introducing a "new" format. And it is everything except hip and fasionable.   -     It is.... .gcode.gz. The real nerds I have to explain nothing now. The rest of you, this is just a gcode file, but then compressed, a sort like a zip file, but then even simpler. This does mean a massive file size reduction. It uses "gzip" file compression, which is easy to do on Linux, and for example 7zip can do this on Windows. The cool part for us, as software, is that we can read a .gcode.gz file in exactly the same way as a .gcode file. We don't need to unpack the whole file, we can unpack it as we read it. So we don't need to store a 2GB unpacked gcode file when we are printing. End result is that we can fit more files on a USB stick, and we require less time to send a file to the printer trough a network connection.   Wrapping it up This is day 1. What will I tell tomorrow? We shall see. Feel free to put in suggestions, but I have more then enough topics.   -       -     Disclaimer: Any information presented here could be wrong. I did my best to proof read everything, but it could conflict with official statements and the actual behavior of the printer.