Jump to content

Search the Community

Showing results for tags 'UM3'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


3D printing forums

  • General
    • Official news
    • Buying or selling your Ultimaker
    • Ultimaker.com feedback
  • Ultimaker products
    • Ultimaker 3D printers
    • Ultimaker Software
    • Materials
    • Modifications, third party add-ons & other hardware
  • 3D print Questions
    • Help, Tips & Tricks
    • 3D modeling software
  • Fields of Work
    • Architecture
    • Engineering
    • Manufacturing
    • Education
  • User Lounge
    • What have you made
    • Coffee corner
    • Events and meetings
  • Languages
    • Nederlands
    • Deutsch
    • Español
    • Français
    • Italiano
    • Japanese - 日本語
    • Other Languages
  • Clubs used for testing's Clubs explained

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Field of Work


Country


3D printer


On The Web

Found 658 results

  1. I've been happily printing with my UM3 for quite a while. One quirk of Cura seems to be that if the printer is not on when I start Cura, Cura will never see that it is online. I have to close Cura and restart it for the UM3 to show as online. That has been a constant until today. Today, no matter how many times I restarted Cura, it would not acknowledge that the printer was online. This started with Cura 4.1. I then installed Cura 4.2.1 to find the same behavior. I pinged the printer and it responded as expected. Following the Network Troubleshooter, I removed the printer. I then tried to re-add it and it was not discovered on the network. I was able to manually add it by IP address. The initial problem of not seeing the printer was happening before I rebooted to complete installation of Windows Update: https://support.microsoft.com/en-us/help/4512508/windows-10-update-kb4512508. It is possible that the update had left the computer in a wonky state until the reboot. I'm in a working state now, so this is more of a heads-up to the developers...and also a query if anyone else has had the first issue of only seeing the printer if Cura is started while the printer is on (I.e. start Cura with printer off, then turn printer on, Cura will not recognize this fact.)O
  2. Hello Community, I have an ultimaker 3d mega since 3 months, printed a lot of technical parts and was quite happy with the printer. My problem seems to be a common one but I have tried all solutions I could find, and they didn't help: After about 10 minutes of printing, the filament is blocked within the hotend. For some minute fewer and fewer filament leaves the nozzle until nothing comes out. When I pull the filament out of the hotend, the distal 3 or 4 centimeters seem to be a little bit thicker than the normal filament. Twice I was not able to pull the filament out because it had become to thick and I had to cut the tube. The problem started sunday at a sudden with the same filament and setting I had used for a week successfully until nearly finishing the filament. I found out that this is a common problem connected with cooling or a bad fit between the teflon tube and the nozzle. I changed filament and used two types of PLA and one of PET-G. I changed temperature and number of layers various times. I switched retraction off and on again. I changed 3 hotends (the old one and two new ones, one that came with the printer and one i bought) I changed the nozzle various times. I changed the cooler because it seemed a little week but with the new ventilator the problem remained unchanged. I updated cura and tried to print directly from the printer via SD-card. I lost a lot of time and now I ran out of ideas. Does anyone have an idea what I could do/try? Yours Dirk
  3. here's the situation: Z Distance between the nozzle in Core 1 and Core 2 seemed not remembered by the firmware, or it is ignored during print, or something went wrong during calibration. Core 1 will always be well calibrated and printing well, however, Core 2 will always got pressed too close to the bed that blocks the filaments from coming out. After Active leveling, Core 2 nozzle always pressed too close the bed during print, as if it is ignoring the result done during calibration.. after running more of tests, it seems that Manual Leveling does not have this issue. I have done a lot of tests, switching print cores(i have purchased one extra print core), and the result is the same. So i guess it is not the problem of the print cores but something is wrong with the machine doing Z calibration. And it seemd to me the machine is ignoring the Z calibration that is done in active leveling, so every time when print started, it went all the way pressing nozzle too close to bed again. Not sure if this is a firmware issue but i would like to post here to see if it shines any clues. Some other users also have this similar problem and is forced to print on one nozzle (Core 1), unless one kept doing manual leveling and forces the machine to never do auto leveling thus not to override manual leveling setting. And this seemed to happen fairly recently, so i guess it could be something about the latest firmware update.
  4. Hi, I am exploring the developer mode of UM3. I am able to log into the printer via SSH and run the command_util.ph. It succesfully execute 'help' command. But when I try to run gcode, it produces following error and exits the cmd shell. Need help to resolve it please. (Cmd) sendgcode G0 F15000 X99.757 Y110.646 Traceback (most recent call last): File "command_util.py", line 140, in <module> GriffinCmd().cmdloop() File "/usr/lib/python3.4/cmd.py", line 138, in cmdloop stop = self.onecmd(line) File "/usr/lib/python3.4/cmd.py", line 217, in onecmd return func(arg) File "command_util.py", line 118, in do_sendgcode print(dbusif.RemoteObject("printer").debugSendGCode(args, timeout=120)) File "/usr/share/griffin/griffin/dbusif.py", line 214, in __call__ return self.__obj_method(*args, **kwargs) File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in __call__ **keywords) File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 4 matched rules; type="method_call", sender=":1.34" (uid=0 pid=2141 comm="python3 command_util.py ") interface="(unset)" member="debugSendGCode" error name="(unset)" requested_reply="0" destination=":1.18" (uid=1000 pid=987 comm="/usr/bin/python3 /usr/share/griffin/main.py griffi") root@ultimakersystem-ccbdd3008b14:/usr/share/griffin#
  5. I recently got myself a second hand (thirs hand maybe?) UM3, and after cleaning it up and doing all the calibrating, one thing still bothers me... The frame lights are completely different colours! The left is a very blue white, probably around 5500K and the right is a white so warm its basically a banana - Around 2300K if my well trained eye isn't mistaken. See attached picture, it's taken in overcast sunlight so pretty neutral. I can post more pictured once it's dark and the light is more visible. Is this a result of something up with the firmware or some random customisation, or are the strips just really weird? I know you can supposedly program these in full RGB, so if I can find a fix through that, I'd be more than happy to give it a go, too! Either way, this really hurts my soul at the moment.
  6. Hello all, I am trying to send a file to UM3 using cluster-api/print_jobs cluster-api/v1/print_jobs/ In this API, there is an optional input field called x-Fields. I assume i can use it in order to send info about the printing job file, like limitations for material or extruder type, temperature range and others.. is this correct? how can i use it? in case that x-Fields is not the right way, is there some other way to do it? in general i see that x-Fields is optional for other APIs as well, where do i get more detailed documentation about using x-Fileds in these various APIs? it seems that gcode slicing files that were saved from cura, can include such info on them. but i need to find a way to control other files as well (not created from Cura), so i need some way to pass those options to the printer
  7. Used Ultimaker 3 in excellent working condition available for sale in London. Comes with two spools of filament - One Ultimaker filament 2.85 mm White PLA and One Verbatim filament 2.85 mm Black PLA. Asking price is 2600 GBP, but open to negotiation. Not available for shipment. Only local pickup. Payment can be made through bank transfer or through cash on pickup.
  8. This is day 3 of "Inside the Ultimaker 3", Remote access part 2 - Other days: Day 1 - GCode Day 2 - Remote access part 1 - Welcome back. Yesterday we look at accessing data from the printer. Today we will look at changing data in the printer from remote access. - This is a whole lot more technical and complex then just accessing data. The reason for this is security and mistakes. First off, you might not want everyone on your network to start/abort/pause prints. And you might, by mistake, control a different printer then you wanted. Think excidental use is uncommon? It happened at our office during development. And think how often you send something to a 2D printer to find it at a different printer then you expected. Security! First off, we had quite a few discussions about this at the office. As you need to have the proper trade-off between security and ease-of-use. Also, security is not an easy subject. Things that might look secure don't have to be. Things that are secure might be a pain to use. - So, we made the following decisions: Reading of data is always possible. To make monitoring of printers easy, and while you can access camera feeds and print head positions. It's not possible to get the exact gcode file out of the printer. Thus the model is still quite secure. Any "change" in the printer requires authentication. A change can be starting a print, aborting a print, or even changing the LED colors. Authentication is done by a pairing mechanism. So your printer and Cura, a phone app, or any application you want need to "pair up". Most of this is invisible to the user. Physical access is access. So if you can touch the printer you should also be able to pair up. Multiple applications/devices can be paired with the printer at the same time. The end result of this means that if you have an Ultimaker 3. And you connect with Cura for the first time, you need to say on the printer "I allow this Cura to use this printer". - On the technical side, this means any REST request to the printer that is not a HTTP GET request requires this pairing to be done correctly. Pairing, under the hood. The pairing process is actually a multi step process. These steps are: The application request a new ID/KEY combination from the printer. It does this with the name of the application and the name of the user that wants to access the printer. The printer returns this new ID/KEY combination to the application. The printer shows the dialog with DENY/ALLOW Until the user has selected ALLOW on the printer, this ID/KEY combination is not valid. The application keeps checking if the user selected allow or deny on the printer. Once ALLOW is selected, the ID/KEY combination can be used as username/password combination for HTTP Digest. HTTP Digest... The nice things about standards is, that you have so many to choose from. For security we looked for something that was quite easy to implement, but offered the security we needed. While we did look at HTTPS, the problem there is that you need certificates, and which the openness of the devices this became complex really quick. - So, we looked at RFC 2617, known as HTTP Digest authentication. This standard on top of HTTP allows for easy username/password checking, while being protected against: Man-in-the-middle attacks Eavedrop attacks Replay attacks However, there is one problem with the standard. It says that you can always fall back to lesser secure modes. Which offer limited or no security at all. So, we chose to implement one of the strongest forms of HTTP Digest, and REQUIRE it, instead of making all the security features optional. - This all sounds very complex. However, if you are a software engineer and you want to talk to the printer. You most likely have a library that will solve this for you. However, as suggested in the other topic, postman is implements Digest auth as such a low level that it is impossible to get this to work consistantly. The HTTP librart of QT has no problem with this. The "requests" library from python can also be used with almost no effort. I will provide an example in a bit. The cop-out If you are developing, and the security is in your way and you want to deal with it later. There is a cop-out. All this complex digest and pairing is disabled in the WiFi setup right now. As you are a local hotspot. This also made it easier to develop the WiFi setup. So, for quick testing, you can start a WiFi setup, and connect to the local hotspot, and talk to the printer without any security. The real thing Finally, some actual things. There are 3 API parts that are important at first. They are: /api/v1/auth/verify: Used to check if your authentication id/key is still valid. This is the only API which requires authentication on a GET request. If you go here with your browser, you will get the username/password popup. /api/v1/auth/request: This is used to setup a new pairing request. This needs to be done as a POST request, with 2 parameters "application" and "user". The API will return a JSON result with an "id" and a "key". This is your username and password for the HTTP Digest. However, this isn't valid till you pressed "ALLOW" at the printer. If you press "DENY", this combination of ID/KEY is discarded. /api/v1/auth/check/{id}: This can be used to check the status of your new request. {id} should be filled with the result from the /api/v1/auth/request call. The result will be one of: "unauthorized", "authorized" or "unknown". "unauthorized" means that the user pressed "DENY" and you can discard the ID/KEY. "authorized" means "ALLOW" is pressed and you can now start using this ID/KEY. "unknown" means that the user hasn't done anything yet and you should try again. Side effect: Currently, the printer only allows for 1 pairing request at the same time. If you send a 2nd request, the first one is denied automaticly. - So, in pseudo code: if no (id, key) or "api/v1/auth/verify" == "unauthorized" then id, key = post("api/v1/auth/request", application="Test", user="Daid") while "api/v1/auth/check/" + id == "unknown" do sleep 1 second end if "api/v1/auth/check/" + id == "unauthorized" then abort: failed to pair up. endend//We now have a valid id/key combination. All that, just to pair up. Doing actual things Still following me? Good. If not, sorry, this is all very technical. I will provide example code at the end. Now, we want to do thing. And there are quite a few things we can do with the API. I will cover a few things. Changing the printer name. Why? It's the easiest API. Changing the LED colors and heating up things. Starting a print job. Why? It's the most important API. Aborting a print job. After you started it, you might decide that you do not want it. (Or the print could be failing. But that is rare right?) Change the name Remember from day 1, the printer name was read at /api/v1/system/name. Now, we can set the printer name the same way, but instead of a HTTP GET, we need to use a HTTP PUT. Now, all our APIs require JSON as input. This means a few things, the data in the PUT request needs to be valid JSON. And the Content-type header of the request needs to be set to "application/json". If we want to set our printer name to MyUltimaker3, we get a request that looks like this: PUT /api/v1/system/name HTTP/1.1Host: 10.180.1.209Connection: keep-aliveAccept: */*User-Agent: python-requests/2.11.1Accept-Encoding: gzip, deflateContent-type: application/jsonContent-Length: 14Authorization: Digest username="2af8417b8501e0422e191d5fbe64209e", realm="Jedi-API", nonce="76684432bdb9a1a386a877e41468a681", uri="/api/v1/system/name", response="50da68df53c0eeb9906212560b0077aa", qop="auth", nc=00000003, cnonce="b2316951bb03e010""MyUltimaker3" This is an actual request that I logged. My auth ID is "2af8417b8501e0422e191d5fbe64209e" which you can see in the Authorization part, my auth KEY is "f9a43169c49bb9e81d670c946d6358dac428b820e0d9676e15b63bdcf57be45f", which you cannot see, and is used to generate the "response". Placing this here to possibly assist in debugging if you are doing your own implementation of HTTP Digest. The printer name is under some restrictions. So your printer might not always accept the new name. Changing the LEDs and heating up. Important note, in firmware versions 3.4.x these APIs are broken. They should be fixed as of firmware version 3.5.x Changing the temperature. This is easy, we want to set the target temperature. The APIs for this are: /api/v1/printer/heads/0/extruders/0/hotend/temperature/target /api/v1/printer/heads/0/extruders/1/hotend/temperature/target /api/v1/printer/bed/temperature/target And, just like the name, you can just put a value into it to change the target. As this needs to be in JSON format, it needs to be a number without quotes, while the name was a string and thus needed quotes. Setting the LED brightness and colors can be done in a single call. There are the APIs: /api/v1/printer/led /api/v1/printer/led/brightness /api/v1/printer/led/saturation /api/v1/printer/led/hue The last 3 set each value seperately, but the first one can be used to set all 3 in one go. You do this by sending a single json dictionary containing the proper key/value combinations to /api/v1/printer/led. Once again, this needs to be a HTTP PUT request. Example: {"brightness": 50.0, "saturation": 20.0, "hue": 100.0} Note, the current implementation of the API returns no status when you do this. So you do not know exactly if the request was accepted. Starting a print Starting a print is the most complex call there is, as you need to send a multi-part file upload. If you are not using a library for HTTP communication. Forget about it. Else, it's easy, just do a HTTP POST request with a file upload to /api/v1/print_job, with the name of the file parameter to "file". Abort/pausing a print job You might want to abort or pause a print job remotely. This is all done trough the /api/v1/print_job/state API. Once again with PUT requests. You need to PUT the new state you want into this state API, in the form {"target": "new state"}. There are 3 possible things you can PUT here. abort, requests the print to be aborted. pause, if the print isn't paused it will do so now. print, if the print is paused, it will resume printing. Note that this API in the current implementation always reports no content. So you need to poll the state to see if you request was actually honored. Wrapping it up. I'll just finish with my python3 code that can talk to the Ultimaker 3. You can use this as an example, or if you make an open-source product you can use it directly. ## This program is free software: you can redistribute it and/or modify# it under the terms of the GNU Affero General Public License as# published by the Free Software Foundation, either version 3 of the# License, or (at your option) any later version.# # This program is distributed in the hope that it will be useful,# but WITHOUT ANY WARRANTY; without even the implied warranty of# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the# GNU Affero General Public License for more details.# # You should have received a copy of the GNU Affero General Public License# along with this program. If not, see .import requestsimport jsonimport osimport time## Ultimaker 3 API access class.# Allows for access of the Ultimaker 3 API with authentication.# Uses the python requests library to do the actual http requests, which does most of the work for us.class Ultimaker3: # @param ip: IP address of the printer # @param application: name of the application in string form, used during authentication requests and is shown on the printer. def __init__(self, ip, application): self.__ip = ip self.__application = application self.__session = requests.sessions.Session() self.__setAuthData("", "") # Set new authentication data, authentication data is send with each HTTP request to make sure we can PUT/POST data. def __setAuthData(self, id, key): self.__auth_id = id self.__auth_key = key self.__auth = requests.auth.HTTPDigestAuth(self.__auth_id, self.__auth_key) # Load authentication data from a file. If this file does not exists, or the data in it is invalid, we request a new authentication set and store it in the file. def loadAuth(self, filename): try: data = json.load(open(filename, "rt")) self.__setAuthData(data["id"], data["key"]) except IOError: self.__checkAuth() self.saveAuth(filename) if not self.__checkAuth(): self.saveAuth(filename) # Save the authentication data to a file. def saveAuth(self, filename): json.dump({"id": self.__auth_id, "key": self.__auth_key}, open(filename, "wt")) # Check if our authentication is valid, and if it is not request a new ID/KEY combination, this function can block till the user selected ALLOW/DENY on the printer. def __checkAuth(self): if self.__auth_id == "" or self.get("api/v1/auth/verify").status_code != 200: print("Auth check failed, requesting new authentication") response = self.post("api/v1/auth/request", data={"application": self.__application, "user": os.getlogin()}) if response.status_code != 200: raise RuntimeError("Failed to request new API key") data = response.json() self.__setAuthData(data["id"], data["key"]) while True: time.sleep(1) response = self.get("api/v1/auth/check/%s" % (self.__auth_id)) data = response.json() print(data["message"]) if data["message"] == "authorized": print("Authorized.") break if data["message"] == "unauthorized": raise RuntimeError("Authorization denied") return False return True # Do a new HTTP request to the printer. It formats data as JSON, and fills in the IP part of the URL. def request(self, method, path, **kwargs): if "data" in kwargs: kwargs["data"] = json.dumps(kwargs["data"]) if "headers" not in kwargs: kwargs["headers"] = {"Content-type": "application/json"} return self.__session.request(method, "http://%s/%s" % (self.__ip, path), auth=self.__auth, **kwargs) # Shorthand function to do a "GET" request. def get(self, path, **kwargs): return self.request("get", path, **kwargs) # Shorthand function to do a "PUT" request. def put(self, path, **kwargs): return self.request("put", path, **kwargs) # Shorthand function to do a "POST" request. def post(self, path, **kwargs): return self.request("post", path, **kwargs) It's a very basic wrapper around the very new "requests" library for python. But it helps in setting up the authentication. Example usage: api = Ultimaker3("10.180.1.209", "Test script")api.loadAuth("auth.data")# Get all the system datasystem = api.get("api/v1/system").json()print(system["name"])# Change the system nameresult = api.put("api/v1/system/name", data="MyUltimaker3")print(result.json())# Set the target hotend temperature to 100C, and then back to 0.print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json())result = api.put("api/v1/printer/heads/0/extruders/0/hotend/temperature/target", data=100.0).json()print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json())result = api.put("api/v1/printer/heads/0/extruders/0/hotend/temperature/target", data=0.0).json()print(api.get("api/v1/printer/heads/0/extruders/0/hotend/temperature").json())# Change the LEDsapi.put("api/v1/printer/led", data={"brightness": 50.0, "saturation": 20.0, "hue": 100.0})# Start a print job.result = api.post("api/v1/print_job", files={"file": ("UM3_Box_20x20x10.gcode", open("UM3_Box_20x20x10.gcode", "rb"))})print(result.content)# Pause the printapi.put("api/v1/print_job/state", data={"target": "pause"})# Resume the printapi.put("api/v1/print_job/state", data={"target": "print"})# Abort the printapi.put("api/v1/print_job/state", data={"target": "abort"}) - - Disclaimer: Any information presented here could be wrong. I did my best to proof read everything, but it could confict with official statements and the actual behavior of the printer. This post is purely informative and does not necessary reflect the official view of Ultimaker.
  9. Hello all, Thinking of selling my UM3, because might be investing into another printer, so figure to put a feeler out! it comes with original box UM3 2 AA print cores 1 BB print core Glass print bed Several goodies that came with the kit I am in Los Angeles, prefer local sale shoot me a message or reply if interested! Kevin
  10. There are scratches everywhere but I am mostly worried about getting rid of that blob of PLA. I tried heating the printcore up to 210C for 10 minutes but to no avail. Any ideas of how to get rid of it without damaging any vital parts?
  11. Hi, I just bought an Ultimaker 3 and installed the newest firmware and I have the Cura 4.2 installed. The wifi setup worked and the printer is connected to wifi. However, after around 30 minutes or so, the printer cannot be contacted through wifi even though it says it has a connection to the wifi. I cannot even connect trough the browser to the printer when this happens. This is happening constantly to me. The current workaround seems to be to restart the printer when this happens but this is quite annoying especially when doing a lot of test prints for small parts and doing minor tweaking to the parts. Any help?
  12. Hi, I recently bought an aluminium PEI coated printing bed from clever3d. Since i am changing from a glass printing bed to the PEI bed i noticed the specified printing bed in Cura. I tried to find any configuration in Cura where i could add a printing bed type with a specific configuration (e.g. temperature) for specific materials. Is it possible to specify a custom printing bed in Cura with it's own dedicated settings or is the only available printing bed "glass"?
  13. This is a project by a group of community members which was also involved in the Mark2 dual extrusion upgrade. More precisely, it's me coming up with an outside the box approach / weird idea for a certain unresolved problem. Smart people like @gr5, @Anders Olsson, @Dim3nsioneer, @rooiejoris throwing in ideas and @tinkergnome who implants the stuff into firmware. My impression of the current state of development when I started this was as follows. There have been filament monitor projects since the beginning of reprap. Only very few made it to some kind of product state, like the one by Aaron Tunell. Manufacturers like Prusa and others recently introduced some kind of filament monitors, with mixed success / reliability issues. The Duet3D guys set their hardware research (laser-based and rotating) on hold because they were experiencing inaccuracies of +/-20%. Well and then there was Ultimaker ... until yesterday with the S5 All these efforts have been or still are struggling to fulfill the most important objective: NO FALSE ALERTS. Otherwise any filament sensor would quickly render itself useless. What we want to achieve Objectives, the obvious part: zero false alerts detect filament runout ("nothing there") detect filament grinding ("nothing/very little moves") Objectives, the challenging part: detect first layer issues (see video below) detect when real flow leaves a certain safe process window and starts to compromise part quality (first, inter layer adhesion will suffer, then classical under extrusion will be visible) and try to counteract, that's where the real fun starts ... Current state of development We chose an encoder and there's a reliably working prototype for an easy to attach external flow sensor, mounted to the entry side of the feeder. Resolution is in the range of 0.015 mm. It's integrated in Tinkerware with a dedicated menu and we (well, he) implemented a gcode command: M591 T0 S1 E0.5000 L0.01695 R35:130 A0.3 P100.00 I leave the parameter interpretation as a little quiz here. Right now I'm working on a modified design which, besides the encoder, doesn't need some parts which cannot be printed and are in the +30€ range to have them manufactured. But most likely some parts will still not be FFF printable. How can I get this? First give us some more time to test and evaluate. If everything works like intended we might proceed like with the Mark2 project. If we should offer this as a product I'd expect a price tag between 70-100 €. And the UM3? That's the BIG question. Like @Daid recently stated their main market is already different. And indeed, has anyone seen any kind of (hardware) upgrade for the UM3 so far? Feeders are the same, mechanically our sensor fits. Electronics, not sure. Ultimaker originally wanted to use a serial interface on the UM3. For the UM2+ we simply connect the sensor's quadrature output signal to free I/O pins, there are enough left (4) for two sensors for a Mark2 dual extrusion UM2. Ultimaker won't do anything to support a sensor on the UM3. Anyway, if a large number of UM3 users would show interest, they might at least not impede a development ...
  14. Does anyone knows if it´s possible to create own nfc tags for the UM3? The tags from the UM spools can be read from my Samsung S7, but the data format is unknown.
  15. We are having this issue with UM3. This started when we updated printer to 5.2.11 firmware. This has been confirmed by 5 users of UM3 uptill now if you have UM3 please make a test, and let me know. Edges on corners are roundes as you can see on image bellow. Also, I have done some measuring all sides are +0.2 and corners are extra +0.3 so this cube measured on sides is 0.5mm bigger than it should be. I've added new printcore, done factory reset and tghten short belts still the same. This is made with Cura 4.1 with ultimaker green pla and default settings. I have tried older version of cura 3.6 and same thing.
  16. I was doing manual leveling and follow it with active leveling once a time every month, mostly. AT first, I thought my Ultimaker3 printer's active leveling started to fail. After a few more times, even manual leveling isn't helping, I guess. No matter how i manually level the nozzles, or use active leveling, the printer will always press nozzle 2 too close to buildplate once print is started. I can see the nozzle was so close that it got pushed back a bit upwards, so close that filament cannot print out of it. Is there a fix to this? I am not sure why this is happening. I suspect the distance between Nozzle 1 and Nozzle 2 somehow was wrong, becuz nozzle 1 works just fine... Meanwhile to keep work going, I manually loosen the 3 screws a bit after manual/active leveling to compensate it while using nozzle 2.
  17. The PVA doesn't seem to sticks well to PLA now with the current update. It works well before the 4.0. Mind that this is for new PVA and new PLA, moisture doesn't play a part here. And as the PVA doesn't sticks well, it travels throughout the model while printing, and get caught in midway thus leaving a lot of holes and scratches on the body. See picture
  18. I was doing manual leveling and follow it with active leveling once a time every month, mostly. No matter how i manual level the nozzles, whenever active leveling is done, the printer will always press nozzle 2 too close to buildplate once print is started. I can see the nozzle was so close that it got pushed back a bit upwards, so close that filament cannot print out of it. Core 1 will always be fine and well calibrated, while Core 2 will always be too close to bed, after active leveling. Either the active leveling is buggy, or the result of Z calibration between the 2 nozzles are not memorized by the machine. Is there a fix to this? I am not sure why this is happening. I suspect the distance between Nozzle 1 and Nozzle 2 somehow was wrong. Now I have to set the machine never to do active leveling, and rely on manual leveling. It will be great if there's a way to manually set the Z distance difference of the two cores in cases like this when the active leveling somehow failed?
  19. I am printing somefairly small miniatures and their legs always give me headache for printing. The above image shows the layer shift on the legs. I am using UM3 with PLA, most of the time my prints are fine but when it comes to small things and structure like this it seemed to fail. The adhesion is okay, but after a while the nozzle started to sort of knock the legs around a bit causing a layer shift during print. I have been printing slow at 30mm/s. I have checked the belt and they are tight. I have done manual leveling on buildplate just in case. Switching materials(brands) doesn't seem to hv differences, and this is some good eSun filament. none of the above action help. So I am going to show you how i slice my STL, see if i done sth wrong there. I have tried different ways and both still have layer shift issues. The first one with support interface enabled, support enabled, support brim enabled, tree support enabled, and increased 40% support density. The nozzle would knock on the printed legs and cause layershift mid-way, usually on one of the legs. The second one is on same settings but with a manually added cube printed as support. This one has less major layershifts but lot of minor shifting along the print, the result is shown in the first photo. Any good advice?
  20. I am usually printing small figurines so i didn't walk into much warping issues. until now that i have to print a box-like object with a large base. It seems the normal default print settings that worked in the past doesnt fit now. I was printing with mostly default "fine" profile on UM3 with 0.4 nozzle PLA 185C at 50mm/s, with a Brim, 60C build plate as usual. Sometimes the base of the model will warp up so far as it lift some of the brim around it off the build plate. Lot's of tutorials out there talk about wrapping issues, some mentioned very different/contradicting solutions, but I still fail to perfect my print. Printing with lower temperature sometimes cause even more warping/lifting the brim, that's to my surprise. I am wondering if printing slower factor into issue?
  21. This motion used to be smooth when manually calibrating - now it is quite jumpy across all our ultimakers. Just wanted to feed this back...
  22. Alex74

    Sous-extrusion

    Bonjour à tous, Depuis peu j'ai des soucis de sous-extrusion... Je n'ai pas changé de filament, la buse AA que j'utilise n'est pas très usées, j'ai juste installer le nouveau cura... J'ai naturellement nettoyé mes printcores, je ne vois pas trop d'où ça vient. J'en ai même profité pour retendre mes courroies. Que j'utilise ma vieille buse ou la plus récente j'ai le même résultat. On voit bien que les trajets ne sont pas comblés et qu'entre les parois intérieures et le remplissage il y a carrément un vide ! On dirait un débit foireux ou un buse bouchée (mais elles sont toutes les 2 bien propres). PS: Ma UM3 a déjà passé 15Kg de PLA/Nylon (+un peu de TPU et PET). La première buse est d'origine (donc bien rongée) la deuxième je ne m'en sers que depuis quelques mois... A ce stade l'UM3 a besoin d'un entretient spécifique ?
  23. I am selling my Ultimaker 3, very good condition ~95 days printing. For $2500 + Shipping (US Only) It has the Bondtech DDG upgraded extruders (for both extruders) as well as the parts for the original extruders. Its in great condition with all original factory parts including 2x AA 0.4 and 1x BB 0.4 print cores. Here are some photos of the printer and a small sample of what I have printed with it: This is a print that I finished minutes before posting this topic:
  24. Hi everyone, *** EDIT: For clarification the filament is only stripping when running a dual colour print. I've been able to run single colour prints from both nozzles without any issues using this filament. *** I'm having issues with the drive gears stripping filament on a dual colour PLA print. It seems to happen at random - both nozzles will be printing fine for a couple of hours and then out of nowhere one or the other will start having massive underextrusion and the filament will look as slightly torn up over a 10-15cm span out of the drive gear housing, and then the fatal groove where the gear finally ate too much. I'm using a "glitter" filled PLA with the 0.4mm AA print cores at 200C and 70mm/s. Here's a list of things I've tried to save people time suggesting things I've already done: - Changing the tension on the drive mechanism. I've tried it real tight, real loose and everywhere in between and the only thing affected is how much the filament gets chewed. - Thoroughly cleaning out the drive mechanisms, including cleaning the gears down. - Cold pull cycling the nozzles. I don't think the issue is clogged nozzles as filament extrudes freely without cleaning the nozzle out each time I have a problem, but I tried this anyway. - Changing the standby temperature from 100C to 160C and a couple of stages in between. - Changing retraction distance, limit and speed to try to limit the number of times the filament was run over the drive gear in the same place. Feel free to suggest any settings you know to work well for 2 colour prints as I'm not sure I've covered all the options on the retraction side of things! If anyone has seen this before or has any new ideas that'd be extremely helpful, thanks in advance! Glen
  25. Hi guys, I have the problem that on long running prints I get underextrusion during the print. I'm using an Ultimaker 3 with standard AA 0.4 nozzles and PLA. At the beginning everything is normal and looks fine, but after some time underextrusion starts till in the end no material is extruded any more. Afterwards I have to clean my nozzle because it is clogged. I already checked the feeder, this is looking fine. I don't think that it is the material as this is not the first time this happens and not only with this material. Also it just happens in long running prints. I also checked the other nozzle, but there i have similar problems. Do anyone has any ideas left? Thanks in advance
×
×
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!