Jump to content

Daid

Ambassador
  • Posts

    4,700
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by Daid

  1. Also, if you bed after manual leveling is 0.1mm off, this could make a large print fail. Rather have a failed print or a print that is 0.1mm off in dimensions?
  2. Taking 1 factor away doesn't solve all the others. We are currently looking into improving the last 10-30 micron of the measured distance. Pretty sure no amount of compensation is getting you that kind of resolution. (Note, I'm not an electrical engineer, I could be wrong on some details)
  3. The A20 connects to the ultimarlin board through (I believe) that very same USB interface (I could be wrong). Now if you want to send just a single gcode without sending an entire gcode file you have to use the REST interfact I think. Anyway you are definitely correct that the USB is gone. Now if you want to print something just send it to the printer over the network. If you want to update firmware the printer can update itself. Indeed, the USB is gone (good riddance IMHO). The A20 is connected trough a direct serial interface to the "main" board, (UART1 instead of UART0 on the AVR), this means it gets rid of USB latencies. Only a small amount of commands is still handled by Marlin. For example M109 (heatup and wait) is handled by python code. So the "Brains" of the system know that this is happening. Marlin is only a dumb slave. So directly looking into it might not be the best idea. This solves the "who is in control" problem, which is quite an issue once you start using the USB on the UM2, as you override the display control. If you want to a hackable motion platform, I would recommend the UMO or UM2+. They are much more suitable for that. And there is no plan to end-of-life those.
  4. You'll be surprised how many people inside of Ultimaker are thanking me for these as well ;-) As we where growing quite fast during the development of the Ultimaker 3, not all knowledge is as well documented and shared as you would like.
  5. The decay fix is a fix for an electronics problem. The electrical motor drivers that we are using can be put into different modes of operation. The intention was to have it in a certain mode, which was done by putting a certain pin at 0V. However, this was done with a pull-down which is not strong enough. It causes an inaccuracy every 16 steps. This can be fixed with a simple solder bridge over this resistor.
  6. I know for a fact that PC prints on the UM3 are already looking great. So expect wonderful things there, the higher nozzle temperature really helps. So that part is in the works. I think (but don't know for sure) we will release those profiles before the advanced printing kit. The new head of the UM3 sticks out of the front a bit when the head is all the way at the front, making the door a bit more complex to develop.
  7. Yes, the main config file is located at /usr/share/griffin/griffin/machines/jedi.json
  8. The worst case tilt and thus tilted object is less worse then you would expect. See: https://ultimaker.com/en/community/23463-inside-the-ultimaker-3-day-6-active-leveling
  9. This is day 6 of "Inside the Ultimaker 3", Active leveling. - Other days: Day 1 - GCode Day 2 - Remote access part 1 Day 3 - Remote access part 2 Day 4 - Electronics Day 5 - Developer mode & Linux/Systemd - Today we will talk a bit about out feature called Active leveling. This feature has been called (incorrectly) Auto bed leveling internally for a very long time. So excuse me beforehand if I slip up and call it wrong. Why do we not call it Auto bed leveling? Because it's not. We do not level the bed, the bed stays where it is. We compensate for a tilted bed. Active leveling First off. What is Active leveling, and why do we want it? The initial task of Active leveling is automatic bed height and tilt/skew calibration. In the Ultimaker 2 you have to manually setup the bed start height and manually set it straight. While this process has been made as painless as possible, it is one of the things that is extremely important to get right to get the highest success ratio in prints. So for the Ultimaker 3 we have build Active leveling. This is a special sensor that measures the height of the bed at 3 set locations and then knows how much tilt/skew there is in the bed, as well as on which height to start printing. - Next, we use this feature for a second piece of calibration. We use it to know the height difference between hotend 1 and hotend 2 as well. Manufacturing differences here can be more then a layer height, so the more accurately we know this difference the better print results we will get. Else we are printing hotend 1 on a different height then hotend 2. We provide the option to calibrate this by hand as well. However, this is very hard to get right, and I personally do not trust myself to do this properly. Active leveling - Start height and tilt/skew As I shortly explained, we measure the bed on 3 points. Two points at the front and one point at the back. This gives us with 3 slightly different heights for each location on the bed. With these 3 points we assume the bed is a straight piece of glas and calculate the start height and tilt/skew with these 3 points. Now, how do we use this data? And this is where some people have their concerns. We use this to only move the bed up and down to compensate for the skew/tilt of the bed. We do not rotate the whole object. And we apply this compensation for the first 10mm, then we gradually stop compensating after 20mm of printing height. So, in theory if you print a cube, and look at from the front your object will look like this: Random person: Daid HOW CAN YOU DO THIS TO US?!? Daid: Because I'm evil. No wait. Because we are exaggerating. If I take the worst case skew that I can introduce into an Ultimaker 3, across the X axis is about 5mm. This is over a length of 220mm. So, if we put the picture into the proper scale, it looks like this: So, we can still see for a bit that the bottom is skew. But, let us play a little game. I rotated this cube. Tell me what the skewed side is, without using measuring tools. As you can identify the skewed side on the unrotated picture due to the fact that pixels are also square. Still think our simple skew correction is so bad? And remember, this is a worst-case-scenario. As the beds come manually leveled from the factory. I hope this changes some minds about this correction method. Else, you can still turn it off, use manual leveling. This disables any skew correction. The real question here is, do you want your print to fail, or do you want your print to be slightly (almost impossible to see) skewed. - The two reasons for not applying a full skew/tilt is that it does not help with printing quality to keep moving the bed. Moving the bed also adds noise. And, we could potentually move the print head into the side of the printer then (thus reducing the effective build volume). A bonus reason is that the code is simpler. Which makes it easier to test. Active leveling - Difference between PrintCore 1 nozzle and PrintCore 2 nozzle This is quite simple and obvious. We measure the two nozzles at about the same spot. But not exactly the same spot. This is because residue from one nozzle could prevent the other nozzle from properly detecting the bed height. Especially with materials that have vastly different processing temperatures. We store this difference. Simple, effective, the machine applies this difference when the active hotend is switched. Not much more to say. You don't need to account for this from GCode. It's quite transparent. Active leveling - The measurement Now. Let us get down to the actual measurement. During the development of this feature we had one important requirement. We want to know when the nozzle is at a certain distance of the print bed. Other printers, for example PrintrBot are using industrial capacitive sensors. Example: https://printrbot.com/shop/auto-leveling-probe-2/ These have a sensing distance of 10mm. And thus can be mounted above the hotend and still be used to measure the height of the bed. - There are just a few problems with it. For us, it's large. It's about the size of a PrintCore. So that part we didn't like. It also has a different problem. You need to calibrate them. The actual specs say that the sensing distance is 10mm +-10%. And you also have a mounting difference from machine to machine. And, to add an extra variation, the sensing distance has an EXTRA +-10% depending on temperature. Which isn't a very good thing next to a hotend. - Now, we didn't want to exchange 1 manual calibration step for another. So, we build our own sensor, still based on capacity. Capacity is actually the ability to store electric charge. How do we use this? We measure how much charge we can store between 2 electrical plates. These plates are: The bottom of the print head The alumimum plate of the print bed You can store a tiny electric charge between this. Really tiny, I wouldn't even know how tiny. But we have special chips to measure this. And, the amount of charge we can store depends on the distance between these two metal plates. That is good. However, the charge also depends on... just about anything else, temperature and humidity levels are quite big factors for example. So we are not there yet. As we still do not have a way to detect a set distance between the nozzle and the print head. We just have a measurement that corrosponds to the distance between the bottom of the print head and the bed. Active leveling - Touching the bed So, we touch the print bed with the hotend. We actually slightly push on the print bed with the head. Before we hit with the nozzle on the bed the bed keeps moving towards the print head. When the bed hits the nozzle, the bed deflects a bit and so the distance between the head and the bed no longer changes. So we actually look for this lack in change. Slightly crazy? Yes. Accurate, hell yes. Take a look at this graph: The blue line is the position of the bed, the red line is the reading from our sensor. It does not take much brain power to see where the change point is. The graph before the change point is clearly a 1/X, and after that is close enough to be linear. Calculating the intersection point of that and then the corrosponding bed height value is just math. And math is easy... Active leveling - How to make it fail. While this measurement can be really accurate. However, it has pre-conditions to really work well. Blobs of material on the nozzle. The nozzle is heated during the measurements so small amounts of filament do not effect the measurement. But large amounts will. Vibrations. If the bed is viberating during the measurements, it will add a lot of noise on the sensor reading. If your printer is on your washing machine, better not use active leveling. Fan cover not properly closed. While the design has been improved on this area, you can have problems with active leveling if this fan bracket isn't closed all the way. This because the sensor is attached to this bracket. Hands. The sensor is very sensitive. It which means it is also very good at detecting hands. If you hold your hands in the machine during the leveling you will most likely disrupt the process. Also, touching the top of the print head, specificly the screws, you cause it to fail. So no touching! Active leveling - The future! We have learned a lot more during the development of this feature. Silly things like, glass isn't straight. Your 8mm axis are not 100% straight and add some problems for a perfect first layer as well. Now I know why printing with that first layer of 0.1mm is really difficult to impossible. Closing words I hope this clears up our Active leveling implementation a bit. See you next time. And post your questions! - - Disclaimer: Any information presented here could be wrong. I did my best to proof read everything, but it could confict with the actual behavior of the printer.
  10. 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. Possibly, we don't know. We have to do quite some tests to make sure nothing unexpected happens.
  11. Search is super hard, I rather see the people working on the website working on other things and just outsource the searching to google, who are super good at this.
  12. Nope, that is not supported. You need to change the machine configuration file for that.
  13. I never had success with FreeCAD. But http://solvespace.com/ is free, tiny, and does like 1% of what Solidworks does. But if you are more into the constrained based modeling it might be more of a fit then design-spark-mechanical (my personal favorite)
  14. 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.
  15. Some kind of serial connector, but there are USB ports left (and those are easily extended), so adding a USB camera should work. The camera is connected trough USB, however the connectors are different for size reasons. In the other news, I checked with the specs, and the camera supports up to 1600x1200. However then jpg encoding on the camera no longer works, and the FPS drops to 4 frames per second. And the system load on linux increases a lot.
  16. 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.
  17. No word. We are only starting to plan extra PrintCores right now. (I don't think we even have hardened prototypes right now)
  18. So it goes into the part with fins by proxy ;-) Also, the black casing which holds everything is the most complex injection molded part that we have. I know quite a bit about mechanics these days and production technologies, and this part just keeps me amazed.
  19. 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.
  20. This is day 5 of "Inside the Ultimaker 3", Developer mode & Linux/Systemd - Other days: Day 1 - GCode Day 2 - Remote access part 1 Day 3 - Remote access part 2 Day 4 - Electronics - Today we will take a short look at developer mode. Why? Because I want to make it clear what it does before misconceptions happen. DEVELOPER MODE - ACTIVATED! Developer mode can be activated from the {SYSTEM}->{Maintenance}->{Diagnostics}->{Developer mode}. Activating this will restart your machine. The reason for this is that it makes it easier for the rest of the code. The rest of the code can just assume that whatever the developer mode switch was on startup, that is what it is during the rest of the time the machine is on. - Why did we add a {developer mode} switch, why is it off by default? Well. This is the most important bit. Developer mode makes you machine insecure!. With this mode on, some safety mechanisms are disabled, and remote login is enabled. This means you do not just open the machine for yourself. You potentially also open up the machine for hackers on your local network. So take extreme care with this. If you do not know what you are doing, developer mode is NOT needed. What does it do? First off, and most importantly. It activate the ssh server. This server allows for remote login trough the network. Linux users will be very familiar with this. Note that you can completely mess up your system with this. Which is why I'm not giving too much information on how to use this right now. As you can access, delete, change any file on the printer. Secondly, it changes the main menu so it always shows the IP address on the printer. We are doing so much with so many printers at the office, that a quick look at the IP address is extremely useful. Next up, it when an error/warning happens, next to the normal message that you get, you get the internal developer message as well. This can provide more information, or confuse you even more. Inside the printer - Linux Now, we will get nerdy here. So unless you are a Linux nerd, the rest here will sound like voodoo. To start off with some basics. We are running: A custom image, based on Debian stable (jessie) We are using systemd. Some Linux people love to hate this. We love it. If we don't need it, it is most likely not installed. Most of our own code runs in Python3. So python3 is available on the system. apt-get is available, but if you run apt-get update you will run out of disk space. This is due to the fact that the root partition is not big enough to contain the huge package list from debian. Run mount /dev/mmcblk0p3 /var/lib/apt/ first. You could also resize your root partition. But that is a bit harder. Linux - systemd First off. I love systemd. It makes so many things easier. We are using it for a few main things: Starting up the system Logging Bringing down the system for a system update Linux - systemd - Starting up Our linux system starts up with systemd. Systemd is some fancy piece of software that handles all kinds of startup and stop action, as well as some more things. Systemd does this by the means of services. You can read a lot about this online. So I'll just go into the very basics. Our own services are defined in: /etc/systemd/system And we have a whole bunch of files there that start with "griffin". Most simple example, we have the file: /etc/systemd/system/griffin.nfc.service This file handles the NFC service. The NFC service is the part of the system that talks with the NFC hardware to talk with the (optional) NFC tags in spools. The rest of the system has (almost) no knowledge of NFC. I've seperated concerns like that. If you are on the system, you can just read it with cat, as it's a normal text file. It will show you how this service is started, and what it depends on. As for example, the nfc service depends on the printer service to run before it can do it's thing. The reason for this is, it needs to monitor the printer service, as the printer service knows when a material change is happening. And that's when the NFC service needs to do it's thing. So the NFC service listens to the printer service. - Now, to start/stop a service we can use systemctl start griffin.nfc.service or systemctl stop griffin.nfc.service. But you will most likely cause problems if you stop indivitual services if you have no clue what you are doing. Linux - systemd - Logging All these services become really interresting once you add the logging. Systemd adds logging for us as well. But, as added advantage over the "classic" Linux logging, we can filter in this logging. A really common (almost muscle memory) command that we use a lot is: journalctl -fu griffin.printer This looks at the logging of just the printer service, and "follows" this logging. Which means that the process you just started won't exit and that every new log message that is added will be directly shown on your screen. I quite often have this running during debugging of issues. There are quite a few cool things you can do with journalctl, other examples: #Only show the log from this bootjournalctl -b 0#Show the log from the previous bootjournalctl -b -1#Show the last 1000 log lines from the printer servicejournalctl -n 1000 -u griffin.printer Linux - systemd - System update When we want to do a system update, we have a bit of a problem. As we are running on this system. So we need to update ourselves, while on the move. Once again, systemd really helps us here. We have a special service that we can start, called "update.rootfs.service". This service is intended to run on it's own, without anything else. Systemd as a function for this called "isolate". The isolate function means only that service runs, and it's dependencies. Our update service has no dependencies, so that means everything else is brought down once we isolate that service. - When the update.rootfs.service is isolate, we know the rest of the system is not running, and it is safe to update those files. You can check /usr/lib/systemupdate/initiate_update.sh for details on how this update process works. It uses rsync, which means only the changed files will be copied over on a system update. Meaning that the amount of writes to disk is actually quite limited, and the chance of the system no longer starting up if the power shuts off during an update is really low. Note, this isolating of the update.rootfs.service is done AFTER signature verification. The full update process also checks if the firmware update file is signed by our private key. To prevent man-in-the-middle-attacks on system updates. Closing words I understand if this was really really really technical and nerdy. But, if you are toying with the UM3 system, and getting your hands dirty. This explains a few really basic things. Tomorrow I will go into Active Leveling, as I think that's really interesting subject. - - 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.
  21. 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.
  22. Small correction, the fan connections are in the print head: https://ultimaker.com/en/community/23401-inside-the-ultimaker-3-day-4-electronics
  23. Well, good luck for you then, we have a fix on our master branch ready. Not sure when that will hit the testing firmware version. We first have our high-priority branch to finish and release.
  24. 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.
  25. Be sure to mention the serial number to them, we are currently tracking all production quality issues and want to know how/when they are produced. (Odd that you have one, everyone in the office is telling me shipping happens in November...)
×
×
  • Create New...