rachael7
-
Posts
160 -
Joined
-
Last visited
-
Days Won
6
Content Type
Forums
Events
3D Prints
Posts posted by rachael7
-
-
58 minutes ago, TimonR said:
Could be worth looking into support floor settings to see if you get better results?
Specifically look at support bottom distance and support floor settings, those should influence adhesion of aquasys on PC.
Thanks for the reply. Yes, that is the trouble I'm having, the same as you found. I did adjust support floor settings, quite a bit. Bottom distance=0, support floor density=100%, support floor pattern=several tried, support floor flow rate=110%, AquaSys temp=245-255. The best I managed was tenuous adhesion that fails before the part can finish. Any other thoughts? Thanks again!
-
Thanks, Smithy. I know it is a clean solution. I was just trying to figure out, if the glass was warped or something, if I'd be back to iffy first layers without the mesh leveling. But I guess if you're getting good results, it can't hurt to try and see. I definitely need to redo the 3 point leveling first though - I haven't done that since I got the machine 2 years ago!
-
Thanks for making this utility available, Smithy! It has saved me a ton of time, thank you. One question though - if we disable the active leveling, does the machine use the measurements from the last probing or does it ignore the mesh and revert to only the manual 3 point leveling?
-
1
-
-
21 minutes ago, Bunnyman21 said:
I would imagine that the remaining filament would be incorrect?
You are correct, of course, and I feel a bit silly for not thinking of that. Dang, thought I had a solution. Oh well, I guess it’s either live with fussy reading or respool onto empty Ultimaker spools as you are doing (where it will only be slightly fussy).
-
Okay, so I've got to scream a little bit here and request, firmly and with all due haste, that the workflow for failed/aborted prints on the S5 w/material station be seriously reworked. Allow me to give a use case/example of the issue. User is printing with UM Polycarbonate or Nylon, which as you know take a VERY long time to heat up because of the 110-120C bed and 250C+ nozzle temperatures. One challenge with these high temp materials is that the nozzles often ooze a bit during the heating cycle that occurs immediately prior to bed leveling and that ooze, if not wiped off, can (and often does) cause a bed leveling failure. Manually wiping the nozzles during startup is problematic already, both because the operator should not have to babysit the machine that closely and more importantly, because wiping the nozzles requires opening the door and letting the chamber cool off, which risks ruining the layer adhesion at the beginning of the print. That point aside, if the operator misses the moment to wipe the nozzles (there's only a few seconds when the nozzles are hot enough before the leveling begins), here is what happens:
1. Leveling fails because of material on the end of the nozzle(s), print head returns home and bed lowers
2. Message appears on-screen alerting the operator to the error, with a button to acknowledge the message. The operator presses the button.
3. The machine cools the print core(s), does the special end-of-print pull(s) to put a point on the filament(s), and completely rewinds the filament(s) back onto the spool(s)
4. The machine cools the 110-120C build plate down to 60C and presents the end-of-print message to confirm the build plate is clear. The operator confirms the build plate is clear.
5. The machine homes the head and build plate and presents the message telling the operator the print was aborted and asking if they want to retry. Operator selects 'yes'.
6. The now-cool build plate begins heating again, the filament(s) is(are) fed all the way back in from the material station, and the cycle starts all over again, while the operator curses furiously and hopes they're quick enough to catch the ooze at the right moment next time.
That whole cycle takes close to 30 minutes with high temp filaments!
Now consider that situation more closely. Immediately upon failure of bed leveling, the machine knows full well it hasn't printed anything yet, because it did not even complete the leveling, so the build plate is clear and does not need to be cooled to release a print. The machine also knows there is a good possibility the operator will want to try again, especially when it stopped for failed leveling and not a manual abort, hence the presentation of the option to retry. Since the machine knows the operator might want to retry, it also knows there's a good chance it might not need to unload the filament. Knowing all that, why not the following workflow instead:
1. Leveling fails because of material on the end of the nozzle(s) or some other reason
2. Print head comes to front center and bed lowers halfway. Print cores come to standby temp and bed is kept hot, at least for 5-10 minutes to give the operator a chance to reach the machine. It could time out after some reasonable amount of time and revert to current behavior then.
3. Prior to timeout, a message appears on-screen alerting operator to the failure and asking if they want to retry.
4. Operator selects yes to retry.
5. Machine presents a message saying "Please confirm the bed and nozzles are clear/clean before proceeding", along with a button labeled "Proceed" or something like that.
6. Operator cleans the nozzles and bed, and presses the confirmation/proceed button. The machine returns to work.
With the bed hot and the cores at standby temp, it only takes a minute or two before it can try again! And it saves unnecessary loading and unloading of the filaments, preventing the possibility of jams and load failures, as well as saving wear and tear on the machine.
There are other use cases where the workflow is very similar and equally cumbersome, such as when the first layer fails or the operator aborts when they realize the settings are off, and a very similar workflow could be used. The only difference would be that the operator likely would have added a new print to the queue with changed settings. In cases like that, the machine could check the queue, and if the same material(s) is(are) being used, it could keep the bed hot and the nozzles at standby until the operator confirms the bed is clear and the next print could begin immediately. That workflow would require allowing the operator to clear the build plate while it is hot, but we're all adults here (seriously, how many children are using a $10k printer) and there are plenty of ways to clear the bed while it is hot without hurting yourself. It could at least be enabled as an option, with appropriate warnings, disclaimers, and whatnot, a "pro" mode if you will.
Even if you're too concerned about the liability to let the operator clear a hot bed, you might at least consider the first case I presented where the build plate at most needs a little scrape to clear off stuck bits from the previous bed leveling attempt. It literally just took me over an hour to run a 10 minute print because twice in a row I missed the tiny window of time to clean off the nozzles. And that is with me having overridden the hot bed interlock through SSH so it didn't even have to wait for the bed to cool off. In the factory configuration it would have taken 90 minutes or more! Please, I'm begging you, find a way to improve the workflow on abort cases. I love this machine, but as a user of engineering filaments, it is not at all uncommon for me to abort prints for one reason or another, and I'm losing so much time to these workflow issues, I'm ready to scream. I'm a consultant who charges by the hour and this abort cycle time issue is literally costing me thousands of dollars a month in billable time! Thank you very much for your consideration.
-
1
-
-
Like Gero, I had no end of problems with the UM PVA breaking in my S5 w/Material Station. It was near constant, probably every 2nd or 3rd print. After countless jam clearing, 3 disassemblies of the material station, a dead pre-feeder, switching to the fine knurl feeders, and more cursing than I care to think about, I finally tossed two sealed rolls of it in the trash - it was that bad. It prints nice, when it doesn't break, and it dissolves nicely as well, but it takes so much extra work to deal with the stuff and puts the machine at so much risk, it really just isn't worth it. I'm honestly surprised UM hasn't changed the formula to soften it up on the spool, given the massive number of problems people are having with it. I switched to the BASF brand BVOH, and like Gero, I find it does everything you would want it to do - it just works. Yes, it is more expensive than the UM PVA, but it has more than paid me back in the time and frustration it's saved. I make my own NFT tags for the spools, so they are recognized in the material station just like any of the UM materials and I just couldn't be happier with the change.
-
I tried the WhamBam smooth plate and even with PLA, the hot nozzle damaged the PEI on bed level probing. I tried their textured plate next and that one works a treat. It makes a nice texture on the bottom of the part and doesn't seem to be suffering any damage from the bed leveling. I do tend to use a bit of Z offset (with the Cura plugin) to increase the squish a bit, typically about 1/2 the thickness of the initial layer, and I run the bed around 80-85C; but otherwise, it's plug and play, and very useful for PLA and maybe ABS. I don't use it on anything hotter than that though.
-
1
-
-
I'm working on some parts with both large, low complexity areas and small, detailed areas, so I've been working with the Small Feature Speed setting to help me get the right speeds in both parts of the model. It's been generally working well, but I noticed today as I was previewing a part in the speed view mode, that the part infill is not respecting the small feature speed. In other words, even though the area of infill falls well within the Small Hole Max Size setting I gave it, the infill prints at the normal infill speed and is not reduced by the Small Feature Speed setting. Similarly, the support is entirely unaffected by the Small Feature Speed setting, both in the walls/infill, as well as the interface layers. Since I'm making a big part that is mostly low complexity, I really need to use large nozzles, and that makes it even more important to get the speed down on the tiny features so that it has a chance of printing well. I realize this is an experimental setting, so not fully supported, but I've come to depend on it and I'd love to have it fully functional. Is this exclusion of the infill and support from that setting a deliberate choice or a bug in the experimental setting? Thanks!
-
Has anyone tried using two NFC tags 180 degrees apart on the spool? I'm finding that the tags read very consistently, but only when they are within the area of the dividers (where the antennae are). So if the filament isn't cut off at the right spot, it is awkward to hold the spool with the tag in the antenna while simultaneously getting it into the pre-feeder. I was just toying with the idea of using two identical tags so that one would always be in, or at least close to, the antenna area. Would having two of them confuse it? Given that it never seems to read them when they're not in the antenna, I'm guessing no? Thoughts?
-
Did you ever sort this problem? I'm not having stringing issues and my material has stayed in the Material Station since opening the bag, so I don't think it's a moisture issue, but I just cannot get the AquaSys to stick to the UM Polycarbonate, no matter what I try.
-
On 1/14/2021 at 10:35 AM, jficara said:
I am running into an issue with the AquaSys 120 and Ultimaker PC filament, with the support autogenerated by Cura. The AquaSys 120 support filament is not adhering to the Ultimaker PC
I am running into the exact same problem - the AquaSys won't stick to the PC no matter what I try. I have a slightly different configuration with AA0.6 (3D Solex) & BB0.8, but all the same results. PC (black) is printing great, AquaSys is adhering well to the build-plate and to itself, and the extruded AquaSys looks good (no bubbles, etc). Material is fresh from the bag right into the material station. But the AquaSys will not stick to the PC part and it also seems not to want to stick to the PC of the prime tower either.
The reverse situation is no problem - PC sticks to the AquaSys just fine at the top of the supports and my supported surfaces look good. I just cannot get the support bottom interface layer to stick to existing PC, as happens when support starts on the part. I'm running the AquaSys at 245C, the max listed temp and I've tried reducing the support floor speeds down as low as 8mm/s. I've tried increasing support floor density and tried different support floor patterns (concentric, lines, etc). I just cannot get even the smallest dot of the AquaSys to stick to the top of the PC.
This is super frustrating, as outside of this issue, the material works really well. I'm running out of things to try, save for pushing the AquaSys temp up outside of its listed range. My PC is printing well at 275C, so I wonder if printing the AquaSys at something closer to the PC temp might work better. I'm hesitant to go beyond the 245C listed max temp, but other than that, I can't think of anything else to try. Maybe increase the flow rate on the support floor to try to squish it down more? Try to get the chamber temp up somehow (it's running around 40-42C right now)? Anyone have any ideas? It is a material station certified material, so I kind of expected better results - maybe someone from Ultimaker could offer some thoughts?
-
On 8/13/2021 at 7:37 AM, JosR said:
Hi Carla_Birch,
thanks for the code list. Can one reprogram a printcore to CC aswell? does somebody have that codes?
thanks,
KR,
Jos
I would like to know as well. Thanks!
-
This happens to me sometimes when the material is in that ready position, a few cm back from the head. It doesn't reprime the print cores when it is in that position, so any ooze during cooldown or heating up is lost material volume that is unaccounted for and results in an empty head at the start of the print. Bizarrely, on the first layer, it prints the prime tower after the part, so you end up with missing extrusions. I just enable the prime blobs to make sure I've got the heads primed and the problem is taken care of.
-
I had the same issue, through 3 different rolls of UM PVA. I think the material is just unsuitable for the material station. Somebody must be using it successfully, but it sure isn't me. After killing a pre-feeder, clearing countless jams, changing to the fine knurl feeders, and taking the material station apart 3 times to clear really stuck jams, I finally gave up on the UM PVA altogether. I'm using BASF BVOH soluble filament now, along with AquaSys120 soluble for high temp filaments, and all my soluble support jams have gone away. Both print just as well as the UM PVA, too. The AquaSys120 is pretty expensive, but the BASF BVOH is reasonable enough, and given the time and headaches they've saved me, both are well worth it.
-
On 12/23/2021 at 10:57 AM, arj3090 said:
After some researching on Cura and some fiddling around, I may have achieved what I wanted. This entailed creating copies of files, renaming the "aa" to "cc", and editing the AA to CC in the file There are 2 directories:
C:\Program Files\Ultimaker Cura 4.12.1\resources\quality\ultimaker_s5
C:\Program Files\Ultimaker Cura 4.12.1\resources\intent\ultimaker_s5
That will work, but as gr5 mentioned, you will lose it with the next Cura update. You can also cause problems with Cura if you mess up files in those directories. I learned this lesson the hard way, trust me on this one. If you add those files instead to the user directory, they will migrate Cura versions and less chance of causing errors in Cura. You can find the user directory by clicking the Show Configuration Folder option in the Help menu within Cura.
-
I just started using AquaSys 120 support material, and while it is printing well, I'm having major issues with bed leveling when I print with it. I'm using the BB0.8 print core and the AquaSys is oozing whenever the nozzle is hot, even if the material is fully retracted from the core (like right after a print). While the printhead is heating up at the front of the machine, the AquaSys forms a little ball on the nozzle which hardens by the time the machine goes to do its first probe. That is causing the core height comparison test to fail and the probing is aborted. It is being kept in the material station and was dried before going in, so it's not a moisture issue. I tried wiping the nozzle at the right moment as well as making sure everything was clean before starting and I'm just getting error after error. If I do the printhead cleaning procedure on the BB core, the subsequent probing works fine, just like it always does, and all other filaments are working fine, so it is something about this particular material and/or profile that is causing the issue. Right now, it's looking like I'm going to need to do an atomic pull after every print to keep the probing from failing on the next print, and that's just a giant pain in the tush. Anyone else run into this? Any idea for a solution? Thanks!
-
2 minutes ago, Bunnyman21 said:
Hey Rachael, thanks so much for finding and fixing the issue! I hadn't tried using it with the newer Cura versions yet. I have merged your change and applied the fix for MacOS and Linux too. The new compiled version is now on GitHub. Oddly enough, the exe is a third of the previous size, yet seems to still be working (no idea what I did). Please let me know if you find any issues.
Thanks!
Happy to help! And really, it was the least I could do after all the work you put in to make it in the first place. I'll try out the new .exe and let you know if I run into any issues. Thanks again!
-
1
-
-
On 6/22/2021 at 8:38 PM, Bunnyman21 said:
Hi Bunnyman! I'm not sure if you're getting notified on Github, so I figured I'd ping you here in case you didn't see it. I found a minor bug in CuraMaterial.py, proposed a fix, and put in a pull request. Never done one before though, so I apologize if I did it wrong. Anyway, CuraMaterial.py was not getting the most current user directory for the materials on Windows systems, if the user had certain past version numbers remaining on the system. A little change to the sort function fixed it right up. I don't know how to compile an executable though, so I'm just running off the Python version for now. Perhaps you can compile a new executable if you approve of my change. Thanks!
-
1
-
-
6 hours ago, JonCxW said:
I agree, not a great arrangement. I went ahead and did that, they sent out a new cable.
Post back and let us know how it works out. What baffles me is why this needs to be a fatal error. Yes, I understand that the chamber could overheat and damage the steppers or printhead, or even in some crazy low-odds scenario, possibly cause a fire. Yes, that could theoretically happen; but it definitely would not happen quickly. In other words, this is not a crisis-level, abort-the-print sort of error; it should only be an informational warning for you to check at the end of the print. Even in a worst case of running the bed, chamber, and nozzles at the highest allowed temperatures, in a warm external environment, the interior of the machine would take long minutes to get from 50C (its max temp) to even 55C, let alone any temp that is dangerous. I've put a thermometer in the machine and the chamber is actually hard to heat up - it won't even go past 40-45C in regular office conditions, no matter hot or long you run it. So given that the fault is not urgent, could they not simply retry the communications every 10 seconds for 5-10 minutes to see if the air manager comes back? It couldn't be more than a few lines of code to retry for a while. Or make it like the new and improved ER65 error, where the operator has a chance to correct it and resume (in the most recent firmware). That wouldn't be so hard either, just pop up the error with a fix button, like ER65, instruct the operator to seat the cable, and the machine tests for the Air Manager again. If still no air manager communications, just make the operator press a button affirming that they've opened the air manager lid to let the heat out. Or hell, just run the fan up to max and let the print run. I've had three prints fail more than 24 hours in over this stupid ER80 error and that is just a lot of time and material to waste for no good reason. I'm just about to the point of unplugging the air manager from the printer, telling the printer it doesn't have an air manager anymore, and using my own external temp controller to control the air manager fan. It's bad enough to lose a print because you messed up the slice or because the material was wet/defective or because the material wouldn't feed right; but to lose a long print for a stupid error that isn't even protecting anything? That's just galling.
-
7 hours ago, JonCxW said:
I noticed the plug end was coming out, so I disconnected the Bowden tube clips and taped down the connectors. Even with connectors fully seated, I am still experiencing ER80 in >30% of my prints.
I ended up changing my cable, even though there was nothing obviously wrong with it. I think the issue is that the cable has to make a 90 degree turn coming out of the lower connection and that creates an upward (sideways from the perspective of the connector) pull on the connector that makes the connection somewhat unreliable. It probably would have been better to have a right angle on that connector like they have on the cable from the material station to the printer. At any rate, if you're still getting the error, I would contact support and inquire about a cable.
-
12 minutes ago, GregValiant said:
The initial layer is Layer:0. The raft layers are negative numbers so your first slow layer would be the first layer of the part.
In higher layers then yes, that setting wouldn't work for you. Instead, you can find the layer (minus "1") in the gcode and manually add an M220 command. (M220 S50 would tell the printer to compute all of the speed entries at 50%.) At the next layer you would add M220 S100 to return the printer to 100% feedrate.
That would indeed work. If there were only a couple of spots, it would be a very elegant solution indeed. Unfortunately, this part is pretty tall though, almost 1000 layers, and there are overhangs that put "bottom" portions on probably 1/3 of the layers or more, so it would slow down the print a tremendous amount, almost as much as if I just set the top/bottom speed for the whole print. Thanks again for bouncing it around with me though, most appreciated!
-
19 minutes ago, GregValiant said:
There are at least 3 ways. I think this is the one you are looking for.
In Speed - set the "Number of Slower Layers" to 1. That will make the "Initial Layer Speed" setting visible and you can enter whatever you like for the first layer.
Thanks for the reply. As far as I understand though, that only applies to the first layer against the buildplate. If the first layer of the material is not on the bed, as would happen if you printed a raft from the other material or when it is a bottom layer that occurs higher up (like an overhang), then the initial layer speed does not apply. Is that understanding incorrect?
-
I'm working on a print that has quite a bit of support. The supports start both from the buildplate and from the model. Filaments are ABS and PVA. I'm having some trouble getting the ABS to stick when it goes down onto the support interface. Having checked temperatures and fan speeds, my next thought for this is to decrease the speed of the ABS layer that is directly on the support. So I went to the speed section, looking for the bottom layer speed, and I was surprised to find that top and bottom layers share a single speed setting. So if I lower the speed, it not only slows all the layers of the bottoms, but also all the layers of the tops, and it adds an unacceptable amount of time to the print. Is there any way to get each first bottom layer to print slowly without slowing down all the top/bottom layers?
-
It's definitely not difficult to do. The question is if they will let us have that flexibility. Thus far, the answer has been no.
Infinite Material Solutions: Aquasys
in Materials & profiles
Posted
It is black PC, haven't tried clear yet. Thanks for the link to that surface modification. I don't think it's right for this application, but it is definitely a clever idea that I will keep in the quiver for other uses!