Daid

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

I am a 100% sure that with the launch of the UM2+ we made sure that nowhere, nothing, no communication was done that it would ever support dual extrusion. We even went trough the extra effort of closing the 2nd hole in the print head to make it extra clear. So the suggestion that there would be dual extrusion for the 2+ has not come from us. But I'm sorry that you think it would have come. Illegal? No, not by far. Annoying as hell, yes, I can agree with that. However, seeing it from our side, sales for the 2 will stop as soon as people know that the 3 is around the corner. And we did dodge a few last minute bullets for this launch, we almost had to delay. Which could have mend that we had no revenue stream anymore. It's not a bait&switch. You are getting exactly what you ordered. You could just contact the seller to see if you can still switch your order.

It's a different design. There is TFM in there. But it's enclosed, you cannot see it. It's inside the cooling ribs. It's a really really cool design that makes sure the FTM isn't getting to hot, while it makes sure that PLA is not getting too cold at certain locations so that it locks up. (even during retractions) The rest is just a shell, the heater+PT100 in a heater block, an EEPROM, a locking mechanism and a light guide.

We take a deep breath. Just the software engineer here. But what I think is happening right now, the machines are being shipped from our factory in The Netherlands and the US to our distributors in each country. They ship them to the re-sellers, and the re-sellers will ship them to you. I've seen a sea of machines here in The Netherlands factory. Really mind blowing, it's the only way how I can describe it. Last things I've heard where that everything was going ok, additional parts are still coming in, but all parts are in stock and machines are being build every day. Trust no-one! I've heard "begin november" here in the hallway. But I'm nowhere near a reliable source for anything shipping or assembly related. So that could also mean that they arrive at the distributors at that point in time. Well, if I look at our history, we don't have the best track record in estimating shipping times on product launches. But I'm 1000% sure that we are better equipped to handle the requests then with the UM2.

It looks so simple like this. But the hours and hours that went into developing and testing this thing. Nothing really does it justice.

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.

It might work, but it requires some serious engineering effort, and you will get very sub-optimal results. For example, the location of the switching bay differs from machine to machine, so that needs machine calibration. Don't expect this from us, else you will be disappointed. We learned from the UMO that having too many different machines out there is a nightmare for support (from both a service side as well from a software side)

You don't need SSH acces for that. There is a nice REST API that spits out json files that hold all this data (and allows you to POST/PUT new data). This specific API can even output cvs files. Example: http://{ip}/api/v1/printer/diagnostics/temperature_flow/10000?cvs=1 Returns the last 10000 samples of the temperature graph, as a downloadable CVS file.

Posted more details in another topic. But it comes down to 2 things: a) The UM3 was planned as the UM2.1 like... 3 years ago? We really really wanted this as an upgrade. But it's not feasible due to our most important requirement "only release something if it's up to the task" b) While it looks almost the same from a distance. Almost every component that is worth something has changed. From electronics to printhead. You are free to collect the right parts and build dual in your UM2 yourself. I know that it can work, but it is a lot of tinkering to get working right. Also, be careful with PVA. We didn't engineer a different hotend for that without a reason.

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.

Let me comment on the "But but but, dual extrusion of the UM2 as promised!" Yes, we sort of did. We wanted to. We REALLY REALLY did. The Ultimaker 3 is a direct result of this. We started on UM2 dual extrusion when the UM2 was launched. We only had a small team back then. And we worked on it, and we learned more and more. Then we discovered that it would take more them to make dual extrusion work reliably then we wanted. And thus we took some time of the project to make the 2go and extended. To "win time". Fast forward a bit, and we put more time in dual extrusion. Slowly discovering that it's not feasible for the UM2 in a reliable way. At the same time, we did have this new nice feeder that we wanted to put in this upgrade. So... that became the UM2+. Continuing development, we discovered we needed to lift the nozzle for the best reliable result. Producing 1 printer with the nozzles on the same height is possible. Producing 10000 printers with the nozzles on the same height was not. And that's when we made the choice not to produce it as an upgrade anymore, and the UM2 dual became the UM3. Not because we wanted. Not because of money. But because we didn't want to push out an inferior product. The UM3, started out as the project "UM2.1".

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.

I understand that disappointment but I think that would be a huge upgrade. I have a different mindset though as I've had my 2+ since February and not just for a month. The 3 is an additional $1000 over the 2+ so that is a pretty big difference for the additional features. It's not really in the same pricing category. While not obvious from the first photos, the Ultimaker 3 has different electronics, full color LEDs instead of just white, a new printer head, a new print bed a new spool holder for the NFC (but that could be optional) So you could re-use a single feeder, the motors, the motor covers, the slider blocks, belts and the 8mm axis. Oh, end the end switches. Everything else you would need to change. So an upgrade kit is not really feasible. So many need holes and changes to the external casing that you would need a new one of that as well. Don't worry tough, the UM2+ is still a VERY good machine. Our spare one at the office runs just as much as the spare UM3 at our office.

Small note on compiling custom firmwares, I discovered an issue about a week ago, which caused problems for the menu code as soon as the firmware goes over 128k in size (not the size of the hex file, actual binary flash size) I kinda work around it with this change when you compile with the makefile: https://github.com/Ultimaker/Ultimaker2Marlin/commit/7408e32de2d4348a077c6b274af3635f022e1e6a But if you use the Arduino environment, all bets are off now...

Did you check if the settings where properly imported?

Note that the material settings in the UM2 do act a bit odd. Instead of you having selected a certain material (Current material = PLA), you actually have a "copy" of that material selected. So if you change the PLA settings (or PLA Flex settings) by an import, your selected copy is not changed. So you need to re-select that material for the changes to be active. I think this is more likely to cause this confusion here.

Just bumping in because of that issue report. First off, this warning is specific for the Ultimaker 2+. The exact code where this check is done is here: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/UltiLCD2_menu_print.cpp#L456 The only extra logic that is executed in this case is this: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/UltiLCD2_menu_print.cpp#L689 And this bit that reads the MTYPE tag: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/UltiLCD2_menu_print.cpp#L274 As you can see, there is no logic there that changes the currently selected material in the printer. So as far as I can see, the material selection in the printer is used.

Well, some people did sort of win a price like that already. Not from a competition, but from just being excellent members of the Ultimaker community.

I still live ;-)

We did test, quite a bit. But... well, all our originals where upgraded to + or heated bed upgrade status. So that was missed. There is a workaround, you can enable the heated bed setting and set that to 0, that will work around this problem till we have a fix out.

The nozzle size is one of the machine parameters, but you can enable more settings to see so you can configure actual line widths, which is most likely what you want to influence when you where messing with the nozzle size on the old Cura. The tripple state of the combing was lost somewhere, as it was contributed on the "legacy" Cura during new Cura development. Best to file an issue about it here: https://github.com/Ultimaker/CuraEngine/issues

On the new Cura you want to create a json file for your custom printer. See: C:\Program Files (x86)\Cura_15.06.00\resources\settings For examples. Most likely you want to base yours of the UltimakerOriginal file.

Every single setting can be used as {tag}, so just save a profile as an ini file, look at all the names in there, that's everything you can use (and there are a few extras, but there are in the default start code already)

I'm still alive. Mostly. Good news. I still have a job. My post was totally inappropriate and wrong on quite a few levels. And I could totally see how most companies would take no effort to fire anyone over something like that. I'm grateful towards Ultimaker that they didn't. I should have handled it completely differently. And got only myself to blame for it. So my voice has been heard a bit, but the message was almost lost due to my stupid way of trying to get it across. Luckily, things are in motion now. Thanks for all the people that showed their support for me. But know that my action was wrong at some core level. In public is not always the proper place, even if you are Open Source. If anyone feels the need to talk to me more, you can do so in private, you guys have my email address.

Yes. I was expecting this problem when I made my posts, so I always copied them to a text file beforehand. I'm more concerned with the attitude of some people in Ultimaker. That's what I'm trying to highlight to the proper people now that I have their attention. @TheGuyKnownAsAndersOlsson: Thanks. Things like that will help in making my case at Ultimaker. I actually heard yesterday that my actions (not the crappy excuse for a forum) is hurting the community according to some people. I would have loved to make a poll about that. But... well, also not possible. Anyhow, I can collect a whole bunch of quotes from this topic alone to show otherwise. @foehnsturm R&D is working very hard on something pretty awesome. The Go and Extended where just to buy some time. Because it proved to be more complex then initially guessed. We also lost time due to all the new people, we've grown quite a bit in R&D after the launch of the UM2. But getting knowledge to spread takes time.