robinmdh

I would expect values less than an ohm or so but as long as your meter sees a stable connection I would assume it's OK... it is fine to lay the printer on it's side. while printing with the printer on it's side is not recommended it does not matter to the electronics or the motors, etc. just be sure to work EMC safe.

when you unscrew the bottom of your printer there is another one of those big connectors, it's easy enough to find and only logically plugs in in that one place. But even if you measure them and the connections are all OK, there might only be a break when flexing the cable. You could clean the contacts (for instance with alcohol on a cotton swab) re-insert and see if that helps.

The i2c head communication error really does point to the cable, since that is only reported if there is no connection to a chip that is on the PCB in the printhead, regardless of temperature errors, etc it could of-course be a combination of things, but that seems less likely.

Thanks for the logfiles! (the ones in the e-mail) Using the logfiles I was able to see a bunch of i2c head communication errors, so my thoughts go to the cable between the printhead and the printer. I think either the cable is broken or it's not plugged in properly. I can further support this conclusion because over the last few days I found A bunch of probing errors and min and max temp errors. The reason for those are all related to the printhead, the printcores, etc. the only thing all of those have in common is the cable from the printer to the printhead. Assuming there is an intermittent break in the cable you should be able to get a replacement from your reseller. I'm not sure how this is handled though if you will have to install it or it they will, etc... If it is just not plugged in correctly/you want to check that yourself/if you have to replace it: There is a retention clip/part on the printhead that needs to firmly grip the cable, this may have slipped or the cable may have broken. you can remove this by removing 2 (long) screws from the printhead, make sure the cable is firmly plugged in and not sideways. if in doubt about the cable retention you can put a bit of tape around around the cable but this shouldn't be necessary, then close the printhead back up.

Another explanation is that it changes more. It did also change the PID settings for heating the buildplate (5 to 10 degrees constantly off target depending on whether it's heating or constant) which won't help you if you don't know about it but yeah it would solve some issues. But just bringing it back as is sounds not great either IMHO.

Could you also add the files that are called something like: ultimakersystem-ccbdd300129b.3.7.7.20201017.boot-0.log.gz? Those are the main log files. (the forum might complain about uploading them if so you can unzip them with tools like z7)

@dcschooley Thanks for the testing and feedback! /edit after waking up We could certainly not replicate a situation as bad as you describe so it means a lot to hear this from you!

Usually the hotends not heating up is related to the pogo pins between the printhead and the print core, try cleaning up the contacts on both sides and try again. The error is caused by protection code that hasn't been changed in this release. If you still think it's software you can try these steps: If you have any materials loaded try to unload them first, possibly do a factory reset, and then try again. If that fails you can downgrade to 5.8.1 via usb, here are links to the files, only one will work but select the R1 only if there is a robot on the side of your printer. http://software.ultimaker.com/releases/firmware/9051/stable/5.8.1/um-update-5.8.1-R1.swu http://software.ultimaker.com/releases/firmware/214475/stable/5.8.1/um-update-5.8.1.swu If none of that solves anything logs will be super appreciated! (you can dump logs to usb, though if you had a usb stick in the printer at the time of the error that will already have happened)

Usually the hotends not heating up is related to the pogo pins between the printhead and the print core, try cleaning up the contacts on both sides and try again. The error is caused by protection code that hasn't been changed in this release. If you still think it's software you can try these steps: If you have any materials loaded try to unload them first, possibly do a factory reset, and then try again. If that fails you can downgrade to 5.8.1 via usb, here are links to the files, only one will work but select the R1 only if there is a robot on the side of your printer. http://software.ultimaker.com/releases/firmware/9051/stable/5.8.1/um-update-5.8.1-R1.swu http://software.ultimaker.com/releases/firmware/214475/stable/5.8.1/um-update-5.8.1.swu

Trying to remember if that made it into the release, I think we found that the ER998 was fixed, but there could obviously be another reason that specific material failed to load and at least one possible reason did not make it in. I'll check in the morning whether I am right about that. /EDIT @spsid13 checked and confirmed, the ER998 with material loading from cura was fixed in the 5.8.2

We've found a bug in the "print one at a time" feature if there was a preceding print, in that case only the footprint of the previous print is used, not the whole buildplate as it should have been, this was fixed in version 5.8.1 in that case there is also a workaround by turning the printer off before starting the one-at-a-time print. We've further added error reporting to that warning (as well as a lot of other warnings). so that we can monitor occurrences and fix the issues.

The UMO printer only prints via SD card or USB, it can't be used via the digital factory. Are you sure you have an Ultimaker original? (it's has a wooden frame).

I think you might have a corrupt USB stick or download is most likely but your firmware is quite old so you might want to use the recovery image to cleanly install the version you want. have a look here: https://support.ultimaker.com/hc/en-us/articles/360011587199?download=%2Fen%2Fresources%2F23129-updating-the-firmware and alternatively you can get https://software.ultimaker.com/releases/firmware/stable/5.2.11.20190503/recovery-5.2.11.20190503.img and follow this guide https://community.ultimaker.com/topic/20024-recovering-a-bricked-um3/?do=findComment&comment=19989

Nope it's not normal, try rebooting the printer and let us know if you get stuck again!

I think we still don't have much data about this because I've gotten files that should have this problem print fine, and it happens with network prints and UFP files as well.... I though we'd already see this via sentry but nope... I'll add a way to log it to sentry, I think that's the only way to catch it in the act so to speak. it'll take at-least 2 new version at the earliest to have a fix for this problem but maybe the fact that this is really hard to find/reproduce and it's being looked at helps a bit 😕 BTW we've started using a tool called sentry to collect data on crashes and exceptions like this. it's been super useful in finding things we never saw happen but were, clearly happening to a few people out there.... the first sentry inspired fixes were in the 5.7.3 release.

We've had a local queue and print management for quite a few years now it was first called cura connect now it's called digital factory but pausing, aborting and checking the camera has been there for most of that time, it's only limited to the local network. The Cloud is quickly catching up to those features though so don't worry.

you can also set the nozzle offset in Cura (and presumably simplify3d as well) that is generally what was done for the early dual hotend setups, not very pretty, I know. the M218 should also work though. switching back and forth with the stock implementation every layer however is not recommended. it rounds floats every-time you switch AFAIK. We replaced it for the UM3 because we did use that offset for the Z but the buildplate was slowly creeping up or down when we did switches in places to test the switching bay.

Unfortunately I don't have any UM3's at home to test with (COVID) but if you feel adventurous you can try this package, just enable developer mode (then you can ssh into the machine with the user: root and password: ultimaker), scp (or winscp) the file to the /root/ directory and install with dpkg -i jedi-display*

For the UM3 you mean? It does take double the roll amount to roll over to the start vs to roll to the next item. we did considered this, decided against it because of some fairly long menus and if I remember correctly it should be easy to change but we haven't planned to do any more UM3 software updates at the moment. I suggest printing a custom knob for the printer control, that makes it a lot more controllable IMHO. https://www.thingiverse.com/search?q=ultimaker+knob&type=things&sort=relevant I used the 2nd one in the search result myself, did have to scale it down a tiny bit, or maybe print with the new engineering profiles?

Good to hear it hasn't happened again! It's odd though, no changes on any of that code in the 5.7.2 -> 5.7.3 change. I wouldn't want that to happen to anyone, If you can send me the logs and gcode or UFP file I'd be glad to take a look and make this doesn't happen to anyone else.

XY calibration is indeed stored for a position locked pair of print-cores. But this almost looks like the 22 mm difference Cura inserts between the positions isn't there... The max the calibration can handle is 2.9268 mm around a center position so + or - 1.4634 mm. To even begin to debug this I'll need more info, like the firmware version, the gcode file and the files duped to the USB stick when you select the dump logs to USB at least.

not sure if this helps but my atomic/cold pull's do look different, way less stringy, this might allow gunk to stay on the sides of the nozzle. The whole tip should be straight and not thin immediately behind the nozzle, I suggest you wait a bit longer before you pull back to allow the temperature to stabilize or do the pull a bit colder untill it comes out like this. or review https://support.ultimaker.com/hc/en-us/articles/360011620800-How-to-perform-a-hot-and-cold-pull again. Alternatively if you have polycarbonate filament on hand, use that, the temps are a bit higher but it sticks a bit better to the whole mess, and is a bit stronger so it can more easily handle the cold pull forces.

Yes, the API extracts the white component from the hue / saturation / brightness and sends that to the white LED's allowing the RGB LED's to do less; So changing the saturation should have an effect on the white brightness, setting the hue should only have an effect if the saturation is not 100% or 0%, yes. you do need 24V RGBW led strips like these: https://www.superbrightleds.com/moreinfo/flexible-led-strip-lights-color-changing/5m-rgbw-led-strip-light-color-changing-led-tape-light-12v24v-ip20/5151/?replacement=1572 Most stips I find are the individually addressable ones these days.

so did we when implementing the initial version of the digital factory, UX voted against this because it was harder to procure color LED strips that where properly white balanced so with the next printer they went with more consistent but only white LED's. It depends a bit on if you have a S5 with A U on the side or with an ultibot on the side, if there's an ultibot on the side the connector exists and you can just connect the led strip, AFAIK. the connector is marked as P3 in the schematic, you would have to find a common anode RGBW led strip (4 chanels of RGBW and one for the positive voltage) If you have an U on the side it gets more complicated: So the led strip used I2C but sending commands to it would be disabled in the S5 firmware. look for the ledRGBWUpdate function in the marlin firmware, this part of the software is open source and you should be able to request a copy from support! if you can get a similar PWM chip you could enable it https://github.com/Ultimaker/Ultimaker3/blob/master/PCB files/1548-I Ultimainboard/Schematics and layout pdf/Schematic Prints.PDF shows we used a PCA9632DP2 IC. you can connect it to the I2C lines via the cables going to the flow sensor, but that would likely not do for the current/voltage you need. Anyway this would require soldering, connecting IC's and some transistors etc. TL;DR Yes you can plug in a RGBW strip, but only if you have an ultibot on the side of your printer iso a big U.

It is already implemented, the cluster API can(if a material station is connected) have a material station section in it's printers API which lists all the slots and copies most of that info from the aforementioned material station API. As is documented in the cluster API interface http://<insert.your.printer.IP>/cluster-api/v1/#!/printers/list_printers it's in the example value but more obvious if you click model, just obove/next to that The error API is also repeated in the cluster API, since everything that is shown in the digital factory(aka cluster, "cura connect" or "ultimaker connect") has to be included in that API because of cross site scripting and page load speed considerations you wouldn't want to get this data from multiple printers in your network directly from the front-end. On a side-note all those documentation pages are generated via swagger documentation which can be found at the documentation url/swagger.json or in the case of the printer api it's docs/api/api_documentation.json so if programming against these API's using the swagger file you can generate interface code automatically if you want. you can also paste them into editor.swagger.io which can give you a different visualization of the API. You can use that same editor to check out the cloud API's you canget the data here: https://api.ultimaker.com/cura/v1/spec and https://api.ultimaker.com/connect/v1/spec