robinmdh

Totally forgot to add instructions, but connect a telnet session to the printer's IP on port 42000 you'll get a whole bunch of data to start off which are all in the format of key\n value\n --- repeat -- after the initial full set of registers you'll keep getting all the changes. you can set registers by sending "key=value\n", there are a whole bunch of led controller registers... have fun. But keep in mind this will be disabled in the future and will then only be available if you enable developer mode.

Something to look forward to 😉, before you get fancy ideas, I doubt the Material station will ever have any blinking or breathing effects, .

@uncle_bob The printer lights are dim-able, via settings -> frame light -> brightness. we intend to make that brightness setting work for the material station as well...

We've been discussing adding an experimental features tab in the settings where you can turn on stuff like this by choice, that might allow us to do things like this but it does mean that the amount of corner cases we have to test rises exponentially... , in the mean time you could try this patch for layer height: The post above was also meant to show you the printer sw is still fairly easy to modify. The patch was not perfect though, now the layers are still shown when the print has finished successfully, etc.

You can also import the material into cura, if it is connected to your printer then upon restarting cura it will sync materials with the printer.

The spool should rotate back during the unloading. Please verify if the roller on the bottom of the bay rotates during the unload. If not you may have a broken rewinder. When you sent a print job the machine will attempt to load the materials you sliced for, so slice for a different material and it will unload the current one first. The matching is exact same type of material. So to stop it from unloading you can use the skip cool down button at the end of a print and then quickly start a print with the materials that are loaded at that time. Currently it tries to unload before you can start a new print, this will also change in the future so that you'll have a window of time to sent a print job with the same materials before they are unloaded.

I hope this was a print head communication error? The most likely culprits (in my experience) are: - the pins in the print head connecting to the printcore are dirty, dust and grease can make this happen, just clean them with some alcohol and a q-tip. - the cable could have developed breaks and might need to be replaced. - the cable can start to move, it is claimed in by the print head but wear can make it start moving. A bit of tape around the cable right where it is clamped could stop this. Given the recent change of printcore after never changing it the first one would really be my bet. Let us know if it helps!

Hence the gently, but yeah if necessary you might have to ope the Bowden tubes there too. @D95 The ER54's most likely reason is that the filament tip was not making it trough the decoupler or into the S5 feeder caused by being slightly bent or cut of flat. https://ultimaker.com/en/resources/52941-filament-loading-unsuccessful-er54 We will definitely be working on makeing guides to get you out of the material station errors. And indeed in the current solution where you are forced to solve the problem and then reboot the printer is not user friendly. Indeed, the moving back and forth is combined with retractions that combined cause the filament to fall off, as a programmer I would have preferred the bucket and flap solution. I too have thought of printing a collection bucket 😁 but this may act as support for the material then causing it not to fall off. The amount of filament purged is about twice the volume that is liquid(ish) inside the core so this ensures fresh material will be used in the print, this is actually super useful with materials that degrade faster. We will be making the purge less in the future as well. It also looks like more when extruded trough a 0.4 mm nozzle. I realise that hearing about future plans does not help you now and they may never be realized, however maybe it helps to know that we know these issues will need to be improved upon. Thanks for the feedback! Don't hesitate to ask questions or share your experiences. We can use that to inform decisions about which bits to work on next. P.S: We do have a long history of apparently useless wiggles, such as the "useless" move at the start of the print which resets the print head switch to a known state. P.P.S: We also have a history of blocking errors that require a reboot to clear, I'm happy that they did not previously show up often and am sorry if they are a bit more prevalent now.

This is intended behaviour bed leveling will start after both materials (if your print uses both) are loaded, in the mean time the buildplate is heating up, so not all of the time is lost on this new part of the print procedure. This purge behaviour is also triggered when you try to change a printcore that was not previously purged and deprimed, the printer keeps track of this and doesn't know that you manually removed the material. There is no older firmware that supports the material station and as far as I can understand nothing unintentional is happening. Have you tried letting the printer continue?

@wessam this issue was specifically about the pulled version, I hope you are not using that version but 5.4.27. If you still have this problem please be more specific in you problem description because we can't help you or fix the problem you are experiencing if we can't reproduce the same problem here.

As long as the filament is loose from the printcore it is fine to gently pull it out trough the material station. Define goes crazy? The purge on the side behaviour is meant to form the filament into a nice tip so it can be pulled back past the printer feeder reliably.

You could consider disabling the prime blob which is currently the default in Cura. But the overall string print makes me think you may have left a BB printcore in there for the silver material, if so try it with an AA printcore.

Basically yes, a GUID stands for globally unique identifier also known as UUID (universally unique identifier). They are randomly assigned in an address space big enough to make collisions extremely unlikely(unless we approach billions of materials). https://en.m.wikipedia.org/wiki/Universally_unique_identifier

Both yes and no. Cura already overextrudes a bit to create a squishy first layer so extra squis is intended. But any error in height is unintended. There are many tiny errors that all add up, we are trying to understand where they all come from so it's likely we will make an update in the future to iliminate this as well as the one caused by temperature differences in the printcore. It will take quite a while though...

You might also have tightend the screws on your buildplate too much. Please first make sure your buildplate bottom to top distance is set to about (I think 14 mm, not at the office so I can't verify this right now), then manually level the buildplate while keeping the total distance close to this number. Then you could try active leveling again.

The use of the material station in the manner you describe is not the intended use case, it was not designed to switch materials that often. The switching would be super slow(due to the depriming which allows the material to still fit trough all the Bowden tubes and couplings after printing) and because you may have 10.000's of switches which will make the likelihood of failures during your print fairly high. In conclusion, doing this every couple of layers would be unfeasible. There is also no way to do so in cura. I admit I could hack some gcode together that does this anyway but this is intentionally undocumented and not selectable from Cura.

Yes, you have to make it a unique type, and unique GUID by editing those fields in the XML, we're probably doing the same thing except that you can get cura to upload the XML files to the printer.

Perhaps this is a bit annoying to hear but have you checked tention on your belts and oild your sliding rods, etc. https://ultimaker.com/en/resources/50678-check-tension-of-short-belts https://ultimaker.com/en/resources/150-lubricating-the-axles https://ultimaker.com/en/resources/50679-check-for-play-on-axles Given that it works on a different printer... I have just done some prints with the engineering profiles on an S5 and they came out fine... That was sliced with the 4.4.0 beta, not sure if that matters.

Any material profiles you have in cura get send to the printer when it's connected via network, restart cura to trigger this. You can just import you material profile into cura, no need for 3rd party tools. If I make an export of an existing generic material, edit the name and type and GUID!, and import that material again then restart cura, wait a moment and I can select the new material... The software does check if you have all the info for the material station and that info is subject to change still, if you get ER64 then you should get your base material profile from the http://github.com/ultimaker/fdm_materials repo.

A small new years gift for the tech savvy out there, with an Ultimaker S5 or S3. A patch with layer count/total below the time remaining. NOTE: this is not coming from Ultimaker officially, this could brick/break your printer, no guarantee is given on these steps or this file, while this is likely to work with a bunch of versions I've only tested with newer than the recent release. And if there are any complaint I'll of-course remove this immediately. Steps to enable: enable developer mode. in config -> settings -> Developer mode login via ssh or putty as root, the password is "ultimaker" (if this is new to you then maybe don't try this). Run: wget http://robin.den-hertog.org/patch.sh Run: bash patch.sh The printer should then reboot. If it doesn't reboot then it's likely the patch failed to apply, maybe you need to update to newer firmware, You don't have an S5 or S3 or I made a booboo, let me know 😅. I strongly advice you to turn developer mode off again, it makes the printer very unsafe! Then While printing you should see something like this:

you're not the first to want this, out UX designers have judged this kind of information to be clutter and they have a point. You can get the z height from the API here: http://<printer ip address>/api/v1/printer/heads/0/position may I direct you here for more information and discussion?

That feature is still planned, not implemented yet 😢 If you're super handy with telnet/programming and want to spend some time on it I could tell you where to look to make a work around but the technical expertise required is fairly high.

happy holidays, After the vacation I'll be sure to discuss this between the 3 printer firmware teams. Though I don't think it will be all that easy, putting a max on the probing temperature is not difficult but between all the different materials and wanting to be able to push trough blobs left on the nozzle from the current or a previous material without destroying any adhesion aids might be tricky. I do agree that it's a shame we can't keep the hotends heated during all of the probing. Though if the cool-down of the metal from the hotend influences the leveling position significantly we could also compensate by calculating the lost expansion due to the temperature difference.

we were actually talking about removing this recently, it skips waiting for the deprime(and purge if you have a material station) which is the intended behavior, and is meant to get you ready for the next print ASAP. it would work quit well in the 5.5.x version but is broken in 5.4.x we are aware but people keep telling me nobody uses it.... so the option to remove it is a serious possibility. I use it quite a bit so I'll use this to argue to keep it, if you don't mind. We may need to rename it though... Look, the machine wasn't build with buildtak in mind, sorry, sad to hear it's a problem. The" build temperature initial layer" setting in cura might help but for the rest, it is just not designed for that and buildtak may cause the bed leveling to be off as well., the leveling method requires a lot of assumptions about the surface of the buildplate, change those and it is unlikely to work as well as you might otherwise expect. I use dissolved old PVA for adhesion, 3d lack/hairspray also works great or use a glue-stick, but add anything 3rd party to the mix and you are likely outside of designed for specs... Higher reliability vs ease of use is a very difficult decision to make, what appears unnecessary may actually serve a purpose, which just isn't obvious (like resetting the nozzle lift switch) or why the heaters appear off during leveling (interference with the sensor) etc. but we do have some stories planned for this, if you could be more specific that might help. but then I'd suggest a video where you indicate the slow/useless bits and precise version numbers and any preconditions like you did a print before that you aborted, etc.

they contain both. here's a sample probe point from my printer, there are 2 reset points which have more measurements to determine the approx buildplate location/nozzle difference and the resulting grid as well as the raw sensor data per probe point: { "_ProbePoint__raw_sensor_data": "7.15250 4981 0\n7.15000 4981 2\n7.13000 4978 2\n7.11250 4982 12\n7.09500 4982 9\n7.06500 4988 9\n7.05500 4987 14\n7.03500 4988 6\n7.01500 4992 10\n6.99250 4997 10\n6.97500 4999 10\n6.95500 5001 10\n6.93500 5002 10\n6.91500 5005 10\n6.89500 5004 9\n6.87000 5010 10\n6.85500 5011 14\n6.83500 5013 6\n6.81500 5014 10\n6.79250 5020 10\n6.77500 5018 12\n6.75250 5023 9\n6.73500 5028 10\n6.71500 5027 9\n6.69500 5029 11\n6.67250 5033 9\n6.65500 5036 12\n6.63500 5038 8\n6.60750 5041 11\n6.59500 5041 14\n6.57750 5042 5\n6.55500 5047 10\n6.53750 5050 10\n6.51750 5054 10\n6.49500 5057 10\n6.47500 5061 10\n6.45500 5059 10\n6.43500 5060 10\n6.41000 5064 11\n6.39750 5068 12\n6.37750 5071 6\n6.34750 5075 11\n6.33750 5077 15\n6.31750 5080 4\n6.29750 5084 10\n6.27750 5085 10\n6.25750 5089 11\n6.23750 5093 9\n6.21500 5098 10\n6.19750 5098 12\n6.17750 5099 9\n6.14750 5105 9\n6.13750 5112 15\n6.11750 5110 5\n6.09750 5112 11\n6.07750 5114 9\n6.05750 5121 10\n6.03750 5120 9\n6.01750 5126 10\n5.99750 5129 12\n5.97750 5133 9\n5.95000 5134 10\n5.94000 5139 14\n5.92000 5141 6\n5.89750 5148 10\n5.88000 5148 10\n5.86000 5150 9\n5.84000 5154 11\n5.82000 5158 10\n5.80000 5162 9\n5.78000 5166 10\n5.75500 5168 11\n5.74000 5175 12\n5.72000 5173 7\n5.69000 5178 10\n5.68000 5181 15\n5.66000 5183 5\n5.64000 5182 10\n5.62000 5182 10\n5.60000 5182 10\n5.58000 5184 10\n5.56000 5185 10\n5.54000 5186 11\n5.52000 5187 8\n5.49250 5178 11\n5.48000 5179 14\n5.46000 5181 6\n5.44250 5185 9\n5.42250 5183 11\n5.40250 5188 10\n5.38000 5189 10\n5.36000 5192 10\n5.34000 5189 9\n5.32000 5190 11\n5.29750 5192 10\n5.28000 5193 12\n5.26250 5188 8\n5.23250 5190 10\n5.22250 5196 14\n5.20250 5194 5\n5.18000 5184 10\n5.16250 5183 12\n5.14250 5185 8\n5.12250 5187 10\n5.10000 5180 10\n5.08250 5180 12\n5.06250 5179 8\n5.03500 5181 10\n5.02250 5181 14\n5.00250 5182 6\n4.98250 5185 10\n4.96250 5184 10\n4.94250 5188 10\n4.92250 5191 9\n4.90250 5189 11\n4.88500 5197 10\n4.86250 5203 9\n4.85500 5203 11\n\no6D0F40", "_ProbePoint__date_time": 1576776924.1612086, "_ProbePoint__bed_temp": 58.79841636258285, "_ProbePoint__location": { "_Vector2__x": 106.5, "_Vector2__y": 173.5 }, "_ProbePoint__z_offset_from_bed_zero": 5.643527916746965, "_ProbePoint__nozzle_temp": 156.9 }, This is repeated for each point probed. We don't necessarily probe the whole grid though only if something is printed above that section. while it is still just a raw chunk of text the first value on each line is z the second is the raw sensor reading, the 3rd I don't remember at this moment (could be the checksum but could also be some internal value ). The main point is well received and understood, but we'll have to do extensive verification on multiple printers before we make a change. Maybe we could make a change to have it configurable in the json config files on the printer in the sorter term but putting this on the UI is just not my decision.