Inside the Ultimaker 3 - Day 4 - Electronics

[Daid 306]

This is day 4 of "Inside the Ultimaker 3", Electronics.

 

-

 

 

Other days:

Day 1 - GCode

Day 2 - Remote access part 1

Day 3 - Remote access part 2

 

-

 

 

Another week day, another "Inside the Ultimaker 3". Today we will take a step away from the usualy software side of things and look at something we can touch.

Touch, and shock you (well, only if you lick it. Do not lick the machine while it is ON!). We will be looking at the electronics.

 

-

 

 

Why electronics? Why now? This is because for a lot of things I would like to explain you need to know what is inside the machine and where. And for which function.

 

A history lesson

The Ultimaker 3 evolved from the Ultimaker 2. And Evolution can be a bit messy. But, to fully understand what we have we need to go back to the Ultimaker 2.

So let us look at the electronics of the Ultimaker 2 first, as they are simpler and easier to follow.

This image shows the general components of the Ultimaker 2 (and Ultimaker 2+) electronics. The boxes show different components, and the lines present wires connecting these components.

The UM2 Main board is the center of everything. And drives all logic. This is also where the USB port is located, and where the firmware is installed.

 

-

 

 

The UM2 Main board is the brains of the machine. It controlls the menus, reads the SD card, controls the motors, regulates the heaters. Simple, contained.

 

-

 

 

Most things going to the print head are connected by seperate cables, directly to the main board. Everything from the user-interface is connected to the UltiPanel board, and this board is connected with the ribbon cables to the Main board.

So, we have 2 clear distinct parts. The top part makes it a printer. And the bottom part handles the user interaction.

For details, what every bit is:

 

• UM2 Mainboard: The main electronics. The big white board under the biggest cover in the printer. The brains.
  
• Bed heater: This is the actual alu plate of the printer bed. About 120W of heating power under the glass plate.
  
• Bed PT100: A PT100 is a type of temperature sensor. This one is directly soldered on the printer bed. But it has seperate wires going to it.
  
• Head heater: A 25W (I think) heater in your hotend. Wires come out of this directly, pretty thick wires that are specially insulated to withstand the heat.
  
• Head PT100: Same as with the bed, this is used to measure the temperature. However, this one isn't soldered, it's in a round casing. And also has special wires comming out of it. Directly connected to the main board.
  
• Print cooling fan: Side fans at your printer head. These two small 12V fans connected in series to a 24V switchable output from the main board.
  
• Hotend cooling fan: Tiny fan at the back of your print head. In early UM2 models this fan was always on. In later models this is switched off if the hotend is cold. It's a tiny 5V fan to prevent too much heat from reaching your PTFE coupler.
  
• X/Y/Z endstops: Simple micro switches to detect that the print head and bed has reached a location. Used to create a defined starting location for everything.
  
• X/Y/Z/E motors: 4 strong and nice stepper motors. Controlled by the main board. You may guess what these do.
  
• UltiPanel board: The extra board in the front of the printer that contains the user interface. This board contains no inteligence. And directly connects everything to the ribbon cable.
  
• SD card: The SD card slot at the front of the machine.
  
• OLED display: The pretty 128x64 ON/OFF pixel display. In a greenish/blueish color.
  
• Rotation button: The rotation button, with a rotary encoder that can be pressed. Provides a simple interface without too many confusing options.
  
• LED ring: Just some extra color and feedback to the user. A simple I2C LED driver is used to control this. The board has space for 4 RGB LEDs, but we only use 2, else it is too bright.
  
• Beeper: Basic piezo buzzer. Beeped when you press a button. Fun fact, there is only 1 beep sound in the code. But you can hear 2 different sounds. This change in pitch depends on if the display is updating or not at that point in time
  

 

 

-

 

 

In the end, all this, the architecture is quite simple. The UM2 main board reads gcode, checks the commands, and executes them. Could not be simpler.

 

The Ultimaker 3

As I said before, the Ultimaker 3 is an evolution of this design. Lets just start off with an update picture:

So. That is a whole bunch of extra boxes. Took me a while to get this all proper in a single picture. All the extra boxes also helps in explaining why an UM2 to UM3 upgrade isn't that feasible.

Most parts from the UM2 are still there, in some way or another. But almost every part has a change. So, what changed?

 

• UM3 Mainboard: This is no longer the "main" board. It is still called like that, but is no longer the brains of the operation. It mainly does motion planning and temperature control now.
  
• Head heater: The heater is now contained within the PrintCore. And it does not have the long wires to the main board anymore. Instead it uses pogo-pins in the print head to make the connection.
  
• Head PT100: Same as with the heater, it's contained within the PrintCore. Also pogo-pin connected. Another important difference is that we do the analog to digital conversion in the print head now. This gives a more accurate measurement.
  
• Print cooling fan: The two side fans are different fans now. They are both 5V. And electronicly, we can control them seperately. However, currently, they are controlled as one at the lowest software level.
  
• UltiPanel board: This was upgraded with a small temperature sensor, but the SD card slot is removed. It is also connected to the new A20 LIME2 board. More on that in a bit.
  
• OLED display: It is white now. Other then that exactly the same.
  

 

And, we have new parts, quite a few of them:

 

• A20 LIME2 Linux: This is the new brains of the printer. It's a full Linux system. Which means you have an actual computer in there.
  
• PrintCore EEPROM: Each PrintCore comes with a small EEPROM. In this EEPROM we store the type of PrintCore it is, and we keep track of runtime data.
  
• Print head LEDs: Behind the PrintCores there are 2 RGB LEDs, those are used for status indication and cannot be controlled by the end user.
  
• Active leveling sensor: A special capacitive sensor is in the print head. It is used to measure the position and tilt of the print bed. It is also used to measure the difference in height between the left and right nozzle.
  
• NFC Reader: This reader is located inside the spool holder on the Ultimaker 3. This is used to identify spools of material. Potentially we can write back to the tags inside spools in the future. But right now we are not using that yet.
  
• Front USB: You requested it, here it is. No longer SD, but USB drives.
  
• WIFI: No cables, no problems? There is a small USB WiFi module in there, connected with USB to the A20 LIME2 board.
  
• Ethernet: But, for a most stable and fast network connection, I recommend cable. This is directly provided by the A20 LIME2 board.
  
• Camera: Quite a simple camera with a wide angle lens. It's connected trough USB with the A20 LIME2 board. Current resolution is configured at 800x600, but camera supports up to 1600x1200. However, the framerate is much lower at higher resolutions.
  

 

 

-

 

 

So, we hooked up all of the user interface to the A20 LIME2 Linux board. This is because we wanted this board as the "brains" of the machine. It's much faster and much more feature rich then the Atmel in the UM2 Main board.

This new board also provides all of the network functionality, and USB drive reading.

 

-

 

 

 

Cutting it short

I have to cut it short today (I have less time today then usual). There is work to do. I hope this helps in giving some overview of the new Ultimaker 3, and what has been changed electronic wise.

 

-

 

 

 

-

 

 

Disclaimer: Any information presented here could be wrong. I did my best to proof read everything, but it could conflict with the actual behavior of the printer.

Edited October 28, 2016 by Guest

[forerunnert 0]

Very interesting, thanks for the write-up!

What was the main rationale for the UM3 mainboard/A20 LIME2 combo?

It seems that the A20 LIME2  would have had enough processing power for both UI and motion control?

Edited October 24, 2016 by Guest

[Daid 306]

What was the main rationale for the UM3 mainboard/A20 LIME2 combo?

It seems that the A20 LIME2  would have had enough processing power for both UI and motion control?

 

Realtime stepper motor control on an linux system is tricky. It's much easier to separate this into a different microcontroller. It's also much easier to guarantee safety on the heater aspect.

So that cut down in development costs. We also had this board already, so it just needed some updates for the new hardware.

[RetromanIE 41]

Just curious, what would we see if we plugged something into the HDMI on the A20 LIME2?

Or is the display out removed or disabled in some way? I think I have a A20 LIME2 knocking around from an old project and am pretty sure it was standard HDMI on it.

[ultiarjan 1,223]

Print cooling fan: The two side fans are different fans now. They are both 5V. And electronicly, we can control them seperately.

So cooling could be optimized for the left/right nozzle? I guess someone already tested if this makes any sense?

Something else. Would it be possible to directly connect to the core's pt100 and heater (from an UM2 board without damaging the eprom?

[Labern 774]

I didn't realise it also had a ambient temperature sensor.

Where does it measure this temperature? Inside the print chamber or where the electronics boards are?

[ultiarjan 1,223]

I didn't realise it had "feature X"

[Daid 306]

Just curious, what would we see if we plugged something into the HDMI on the A20 LIME2?

Or is the display out removed or disabled in some way? I think I have a A20 LIME2 knocking around from an old project and am pretty sure it was standard HDMI on it.

 

The port is there. Don't know if the drivers are loaded. We don't have Xorg on the our image. But there is no reason you cannot hook up display and display something on it if you install the proper packages.

[Daid 306]

I didn't realise it also had a ambient temperature sensor.

Where does it measure this temperature? Inside the print chamber or where the electronics boards are?

 

The sensor is in the front of the printer next to the beeper. Between the rotation button and the display.

The sensor isn't logged or used yet, but the drivers are loaded, and it can be read if you poke in the proper location in Linux.

[drayson 75]

Great insight - thanks!

Now, upgradeability discussions are basically stopped I guess :-)

Nevertheless, more Infos about the print core would be great. How is it built, how is the nozzle shape inside, comparison between AA and BB and the UMO /UM2 /Olsonn nozzle designs, dimensions,... and so on...

Maybe next time?? :-)

[chrii 5]

Two tiny questions to the (not)Mainboard, is it still 1/16 microstepping ?

And more important, decay hack activated ?

Chri

[nallath 1,120]

Two tiny questions to the (not)Mainboard, is it still 1/16 microstepping ?

And more important, decay hack activated ?

Chri

 

We didn't change the steppers as far as I recall.

[Daid 306]

Two tiny questions to the (not)Mainboard, is it still 1/16 microstepping ?

And more important, decay hack activated ?

 

1/16 microstepping (now also for the Z, which was still on 1/8 for unknown reasons)

The decay fix (rather call it what it is) isn't applied yet as far as I know. Due to all the stress on other parts we didn't had time to properly test this change. And we're not at the point where we can make changes and not test them properly for regressions.

[Dim3nsioneer 557]

1/16 microstepping (now also for the Z, which was still on 1/8 for unknown reasons)

 

Finally! Hooray!

[robinmdh 100]

Other big changes missed by Daid is maybe the RGBW case LEDs

he did explain how the API to set them isn't working yet :)in one of the previous threads...

We did test with the decay fix, It seems like a straight forward fix but it does impact everything, things like the active leveling for instance.

EDIT: I've been using an ultimaker original since the first one came out and had the luck to be looking for a job at the right time to join in with UM3 development. First post on the new forum btw... (I'm not much of a forum hanger out anyway but I now understand the dislike I heard about)

Edited October 25, 2016 by Guest

[forerunnert 0]

Realtime stepper motor control on an linux system is tricky. It's much easier to separate this into a different microcontroller. It's also much easier to guarantee safety on the heater aspect.

So that cut down in development costs. We also had this board already, so it just needed some updates for the new hardware.

 

I like the concept, rather different than the migration to 32bits boards going on now elsewhere.

Apart from lowering development costs separating motion control from everything else just sounds like a good idea.

It would seem to be a nice evolution for Marlin/Repetier and current ATmega hardware too: motion control only and loose everything else. Add a Pi for the rest, preferably including your JSON interface because that is just everything one could ask for in an interface :-)

All in all great job on the UM3 development guys!

[gr5 2,172]

 

@arjan - I looked at the wiring very carefully in the Core and the 3 electrical components are isolated. so the heater uses 2 wires which don't connect to the other 2 components. Same for the temp sensor. So you can simply decide to not connect to the eeprom and simply never power it up if you mount a core on the UM2.

[Daid 306]

I like the concept, rather different than the migration to 32bits boards going on now elsewhere.

 

I still would like a simple 32bit controller there, but that would cost just the same as the current Atmel. But this simple separation of real-time and application flow is something we had on my previous job and I really really liked that. Makes debugging and developing so much easier for 90% of the things.

Trying to do everything in a 32bit fast feature rich microcontroller, with a realtime-os is a nice engineering challenge. But eventually it will create a lot more problems for yourself.

For example, the largest part of the system does not even known that there is a UI or a REST API. So those parts could easily be exchanged or upgraded without effecting the rest of the system at all.

Linux abstracts most of the hardware for us. New camera? Software doesn't care. New WiFi board? As long as we have drivers we are good to go.

And we've only just begun with improving this architecture path. Our focus was first getting this machine up and running properly, with the the required features.

[ultiarjan 1,223]

@arjan - I looked at the wiring very carefully in the Core and the 3 electrical components are isolated.  so the heater uses 2 wires which don't connect to the other 2 components.  Same for the temp sensor.  So you can simply decide to not connect to the eeprom and simply never power it up if you mount a core on the UM2.

 

Cool!! we must make a UM2 mount.... I really like the core...

[Daid 306]

Small update, I just checked, and the camera we are using is configured for 800x600 video output to get a nice smooth video. However, the camera supports up to 1600x1200 images, but then drops to 4fps due to the hardware JPG encoder no longer working.

[ultiarjan 1,223]

Small update, I just checked, and the camera we are using is configured for 800x600 video output to get a nice smooth video. However, the camera supports up to 1600x1200 images, but then drops to 4fps due to the hardware JPG encoder no longer working.

 

Are you talking about the view function in CURA now? as only there you have the limitation of the JPG encoder?

So it does (or can do) 1600*1200 in the direct video stream in the browser?

Is there any reason not to use the video stream, iso the low fps jpg's in CURA?

[neotko 1,417]

1600, now that's interesting. Also webcam for just seeing it in motion is ok but for timelapses is quite useful!

[Daid 306]

 

Small update, I just checked, and the camera we are using is configured for 800x600 video output to get a nice smooth video. However, the camera supports up to 1600x1200 images, but then drops to 4fps due to the hardware JPG encoder no longer working.

 

Are you talking about the view function in CURA now?  as only there you have the limitation of the JPG encoder?

So it does (or can do) 1600*1200 in the direct video stream in the browser?

Is there any reason not to use the video stream, iso the low fps jpg's in CURA?

 

The low FPS is in Cura. They had some troubles implementing the video stream, and so went for updating snapshots till they have more time. (proper dual material printing was tiny bit more important)

If you directly open the stream you get a very smooth video stream. The (unreleased) iPhone/Android app use this for example.

The JPG encode is in hardware, it is inside the camera. It's one of the reasons we picked this camera. It means that the software just has to read data from the camera and pass it forwards on the network. Which reduces the overall system load.

So it could do 1600x1200 video stream directly in the browser, but only at 4FPS. Right now it's hard-configured at 800x600. So the higher resolutions are potential, not something exposed yet.

Edited October 26, 2016 by Guest

[nallath 1,120]

The low FPS is in Cura. They had some troubles implementing the video stream, and so went for updating snapshots till they have more time. (proper dual material printing was tiny bit more important)

 

Somehow once per two seconds snuck into the requirements, so that it was was implemented. We did have issues with the stream, but that is not the reason we only update at 0.5 Hz. I've tried setting it to 20 Hz with the naive snapshot approach and that worked on my system. I wouldn't recommend doing that with 10 cura instances to the same printer (or on the same computer for that matter).

For 2.3.1 the speed of the camera already has been increased (to a whopping 2Hz )

[rimb05 3]

We did test with the decay fix, It seems like a straight forward fix but it does impact everything, things like the active leveling for instance.

 

Do you mean the extra EMI generated is picked up by the capacitive sensor, or something else?  Mixed decay on the UM2 made such an improvement for Z banding, it would be great to be able to apply the hack on the UM3 as well.