robinmdh

NOTE: this is just my opinion and may not be shared by ultimaker... While not explicitly open-source, the S5/S3 UI is completely written in qml and python with pyqt so, you can mod it Note: this only goes for the S5 and S3, the UM3 display is compiled C++ code that is not open. The information is in the procedure metadata of the print procedure. so you need to change the __updatePrintJobState(self, printing_state) in the /usr/share/okuda/components/progress/component.py and add extra properties for the layer_nr and the layer_total, which you can then use in the /usr/share/okuda/components/progress/PrintProgress.qml there you can then use the component.<whatever you called your @pyqtproperty> put those in some label and done... Distributing diffs should also be OK ,since you don't have the rights to to code but you do have the rights to your additions, the rest could fall under the sample laws... so I would deploy your software as a patch on an existing version. If you do please also post-fix the version number in /etc/jedi-version with your fw name so that we can see it's modded 😅 but as @CarloK said our UI designers don't like clutter such as layer numbers. Which I think is understandable since layer counts are not useful in estimating time or showing progress, just imagine printing a pyramid or an Eiffel tower; Our progress and time estimates are better for that. Neither are they needed for an additional action like placing a magnet inside a print, you can just use the pause at height/layer# post processing plugin in Cura.

Perhaps you could check the cable between the air-manager and the printer and power-cycle the printer? or maybe @SandervG has more info? /edit/ The error diagnosis page https://ultimaker.com/en/resources/52955-air-manager-fan-is-unable-to-rotate-at-the-desired-speed-er86 has changed to ER86 though, so maybe this helps? I thought it was also triggered by a bad connection though, hence, check the cables as well.

bed leveling (at least the single probe concept) was explained here: The probe logs are saved on the printer in: /var/lib/griffin/probe_reports_* so if you enable developer mode: That way you could have a look at the raw measurement data. One of the problems is for instance blobs at the end of the nozzle which the leveling then has to push trough, changing the curve, this and many other unpredictable influences and differences between printers do make this a difficult problem. And like @tinkergnome said it then also influences buildplate adhesion which is very important as well. As far as I'm aware there is no constant set to change the height.

It will depend on your hardware the UM3 did have RGB leds but due to not using them in the user experience design they may have been removed from newly produced units. the code you have should work, assuming you logged in as user ultimaker to ssh on the printer in dev mode... sendgcode M142 r255 g0 b0 w0 should work... and show up very red... The HSV values can be used with the API, there is a software layer translating this, via gcode it's always been RGBW though

The air-manger measures the temperature, and if it has a "target build volume temperature" it does determine rotation speed based upon that temperature, but like @SandervG said: A safety feature to not melt any prints unintentionally, if not target build volume temperature is given(by the print-job): 100% on is the decision, at least right now. But I'm working on the material-station so I'm not the expert on the air-manager. Though I've never fount the air-manager to loud apparently my colleagues disagree so my tolerance to noise may be a bit off the norm... Good info from @SandervG

Because we can't stop people from putting air-manages on top of pro bundles, and when you have an air-manager and it doesn't spin it's not good so it was either a partial release, longer wait, etc now if you use the latest Cura it does throttle down the fan. 2 teams have been working on this, one dealing with the air-manager and the other one with the material station, both are high prio.

NO The air-manager goes to 100% whenever hotends/buildplate are hot, unless you are in a print that is sliced with the newest version of Cura. This is simply a safety feature. so @kotsoym's initial video is at least explained. The hot plate warning just pops up if the buildplate is above 60 degrees. It itself doesn't change anything, it's just informative.

The 5.4.24 is now online... This has a first version of the air-manager support but is more focused on the material manager... That took a while and some effort.... I hope we didn't break your particular workflow 😄

I have never seen problem 1, except when a print is running, or the buildplate still has to be cleaned, could that be the case? Problem 2 will be fixed in the next release, we did also pull the 5.4.x update for unrelated reasons so you could go back to 5.2.11. This might also be a fix for you @geetee ?

Indeed there were some problems with it, mostly with regards to print quality. Basically we're working very hard to release a new version... In the near future 5.4.x will introduce material station and have incomplete support for the air-manager. Then in 5.5.x we will have the pro-bundle fully operational. These releases are currently at the testing stage, but this may still take a while depending on what the findings are.

you can unbrick the firmware and flash a new rom into it using these guides: or 567519794_WorkInstructionsUltimaker3firmwarerecovery.pdf if you want to change the software on the printer manually you can also just log in via SSH look up @Daid's "inside the ultimaker 3" set of topics. You can just install software via apt if you apt-get update first, this data should not be stored after reboot but whatever you installed is still be there. I hope that helps @TheodorK

As @ultiarjan said, the UM2(+) and UMO are completely open source. Though I'd like to add that: The python code running on the UM3 S5 and S3 is readable/writable. If you enable developer mode you can log into the printer and gain access. The UM3 display is then the only exception, the S5 and S3 display use plain readable python and qml for the display as well. I was also given to understand from some of the support members that if you have the UM3/S5/S3 and request the open source code you'd get more than just the marlin code. The marlin code is most definitely open source and available upon request. A lot of the parameters you might want to change in the UM3 are in configuration files so depending on what you want to do it might be easier to modify this in small ways. look in /usr/share/machines/um3.json and related files in that directory on the UM3/S5/S3 for some examples. but for instance the steps per unit (a unit being a mm of motion) can be easily changed if you changed your feeder for instance.

Discussed with @CarloK While the XY calibration does re-calibrate for the smaller nozzle the print still happens with a static layer height, maybe the max mm/s that is pushed trough the nozzle is exceeded causing grinding. I could generate the gcode for the XY calibration with a smaller layer height, would you be willing to test that?

Missed that SD card bit indeed 😅 While the we are still making bugfixes for the um2(+) I don't see time for new features likely. Have you tried @tinkergnome's tinker firmware? It has a bunch of features the regular firmware does not, if it doesn't already have that feature someone might be able to add it.

So if you abort a print the UM3 and S5 have a retry option at the end of the print. And the Cura connect print queue software (running on the same printers) has a list of old prints you can duplicate. Does that help?

Have you done a cura connect reset on the printer? There is no official PPA AFAIK so this is out of our control, we can't make old software magically do new tricks. Please use the AppImage version provided for Linux. (and yes try doing a cc reset)

never mind.... It seems silly that I can't delete a post, but I was incorrect.

Of course you can more easily set some pins to create a short circuit and doing so would be unintended use and the damage caused would fall outside of warranty.

It will still abrade the printcore and ooze a bit more but the wood fibers have an easier time being pushed trough the nozzle and I have less clogging especially at higher temperatures (to create fake wood nerve/layering) as the nozzle does not have a flat bit just before the exit. | | | | AA \ \_ _/ / \__| |_/ | | | | BB \ \ / / \ \ / / \_| |_/ Perhaps this ASCII art cross section illustrates the difference in internal geometry. So the BB core is intended for materials that do not easily flow trough that flat (even if the hole is the same size), while the flat does a lot to prevent oozing, it's a trade off.

Some phone providers make it just as easy, and the user still gets access to the root(administrator) account of the device, so rooting is what it literally is. Ultimaker provide the tools and instructions (on this forum) to "root" the printer that makes it even more questionable to hinge warranty on that IMHO. I have no idea what Ultimaker's official stance on this is so I'm sticking to quoting fact.

A) you'd have been warned (in Cura by a yellow color, in the printer by a line saying it is not recommended) B) it works fine and it is even advisable to print wood-fill PLA with a BB core for instance. The one thing you shouldn't do is put PVA in a AA core. this quickly makes the core clogged beyond recovery. (*barring drilling the gunk out which damages the core) the PVA flyer with your printer does specifically mention the BB core. At least it is listed correctly on the website: Swappable print cores Faster print core changes mean higher uptime and easier maintenance. Your Ultimaker 3 comes with print cores for build (AA) and water-soluble support (BB) materials. The app can monitor the printer remotely already but it only gets events such as print finished, aborted or started. not a camera stream, the cloud solution we are working on (I think we have 1.5 dedicated cloud engineers in a SW department of 40-ish people testers/developer/product-owners working on firmware connect, Cura, app and cloud) includes slicing in the cloud and sending prints directly to the printer from anywhere. AFAIK no remote camera stream. so that depends on what you mean by monitoring. And yes @kmanstudios this is forcing us to implement better security everywhere connect is currently completely without security this will have to change. Great to hear, and improving this is indeed out focus at the moment!

I would compare this to rooting your phone And well as far as I know it's just not legal to consider changing the software as breaking warranty. Then again I'm a software developer not a lawyer...

If it helps it would for instance be very easy to expose the current and total layer counts via the printjob HTTP REST API the same way progress (0 to 1) is currently exposed here: http://<insert.printer.ip.addr>/api/v1/print_job/progress BTW: There already is a way to view the current Z height during printing: http://<insert.printer.ip.addr>/api/v1/printer/heads/0/position/z

We're working on that, currently there is some divergence.

I've never had this problem with Ethernet, I would suggest doing the factory reset as it should be the default after that if you then skip the wifi setup. You can always make an impromptu mini lan with a router but indeed you can also plug your laptop into the printers Ethernet port cross cable (though most modern computers can use a normal cable) directly or use a hub/switch and the printer should come up with a link local ip address, https://en.wikipedia.org/wiki/Link-local_address these start with 169.254.x.x depending on your computer you might have to configure an ip in the same range but most systems do support the link local protocol, it just takes a bit more time. That way you can also find out the mac address. Though I thought the mac address was also in the networking menu (I just checked the code (as I don't have an S5 present) it shows the mac address of the active connection though so you need to set it on Ethernet first), so yeah that would be the simple path. I Had no problems with the first run wizard it is a bit restrictive(requesting specific materials) but you can do the steps you want and then skip everything else. If you really can't get networking to work you could also get a serial cable there are some instructions from the olimex folks that explain this. NO! What you seem to want is not a simple setup, changing the steps per unit by re-compileing marlin and putting that on the printer is more complicated, this is changing one file on the printer. I only mentioned this as an alternative to that.