Jump to content


Team Ultimaker
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by CarloK

  1. IT-departments never cease to surprise me... With a correct DHCP configuration you don't need static ip-addresses. Your DHCP server can be configured to always assign the same ip-address based on a once configured MAC address. Then, for the host name, DHCP has an option to change the hostname as well. So, with a well equipped IT-department they could handle it all themselves instead of you having to do crazy things (and we as well). Note that RFC-1035 says the length is limited to 63 characters. So why your IT-department comes with an 18-character limit is surprising. As a side effect of renaming: Cura won't be able to detect the printer anymore automatically, you will have to enter the ip-address instead. Changing the host name: - Ensure printer is in developer mode - Log in to the printer with SSH - type: vi /etc/rc.local - in line 4 you see a line starting with 'hostnamectl .... ' Mark this line as a comment by inserting a '#' as the first character - insert a new line 5: hostname my-fabulous-new-name - Save the file - reboot the printer with 'reboot' command - Log in again and - Check by giving the 'hostname' command without parameters. This change will have to be applied after every firmware update.
  2. You have two problems that I think are unrelated: 1) After rebuilding your printer the printer shows an ER05 for the Z-axis being broken 2) Cura 4.5 can't upload firmware from a Windows 10 computer I want to focus on problem 1 first, since when we get that working you don't mind about problem 2 anymore. There is an article on this forum where people reported the same problem when the 5V fan connector was connected to the wrong pin header. In the middle of the board is a connector marked JP3 - 8/16 step, when you connect the fan here it causes the stepper motor to make smaller steps and missing the Z-switch. The right connector is 4cm to the right and marked J34 - 5V Fan. See this thread for more details and photo's:
  3. Thanks for reporting, it is assigned internal ticket number EM-3499 All our translations are centralized in a widely used tool. Something went wrong and for many languages the hour symbol changed to an 'M'.
  4. M190 with the 'R' option is not supported by the Ultimaker printers (at least not with the current v5.6 of the firmware). What you can do is to add a wait time: G4 S<time in seconds> We did a similar project for series production where we printed 1 PLA object and then used the print head to bump it off the glass plate. So, it is possible but we didn't cool the build plate in between prints. We added the famous blue tape to the build plate so the adhesion of the PLA was good, but weaker than when printing on the glass plate.
  5. Print times do differ between Cura versions but I know that these changes are being monitored with every release and large deviations are being fixed, unless the extra delay improves print quality. A factor 2 difference sounds like a change in settings. Can you share more info? What was the old Cura version and what is the new version you are using? What printer brand & model are you using? Can you post the model?
  6. That's not true, the used material quantity is updated quiet often in the NFC chip. You might loose a few cm of filament but that's within accepted margins. One of the main reasons we never implemented this feature is because we don't know how accurate the filament length is to start with. On the S5 you have the filament sensor which will pause your print at the end of the roll so you can switch to a new roll.
  7. Great to hear your printers are working now! I forwarded your WiFi findings to my colleagues working on the S5 printer's firmware. We had WiFi related problem reports before, but could never reproduce it. Your report gives some new details that hopefully will help find the problem.
  8. @slnielsen Me too would like to hear what problems your IT-department has with our restrictions on the allowed hostname format. We implemented it according the RFC952 standard, but there might be interpretation differences that I'd like to hear about.
  9. @gr5 Thanks. I missed the update to his post. I couldn't explain why v5.1.7 was failing.
  10. Ultimaker never released a dual extruder UM2 printer since we couldn't get it working as reliable we wanted. All 3D printers with a second nozzle have the problem that the other nozzle can damage your printed object, so special measures have to be taken to avoid that. For example, the UM3 printer changes the height of the second nozzle. You can download the UM2+ source code and then change the configuration settings to activate the 2nd nozzle, but without mechanical improvements to change the height of the other nozzle your project will never print reliable.
  11. The S5 with v5.1.8 can't find the update files on the USB drive. This release is already looking for the update files in the new *.swu file format, but soon after the release some changes were made so it needs to update to the intermediate 5.1.94 version which was only released in the older *.tar format. Sorry, we messed up this one and hence v5.1.8 was only available for download for a week I think. I was not directly working on that project, but I think the official work around is to do a network based update. I understand you can't connect the printers to internet? Then I suggest to install the firmware using the recovery method, this involves downloading the firmware to a micro SD card, removing the bottom cover from the printer and inserting the SD card. Ultimaker doesn't recommend this method for the S5 printers since there are dangerous high voltages inside (110V/230V) so take extra care to switch off the power before removing the bottom cover. An official guide is missing for the same reason, but you can use the attached UM3 guide. In fact, for the S5 it is easier since the SD card slot can be accessed without removing the UM3's USB cable. When you are planning to use the S5 in combination with a Material Station and/or Air Manager you can download the recovery image v5.4.29 from: https://software.ultimaker.com/releases/firmware/9051/stable/5.4.27-20191212/um-restore-5.4.27-20191212.img Without Material Station I recommend the older but very stable v5.2.11: https://software.ultimaker.com/releases/firmware/9051/stable/ 567519794_WorkInstructionsUltimaker3firmwarerecovery.pdf
  12. What is your firmware version? Have you tried the directions at this page? https://ultimaker.com/en/resources/23129-updating-the-firmware?download=%2Fen%2Fresources%2F23129-updating-the-firmware
  13. Ok, I see some differences in how I performed my test. I will re-try too. How do you perform the Welcome setup steps? Do you execute the steps where you have to load the printcores? I always skip all the steps. I suspect a problem with the switching bay settings. I know you calibrated this but I've seen it fail and couldn't reproduce it. In the maintenance/diagnostic menu there is a 'switching test'. Can you execute the test for switching the second nozzle? Are these running good? Is the right nozzle actually moving down and up?
  14. An old topic, but besides a bad USB drive we recently discovered another root cause for the weird error messages with 'line nr = xxx'. When the line number refers to a gcode line with 'G0' or 'G1' in it, then this is a late error message from Active Leveling. In an earlier stage the Active Level probing failed and that software error wasn't handled. We will have to fix that in software and show a better message, but also check your build plate as it might have a curvature out of specifications. A curved build plate might explain how the error disappeared; perhaps the build plate was moved, flipped or turned? Also printing the object on a different region of the build plate would create another probing pattern skipping the curved part.
  15. @V3DPrinting I'm sorry to hear about your problems. First, yes it is possible to downgrade the software to v4.3.3. Attaching the document failed for some reason, but it was also discussed in this thread. The problems you experience are most likely related to the firmware in the printer and I really like to figure out what is going wrong. I tried reproducing all the steps you mentioned but in my printer that worked correct. So, my guess is you are doing some detail in a different way than I did when trying to reproduce. What printcore type and diameter are you using? What material type are you printing with? Do you use the default first layer height in Cura of 0.27mm? When you say you disabled the Active Leveling on the printer, then how did you do this? Did you achieve this by setting the bed leveling frequency on the printer set to 'never'? Is it possible you mail me the log files of a failing print? (hoover your mouse on my avatar picture, a pop-up will show where you can send me a message).
  16. I'm sorry to hear of your problems. What firmware version is installed on your printers? V5.4.27 is the latest. There are reports of blobs in v5.2.11 when the printer is connected by WiFi, the solution was to use cable instead but we fixed a bug in v5.4 that should fix that problem.
  17. 1) In the current firmware (v5.5) we don't check the checksum on reading. GR5's method now works and later the correct CRC is written. Checking the CRC on reading is a long standing wish to implement since on some printers the long cable to the printhead creates bad readings. Starting a print with corrupted configuration data can lead to all kind of print failures. So yes, for now GR5's method works but might fail with a future firmware. 2) The nozzle diameter as numeric value isn't ignored. It's currently used in generating the XY-printing pattern and more uses might follow. 3) The counters are not touched by my code, they are at another memory address range. And I'm not going to explain in this forum how to reset those counters. 😎 4) You describe the XY-calibration settings correctly. This wasn't something I was referring to. 5) The fancy header in the gcode is required for the newer printer firmware versions to accept the file. As noted, the attached files were created for the UM3 series of printers since the original topic starter was using an UM3 Extended. For the S5 printers change the line: ;TARGET_MACHINE.NAME:Ultimaker 3 to ;TARGET_MACHINE.NAME:Ultimaker S5 @gr5 you correctly indicate the attached files will not work for 3dsolex print cores. I don't know the physical properties of those cores. So people using a 3dsolex core should use your procedures.
  18. @jphahn63 This forum section is about discussing the software (firmware) inside the Ultimaker printers. I don't completely understand your request, but to me it looks like a Cura request which then should be posted in the Cura section of this forum.
  19. Thanks for reporting the 5.3.4 update being marked as 'new' even after installation. This was a problem on our web server and has been fixed now. About the log message for a testing version not being found: Ultimaker uses test releases for people to test new versions that fix problems or add new features. These test releases have not gone through an extensive test procedure and hence are not considered good enough to be released as 'stable'. Since the S3 is a new printer model we never before released a test version and so this message pops up in the log file. To avoid confusion about these log messages I just uploaded the identical v5.4.3 to testing as well. The testing and stable versions are identical so it makes no difference which one you install.
  20. The only suggestion I wanted to make is that you go for the cheapest as both types will work. As GR5 says, the old one delivers a bit more power but we as Ultimaker are not allowed to sell it anymore with new printers. The newer type is a bit more environmental friendly and will save a few cents in electricity.
  21. T1 and T2 are BC817 NPN transistors. T3 is a BC807 PNP transistor So glad Ultimaker provided the schematics so people will study them .... 🙄 https://github.com/Ultimaker/Ultimaker2/blob/master/1091_Main_board_v2.1.1_(x1)/Main Board V2.1.1.pdf T3 indirectly switches on the 24V for the motors and the bed. So with a wrong type of transistor here it explains the wrong behavior in your printer.
  22. During the printing of the XY-calibration pattern you can adjust the flow and temperature like with any other print, but our goal is that for all Ultimaker approved materials this should be working out of the box. The 0.25 nozzle is not as well tested as the 0.4 nozzle and I will test again to see if I can find some grinding related problems.
  23. Did you perhaps install firmware for another printer? You say you have the UM2 and installing firmware for a UM2+ could show this behavior. Which Cura version are you using? We are now at Cura 4.3, but I remember about a year ago there was a bug in Cura where firmware versions for the UM2 and UM2+ were mixed up. Instructions for re-installing the firmware on a failing UM2 printer The newer versions of Cura are being 'nice' to your printer and that's why they fail in programming. In order to start the programming process, Cura has to reboot the printer. That's what older versions of Cura did when you connected the USB cable. Disadvantage was that when you were printing and you started Cura, then your multi-day print would reboot as well.... Oops. So, now Cura is nice to the ongoing print process but as a consequence fails to program a printer that's stuck. Your workaround is to use another program for programming the printer. One option is this old version of Cura: https://software.ultimaker.com/cura/Ultimaker_Cura-15.04.06.exe There are other programs as well, but I haven't done this since long so are not aware of the current situation. Look for programs that can program an Arduino AtMega 2560 board The UM2 firmware is a *.hex file and is included in the Cura program directory. For the UM2+ a release candidate for the next official version can be downloaded here: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/releases/beta/MarlinUltimaker2plus_20181007.hex (right click on link, and then 'save link as').
  24. I just stumbled upon this thread and thanks for reporting. I can confirm this fixed in firmware 5.2.13 (not released yet) and 5.3 (S3 only).
  25. I had a long look into this problem, but it is a difficult one to tackle since I can't reproduce it myself. My feeling is that the problem is caused by a sequence of actions involving the combination of manual leveling and Active Leveling. In the V5.0 release for the S5 we completely overhauled the Active Leveling software. Since the S5 build plate is larger than for the UM3 the undulations became too big to be solved with a simple 3-point leveling, that's why we introduced the grid based probing. The probing algorithm itself was also rewritten to be more accurate and faster. The v5.2 release integrated the UM3 and S5 to be one software package again which for the UM3 has a lot of changes under the hood that you won't see but will be beneficial like: - A year of software development, including lots of bug fixes. - A new Linux version - A new file system on the internal Flash memory for improved long term stability - The overhauled Active Leveling - A much improved version of Cura Connect, including Cloud connection - etc But.... for the users in this thread the v5.2 firmware breaks Active Leveling on the right print core. And I can't reproduce it which annoys me a lot after all the time I spent looking for the cause. The problem seems to be caused by switching between manual and Active Leveling. Could one (or more) of you please sent me the log files from your printer when it fails? Sent the files to me by private email (hover your mouse on my name avatar picture, a pop-up will show with email option). Add a short description of what you did and what you saw happen.
  • Create New...