Inside the Ultimaker 3 - Day 1 - GCode

[Daid 306]

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.

Edited November 3, 2016 by Guest

[DidierKlein 729]

Hi @daid thanks for the write up!

One small question, why Griffin?

And is it possible to change the led colors (head or side) with gcode?

I'm sure this topic will interest @neotko for sure

[nallath 1,120]

One small question, why Griffin?

 

Insider joke. We use mythical creatures for work titles for projects. This one kinda stuck.

 

And is it possible to change the led colors (head or side) with gcode?

 

Not sure. But the printer has a REST-full API that allows you to do it. This also resulted in the quire infamous disco.py script that made all the printers at the UM HQ go into party mode (Don't worry, now you can't do it without authentication anymore)

[Daid 306]

We have so many internal project names. I think this one came from a list of fantasy beasts. It's the name that collects a whole range of packages on our linux board into 1.

(It contains "opinicus", "griffin-display", "jedi-marlin" as main components for example. I could go into the overall architecture in a different post)

Case leds can be set with M142 r[0-255] g[0-255] b[0-255] w[0-255] right now. However, this is currently a side-effect of the implementation, and for example the web API will not know the colors have changed. I will try to fix this soon in an update, so I can put it on the official list.

The head leds are controlled by the system and used to indicate status. Due to the same implementation side effect you can try setting them with M143 r[0-255] g[0-255] b[0-255] T[0-1], but this isn't officially supported, and thus might stop working in the future.

[blietz 0]

Thanks for the clarification Daid! Some design decisions had to be made and are reasonable.

 

Not sure. But the printer has a REST-full API that allows you to do it. This also resulted in the quire infamous disco.py script that made all the printers at the UM HQ go into party mode (Don't worry, now you can't do it without authentication anymore)

 

Easter eggs: Red for christmas, Orange for Kingsday, flashing "disco mode" on new years eve etc. etc. etc. ?

Also congratz on the creation of the UM3, long time in the making and now it's finally here with all it's glory

Can't wait to read more of these "inside the Ultimaker 3" posts.

[Labern 774]

Yes I missed you @daid

Thanks for posting this and can't wait for the next topic.

+1 for manipulating Led colors

[neotko 1,417]

 

One small question, why Griffin?

 

Insider joke. We use mythical creatures for work titles for projects. This one kinda stuck.

 

And is it possible to change the led colors (head or side) with gcode?

 

Not sure. But the printer has a REST-full API that allows you to do it. This also resulted in the quire infamous disco.py script that made all the printers at the UM HQ go into party mode (Don't worry, now you can't do it without authentication anymore)

 

Is there anyway to disable the authentification by post/get I tried to play with it without any luck. I would love to be able to use the gcode interface python to test gcodes to test stuff. Also it could be nice. Ofc is just the day after but I would really enjoy a fullcontrol mode pssword or something alike.

Anyhow great job with Cura. I managed to make a semiok S3D profile but without the Cura magic it will never be able to print as good as cura. New cura has clearly made a step forward on dual printing.

[nallath 1,120]

Is there anyway to disable the authentification by post/get

 

Get does not requite auth. Post/Put always require it. There is no way to disable it. Not sure if we ever will (it's kinda a security risk...)

[neotko 1,417]

Indeed I get it. But just as Cura once has auth has power to do anything, it could be nice to have a full console that works on Cura, like a Plugging, to have a cool nice remote full developer access. Anyway is just been 1 day

[neotko 1,417]

@Daid and how can you change the Esteps? I see there's a Gcode to change it, but how you actually 'save' the new data without M500?

Or editing is it ok to just SSH and edit the jedi.json inside griffin/machines line:

"default_steps_per_mm": {"X": 80.0, "Y": 80.0, "Z": 400.0, "E": 369.0},

So.. Can I change the data by gcode? Or to really change the esteps of the feeders I can just edit it?

[Dim3nsioneer 557]

@Daid, good to have you back here! This makes the forum a bit more traditional Ultimaker-like again...

And thank you for the nice write-up!

Edited October 19, 2016 by Guest

[Daid 306]

@Daid and how can you change the Esteps? I see there's a Gcode to change it, but how you actually 'save' the new data without M500?

Or editing is it ok to just SSH and edit the jedi.json inside griffin/machines line:

   "default_steps_per_mm": {"X": 80.0, "Y": 80.0, "Z": 400.0, "E": 369.0},

So.. Can I change the data by gcode? Or to really change the esteps of the feeders I can just edit it?

 

I see steps and thus E steps as machine configuration.

And that's not something I would want to change at runtime with gcode. While the current M92 might end up working, most likely it will be disabled in a future update when we fix some architectural flaws in the code.

The machine definition would be the proper place to change this. After all, you most likely changed the machine?

There is also the property system you can manipulate, but that's something for a later day.

[neotko 1,417]

Cool. Yeah my plan is to start modding it for 1.75mm filament so I can make it work with all my 3 umo+2 (they use um2 1.75 hotends). The first step to do so is by using other feeder.

Thanks @daid !

[tinkergnome 927]

Missed me? I know you did.

Right you are...!  

Good to know, that you have survived this long journey...

I see.. - you're back to get our list of feature requests!

@neotko: so - wishlist for day 2 is the full documentation of the REST-API, right?

Edited October 19, 2016 by Guest

[Daid 306]

@neotko: so - wishlist for day 2 is the full documentation of the REST-API, right?

 

I am going to slightly disappoint you now. I'm 100% sure our documentation is incomplete and a bit outdated.

[neotko 1,417]

Day 2 no hurry! My main concern was the esteps and I want to change led colors by http )

[tinkergnome 927]

I am going to slightly disappoint you now. I'm 100% sure our documentation is incomplete and a bit outdated.

 

Geen problem - alternatively access to the sourcefiles is ook prima!

(I'm sure @neotko has already found them somewhere... )

[neotko 1,417]

What source? I mean the whole machine is working under python scrips. All the main stuff has info added inside and while isn't super easy is quite ok. If you download the firmware directly you can xz/tar it and you have everything except the marlin jedi.hex that's compiled already

[neotko 1,417]

For url of the firmware look at systemupdate python, it has the url for download.

[tinkergnome 927]

What source? I mean the whole machine is working under python scrips. All the main stuff has info added inside and while isn't super easy is quite ok. If you download the firmware directly you can xz/tar it and you have everything except the marlin jedi.hex that's compiled already

 

that's what I'm saying...

...and be careful - don't break it .. again...

[neotko 1,417]

Yeah @tinkergnome I did vi edit the auth stuff and changed the values, basically I was able to brick it XD but that's the beauty of open source, I got a 12€ usb/serial cable for this A20 boards and plugged in to have total access and fix my lame editing skills XD

Also is great that there's the possibility to enter there for servicing and modding the hard way.

[gr5 2,172]

Ultimaker absolutely needs all resellers to have a few micro SD cards to unbrick machines that get corrupted such that the reseller can mail the SD card to the customer who can insert it into the A20 board and reload the operating system (and then of course update it to latest the normal way through Internet).

and arduino github link would be nice.

[ultiarjan 1,223]

@daid

 

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.

First, thanks for sharing this.

About the lift endurance tests, were the 100000 on the same core? and also the core did not show signs of wear?

[tinkergnome 927]

I got a 12€ usb/serial cable for this A20 boards and plugged in to have total access

 

Was it something special or is one of these USB-TTL converters sufficient?

[neotko 1,417]

 

I got a 12€ usb/serial cable for this A20 boards and plugged in to have total access

 

Was it something special or is one of these USB-TTL converters sufficient?

 

Used this https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/

I got it on amazon spain really fast. The board has 3 pins for this cable so you can enter debug mode and you can even interrupt the bootloading etc. Ofc you need to read the basic manual to know where goes each cable colored. Is quite easy.

If remember well is this board https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware