Jump to content
Ultimaker Community of 3D Printing Experts


Team Ultimaker
  • Content count

  • Joined

  • Last visited

  • Days Won


Daid last won the day on January 27

Daid had the most liked content!

Community Reputation

248 Excellent


About Daid

  • Birthday 01/01/2015
  1. The mock printer hasn't been updated, and thus isn't current, and thus useless. I highly recommend the cable so you can always debug/recover from a brick. Even if the risk is fairly low. The recovery by micro SD card also works to fix a brick. Next to that, you can also run the whole system on a virtual machine, there is actually a software setting somewhere (I forgot where) that allows you to use the "marlin simulator" instead of talking to most of the main hardware. But setting that up is quite a bit of work.
  2. There seems to be 3 bugs: Cura didn't emit the profile string UM2 firmware thinks the print is finished before it actually is The UM2 "print finished" code calls the "abort print" code, aborting a few final moves, and then sets the current filament position incorrectly. Combined they provide this behavior. I think the fix for 2 and 3 are relatively easy: diff --git a/Marlin/UltiLCD2_menu_print.cpp b/Marlin/UltiLCD2_menu_print.cpp index e3cd69a..5755583 100644 --- a/Marlin/UltiLCD2_menu_print.cpp +++ b/Marlin/UltiLCD2_menu_print.cpp @@ -104,7 +104,7 @@ static void checkPrintFinished() lcd_menu_print_pause(); } - if (!card.sdprinting && !is_command_queued()) + if (!card.sdprinting && !is_command_queued() && !blocks_queued()) { abortPrint(); currentMenu = lcd_menu_print_ready; diff --git a/Marlin/stepper.cpp b/Marlin/stepper.cpp index ff6e388..ebfbeff 100644 --- a/Marlin/stepper.cpp +++ b/Marlin/stepper.cpp @@ -933,7 +933,7 @@ void quickStop() current_position[X_AXIS] = float(st_get_position(X_AXIS)) / axis_steps_per_unit[X_AXIS]; current_position[Y_AXIS] = float(st_get_position(Y_AXIS)) / axis_steps_per_unit[Y_AXIS]; current_position[Z_AXIS] = float(st_get_position(Z_AXIS)) / axis_steps_per_unit[Z_AXIS]; - current_position[E_AXIS] = float(st_get_position(E_AXIS)) / axis_steps_per_unit[E_AXIS]; + current_position[E_AXIS] = float(st_get_position(E_AXIS)) / axis_steps_per_unit[E_AXIS] / volume_to_filament_length[active_extruder]; plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]); } But I haven't tested those. Adding a comment block at the end, of an M400 in at the gcode will most likely work around the 2nd bug. And thus not triggering the 3th, unless you do an abort, that can also trigger the 3th bug.
  3. For material upload errors, most things actually end up in the logs instead of in the API output (due to some shortcuts taken in the code) The UM2 and UM3 share almost no code. The code is actually readable on the UM3 itself, as it's all python. Logging in with ssh in /usr/share/griffin/griffin/interface/http you can find the API implementation.
  4. No, 401 would indicate authentication required. 400 means the parameters to the call are not as expected, most likely our documentation is slightly wrong then. For setting the printer name, the data needs to be proper "json", so it is missing quotes inside the data. -d '"Ultimaker"'
  5. Firmware Code Displayed on UM3 UI prompt

    I'm just glad you managed to work around it for now. I've also submitted a fix for this problem so we ignore wrongly retrieved version numbers it in the future.
  6. Firmware Code Displayed on UM3 UI prompt

    You mean we failed to catch this bug. We're only human. And I think we acknowledge the bug right here... The reason it's still being the same scroll wheel as the UM2 is part of the turbulent history of Ultimaker. Everyone agrees that our interface (screen+button) is not of this age, and a bit embarrassing. The reason for no separate back button is easy. Because a 2nd button makes it an awkward and bad UX. The Replicator 5gen has it, and it only makes it more awkward to use the interface. It was a very well thought out choice not to add more buttons. While an extremely horrible thing to do, you'll have to scroll down all the way on the "new update available" message and hit the ignore button. It's far from ideal, but as we didn't account for this issue, there is no other workaround. But then you should be able to reach the main menu.
  7. For remote control, you don't need developer mode. You need to access the HTTP REST API.
  8. Indeed the firmware is the same, there is 1 firmware for all machines. The type of machine however, is stored on internal EEPROM on the board. The command "python3 /ulti_installer/configure_eeprom.py 9066" (or 9511 if you need an extended instead of a normal UM3) will change the machine type. Needs a reboot before it's picked up.
  9. Prime blob knocked down (Cura/UM3)

    As far as I know, we disabled the prime poops. Or, at-least, Cura has the capability to do so. Technical background: There is the custom "G280" command that does the priming and sets the current E value to whatever the filament position is compared to the hotend. So "G1 E0" will put filament at the tip of the nozzle after the G280. As we noticed the priming poop was giving problems, but we did need to account for backwards compatibility. We added "G280 S1", which does set the filament position, but does not do any priming poop. As our filament position tracking is now quite good, as long as you don't bypass the filament loading/unloading on the machine priming isn't really needed. I don't know what is the default in Cura.
  10. I didn't say those 2 things. I didn't say that I believe in open source (but I guess my past actions speak for me), and I didn't say that the people who have a big say don't believe in it. I only said it's not high on the priority list to solve. I didn't even say that I'm not one of the people that has a big say in it ;-) As for tinkering with machines, the UM2 is much more suited for that. We use it for that at the office as well quite often. It's a much simpler machine with much less to go wrong. And a lot easier firmware. So I would actually recommend the UM2+ as hacking platform instead of the UM3. This, we have a few bits and pieces of documentation. But nothing that is near the level that you would expect to have when you want to roll fresh into the code. As for ssh into the printer, you'll have to turn on developer mode. And then you can login with ssh as root, you can guess the password. Note that the UM3 is open for your whole network then, so that is a security risk. (As for the burned in screens, I've seen it on the UM2. I haven't seen it on the UM3 yet, which dims the screen when it's not in use)
  11. I wish I could tell you "yes and a date". But that's not the case right now. In parts of the company there is still a heavy discussion going on on this topic. On all points (if, what, when, how, where). And the discussion is slow, due to it having low priority for most people that actually have a big say in this. Most of the printer logic itself is actually accessible already on the printer trough ssh, as it is python. So you could already patch that and send us fixes. Except for the display code, which is compiled C++, and to be honest, a mess. Combine that with the very few patches we got from the community for the Ultimaker 2, it's really hard to sell this. There is also a general difference in view on how certain parts should work. Engineers generally want more features, more options, more things to play with. However, a large part of our use base isn't engineers at all. So quite a few patches, while valid, we wouldn't merge, as they do not match our view (for the UM2, this is clear with the differences between the Tinker firmware and our firmware) Some parts are already open, like the kernel, u-boot, connman and a bunch of other things. Even the easter-egg code is published somewhere, if you know where to look (I got no pull request for that :( ). For Marlin, we have the issue that our repo has a lot of secret branches, and commit messages that referrer to secret things. But if anyone wants a copy of that source, we will share any release state. But we cannot open the repo till all those secret projects are purged or released.
  12. How to remote control Ultimaker 3?

    Oh, scrollwheel also works with this patch. As the rotation button already acts as a scrollwheel (for that I just had to fix the hot-pluggin)
  13. How to remote control Ultimaker 3?

    Just build the code to accept any USB mouse as alternative to the rotation wheel. The up/down movement of the mouse simulates rotating, the left button simulates clicking. Put it up to review for my fellow developers. With a bit of luck I will have a test version soon.

Important Information

Terms of Use Privacy Policy