Daid

On the flow sensor, in theory it is simple, put a rotation sensor on the filament, check how much rotation you are getting compared to how much you are asking, differs by X, flow problem and pause. In practice however, you need to get that sensor always touching the filament. Always. Without deforming the filament. This is actually a bit harder then it sounds. Some designs worked fine for a few spools of material, and then suddenly have a 2 cm extrusion of "no touching" due to some mechanical problem. Next, how much filament we ask and how much we are getting is not a 1:1 relationship. Even tough our prints are coming out fine, there is a lot more happening then you initially expect. Filament itself compresses in the bowdentube. There is pressure in the hotend that slowly relaxes, and a retract+unretract does not move equal distance. The back-pressure of the build plate on the first few layers causes under-extrusion. Just to name a few things that can cause false triggers. And those are just the things I know, and I wasn't even on that team!

The UM3 and the S5 run the same firmware, with a different machine configuration. So any firmware improvements on processes like changing material, pausing, etc, tickle down to the UM3. Cura Connect is also on both, and thus any improvements there also tickle down to the UM3. UMO and UM2 can only expect bugfixes in firmware. But continued Cura support as always. (Also, you commented on the UMO noise, most of the noise there comes from the material feeder, the back plate is acting like a noise amplifier, you can get some serious noise reduction by isolating the vibrations from the feeder to the backplate)

The leveling is still using the same sensor, it just measures on more points. Electronics are not 100% the same, but 90%. Software is still the same base as the UM3. Oh, and yes, I forgot the Trinamic stepper drivers. The noise is much much less. The fans are the noise producers now. (Technical detail, TMC2130 is the chip we use) No new motion controller, still the ATMega2560. We had it as an option to upgrade this as well. But we made the choice to keep it close the UM3. (You could see the S5 as an UM3+) I don't know exactly why the Aluminium plate won't be available directly. Some things I overheard could indicate a supply chain issue (the plate needs a proper coating), but don't pin me down on that part, as it could also be profile development. I can only speculate just like the rest of you, as I don't know everything that is happening anymore. As far as I know, the flow sensor won't become available as upgrade kit for the UM3. We had that as option on the table, but I though the latest design no longer fits directly on an UM3 mechanically. And the market that we are in right now isn't super fond on upgrade kits, even if you guys are :-)

It's bigger. 330x245x315mm to be exact. And that volume can be used by BOTH nozzles. No more less volume for dual extrusion prints. It has a flow sensor, that works for jam detection as well. Yes, we spend a shitload of time developing this one. It has been in development even during the UM3 development. As we wanted in the UM3 initially, but we cut it from the release then when it didn't work properly. Solves the 750g spool problem. I think we've gone trough 2 different sensor chip designs, and a whole bunch of mechanical designs before that part was perfect. Then the software when trough a few large iterations as well. This was quite a ride. Touch screen, better late then never. Doors, just improves print quality, especially with high temp materials. But we all already knew this. Expansion port. Next to the spool holder NFC connector there is a mystery connector. Future extension devices can be connected to this. Cannot tell you what we have in the works for this. But hey, the connector is there. Aluminium buildplate. Not all materials where sticking very well to the glass. A proper aluminium build plate works better for some materials. (Available later) Double the theoretical resolution on X/Y by changing the belt pulley sizes. With the heavier construction, this also gave us the plus of having more torque. Internal power supply. No longer the separate power brick. New improved bed, which is stiffer then anything we did before. Grid based leveling. With the large build volume, our 3 point leveling no longer worked properly, as glass and aluminium plates are always a bit warped. (I think this will be backported to the UM3 as well, but don't hold me on that one) It uses the same PrintCores as the UM3, why change something that works great? One thing got removed compared to the UM3, the frame lights are now only white, no longer RGBW. (The RGBW strips are quite expensive in the UM3, and never really used, which I personally think is a shame, but hey, you win some, you lose some)

It should be relatively easy to adapt the "pause at height" post processor for this goal, instead of height it just has to look at filament usage.

Well, how bad is a small scar on your model compared to a failed print because filament ran out? Yes, resuming isn't 100% smooth sailing, but the current UM3 firmware already does some smart tracking of filament positions to allow material changes during a print and resume as good as possible. As it tracks how far the material is retracted when pausing, and puts the filament tip back at that position when resuming the print. That's generally where things can mess up, filament all the way at the tip, while the gcode thinks it is retracted, you will get a messy result :-) Oh, and you can program in pauses into UM3 gcode as far as I know. M0/M1 should pause the printer in the UM3.

Print time does not scale linear with print volume ;-)

300mm^3 is ~7x7x7mm. But yes, a clever play on perspective, it's actually an UM3go! But if you mean 300x300x300mm => 27000000mm^3, that would mean 3x the volume of the UM3, that would be crazy! Right?

On the machine it behaves like that. Cura has a good flow rate per extruder (pretty much a requirement for perfect dual material prints)

There is no UX reason. It's actually tracked as a bug in our system. The reason is legacy, we are still building on top of the old Marlin which does not support flow rate per extruder. Priorities prevented it from fixing it so far.

You can get all the warp speed you want at http://emptyepsilon.org (shameless plug) Also note that dilithium is an actual thing, but it's just 2 lithium atoms in a molecule. Seeing where it is in the periodic table, between "mr explosive gas" and "mr I look like metal but will burst into flames when touching air", it won't do you much good unless you want to set things on fire. (Yes, I'm a science nerd) On the big news, we are obviously finally launching our lawnmower.

Problem was that dilithium was very difficult with legislation, being an accidental space-time warp risk. So we removed that feature last second.

I have no experience with node-red. So I cannot help you on that part. I did post a python example in my topic about the API, that might help? But the UM3 API requires HTTP Digest with "auth" quality-of-protection. (The Digest standard makes this optional, but that completely ruins the security, and thus we made it required) most libraries handle this seamlessly. Part of the "auth" quiality-of-protection are one-time-use tokens, called "nonce". Which I'm not sure if node-red is handling for you or not.

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.

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.

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.

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"'

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.

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.

A job name is read-only

For remote control, you don't need developer mode. You need to access the HTTP REST API.

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.

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.

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)