Supramaker

Thanks, that is easy to verify, as I can put Gcode commands directly in the console section of the Paneldue display while sitting just in front of the 3d printer.

Yeah, exactly that is what I am working on. I am trying to find out how to independently control one fan output in my Duet2 WiFi (I've got several) and setup a macro for that, should be viable. I meant the postprocessor for annealing purposes; not a bad idea, by the way. Depending on isolation of the cover and of the underside of the heatbed, a quite high temperature can be achieved (I would need something like a tart cover or a bottomless cardboard box to cover the build plate since my printer is not fully enclosed). I left a bluetooth sensor inside while drying the filament role and can easily control the temperature in real time. Last time I got rid of about 15 g of water. I recently read somewhere that annealed PLA has allegedly the highest stiffness of all kinds of common filament materials. A quite troublesome thing remains though: The unpredictable degree of shrinkage, which makes the piece useless as technical part. But anyway.

Thanks, now I am certain how to deal with those values. I already have the Material Settings plug-in installed, and just because I wish to consolidate the settings a bit I wanted to know how this works. Then I will have to probably put all types of flows in the Material profile itself and only change what is needed case by case. For example, I found that for hinges, it helps to lower the flow 1-2% to allow for clearance (I know that there are better ways like Horizontal Expansion, ordering or outer walls, and exclusive mode). It is a pity. I hoped to be able to separate strictly material dependent things from all other cases. May be I will come back to you for a postprocessing script to anneal the parts in place. Actually, I am not annealing but I printed a support part for filament roles featuring a small fan, all covered, on the heated print plate, in order to dry filaments - not far from annealing (just a higher temperature is needed then). Thanks a lot.

I have a simple question that is intriguing me for a while now and I need to solve it at last, because it is so basic for a good print. Assuming following situation: I define a new custom material and set a flow for this new material to 98% (for example). This is the optimal setting relative to what I have already determined via e-steps calibration. Then in the materials section of the quality profile, I set the flow to 100%. Now what is going to be the effective flow of my prints with this custom material selected? Will it be 98% or 100%? Will those settings substitute each other or are they supposed to be multiplied? To be more clear: If I set flow 95% in the quality profile, will be the resulting flow 0.98 x 0.95=0.931 (or 93.1%)? Or will it be just 95%? I already know that the quality profile settings override the material settings if changed. In this case, I see no symbol at the left side of the corresponding field that would allow me the reset the changed value in the quality profile to the "default" value of 98 from the material settings, suggesting that both values work together (by multiplying). Although the quality profile settings override the material settings, in this case of the flow value it would make sense that the quality profile setting would be just a modifier to consider flow settings specific to the particular print part than to the material. And by the way, what other settings of the quality profile behave in a manner that they do not replace but modify the materials settings, if any? Thinking about "Scaling factor Shrinkage Compensation" - it depends also on which part I anneal or not after the print, and since there is no special setting for shrinkage of annealed parts... Sorry to ask that simple question but I could not find an explicite answer. (using Cura 5.5).

You will have to wait asymptotically long. Or blow yourself very, very large.

I took your advice seriously and went through the process again. It turned out that all my flow calibrations were made with small, filigree parts. They do need a higher flow than ascertained by the esteps measurement. But the larger the prints, the closer the flow should be to the "official" 100% rate. So I was biased. I have never printed a piece weighting several hundreds grams yet and if I did, 110% would be too much. In short, you were a couple percent right, depending on the weight 🙂

Touché! However I am quite new to 3d printing. My self-made printer is about 4 weeks old (building it took 2-3 months, mainly due to 3d printing parts needed), and is still work-in-progress. I want to gather experience without Klipper or other magic first. But yeah, Klipper is one of my many ideas in the project.

As I said: going down to 90% (which is huge if 110% is the correct value) does not diminish the amount of excess material, on the contrary: The blobs can be seen even more noticeable, as the surrounding is scarcer. We already know: The results of a e-steps calibration are not mandatory to set flow rate. Of course, the number of steps per mm must be set correctly in the config, but there are other factors like diameter of the nozzle and/or of the filament, or whatever else. I noticed that using the 100% defined by the calibration, I was getting holes in models made of just one wall. Then I did a "real life" flow calibration, using approriate models in a set with varying flow rate. The result was 110% and that has proven to be fine until now. It dawned on me that there is no fix for this issue, which happens to hit me severely with this particular piece. I can still do mitigation or tricks, like using just one top/bottom layer with gradient infill combined with coasting and ironing (for the topmost layer), but I hate when the nozzle strips the blobs on the solidified surface, causing vibrations and mechanical stress, not to speak about knocking the print off the bed. Another kind of "solution" would be to define per-modell settings blocks containing the top/bottom layers only with their own parameters, like snailspace speed. Unfortunately, coasting is not available for per-model settings. The best solution would be to anticipate the flow decrease based on the number or frequency of turns ahead. I am honestly quite surprised that this issue has not been addressed by Cura developers, considering that it is so basic and could potentially affect every print. Seems like most Cura experts are on holidays. I will take a look to Klipper asap.

I cannot follow, with the best of intentions. In Cura, using the Mesh Tools, I get a message "The model is watertight" when doing a check. I don't know how to recognize further errors in the model, give my a hint. I would willingly learn to correct them. That looks to me like tiny details in the mesh, which would be ignored by Cura (in my understanding). Do you see any link between those errors and the issue I am adressing? Because no matter what model I use, the depicted behaviour is almost unavoidable: When building a bottom or top layer with a pattern of lines, very often the nozzle will move doing turns in a limited area, without having adapted the extrusion rate to this effectively slower speed, resulting in overextrusion. That happens in the inside of the print, but cannot always be ignored.

Alright, please find the project file attached, including the corresponding picture. In the picture, the blobs are deformed by the nozzle passing through them. Be aware that in my case, 110% flow is usually the correct rate (e-steps calibration has been done, but using it as 100% would yield underextrusion in many cases). It took some time as I wanted to be sure that my statements still stand and I spent hours doing experiments. No matter how you look at it: In the spots where the bottom layer pattern is "squeezed" and in the connection points of the hexagons (there is a small area there in the middle that wants to be filled by itself, slowing down the nozzle) there is excess flow. But I admit: TPU balls won't suffer from this defects 🙂 And I still don't know how to cope with that. Perhaps I will try other slicers? Rather not, they will have their own quirks, which I will have to learn the hard way again. DancingNozzleTest.3mf DancingNozzleTest.gcode

I also tried larger values of that parameter without success. The point is, this is not a small bottom. It is a small area in the bottom. Don't be surprised to know that the first thing I did was to decrease the flow to 90%. It looks inded as a case of overextrusion. Result: light signs of underextrussion appeared, accompanied by the same blobs. So it got worse. The material flowing at this spots in excess is not accounted for anywhere. It just flows "without permission". Of course a lower flow means a slightly lower pressure, and the blobs would be smaller, in theory. Practically? No.

You can reproduce this behaviour with ANY model actually. I have been seen that happening from the first piece I ever printed, but I did not try to troubleshoot it. It was not necessary, as usually the layers are buried later on if the effect is not so pronunciated. So I used to ignore that, things are not perfect in the 3d printing world. It just happens that with this model due to its shape there are many such spots, while at the same time several bottom layers are defined, using the notoriously leaking PETG. But I will provide a project file, why not. No pause, just slower. I observed cautiously many times while printing. Do not expect a Duet 2 WiFi to have that weakness (the idea would be digressive).

Today I tried to print a kind of grid, several mm thick. While printing the bottom layers, lines are layed to fill areas that are often small and have narrow corners (between the holes). So lines are printed one after the other, but as the nozzle approaches the narrow corners, the pattern dictates that the lines get shorter and start cornering around more often. At some point, the nozzle seems to "dance" slowly on a small area. Then I can literally see the plastic flowing in excess, a drop appears. Then the nozzle is moved away going through the huge blob, and drags rests of it around. An ugly picture. Stringing is the smallest concern. This is due to the fact that the nozzle effectively moves slower and slower as it executes turns in short order, but appareently Cura does not take this into consideration and does not compensate the flow. The flow simulation confirms: no variation. The same applies for speed display. This is not a pure cosmetical issue. With several such layers, the excess material accumulates. The nozzle hits the blobs violently when traveling and even knocks the piece off the bed. Incidentally, I used 5 bottom layers and 5 top layers, exacerbating this effect (not knowing what would happen). This problem can be mitigated by a very slow printing speed, so that the flow in the problematic spots is not very different from printing at regular speeds then. But I am not happy printing at 10 mm/sec, when I can do it 10x faster at least. While experimenting, I tried coasting with high values (0.3) and I could indeed eliminate some such spots but only when they happened to be at the end of the line, otherwise they were clearly recognizable. However this is not a general solution. I also tried different line patterns, and even a flow equalization ration of up to 400% - no effect. What is the proper way to tackle this problem? (Not just mitigating it) PS: Would Klipper be aware of cornering lines? (I don't use it).

I am determined to write a post-processing script aiming to give an overview of what is happening layerwise (not changing anything). After what I experience with troubles due to unexpected quirks of Cura, I got tired of looking at the Gcode and numbers to figure out what is happening. I actually have begun trying to process the Gcode, using awk (since it is actually just text). At some point, I will do it in Python as a post-processing script. And nobody asks what actually was spoiling my prints... My post must be very boring. Had I have that analysis tool, I would have recognized the problem at once. That's why I will write one.

I started this thread about post-processing scripts, because I thought I would need them. In the meantime I realized that my problem with underextrusion right after retraction was due with something wrong in the settings (after analyzing the gcode files directly), why I interpreted as a bug in Cura (debatable). I found the culprit and corrected the settings. No underextrusion any more. Great relief. The post-processing scripts could still be a help in subtle improvements, assuming that they work at all. And I wonder if there is a repository for such post-processing scripts somewhere, at least I don't see them in Cura's Marketplace.

I could not see any difference in the gcode using the plugin ScalablaExtraPrime. It does not work, it changes nothing. But it makes a good impression 🤩

After I did a clean reload the plugin was loaded without any dubious messages in the log. While Marketplace Plugins can be managed in the GUI, Cura seems to lack a controlled method for removing user plugins (to my limited knowledge). Loading is one thing, the actual effect of the script is the other one. Anyway, it can be tested now.

I asked not out of skepticism, on the contrary. I noticed that even after removing the scripts from the user-script folder I was still seeing messages about those scripts in the log. Thanks for that tip - I am still learning. I reverted the scripts and the plugin is loaded. I also found that the script ScalableExtraPrimeTest can be completely ignored, it is not invoked anywhere.

What do you mean with that? The GUI elements appear in the settings (see my posting above), but that does not prove that it is effectively doing what it should. My practical tests have shown no effect in the printing, and I did not even look at the gcode to verify that, because it is obvious that if the subroutine ScalableExtraPrimeAdjust (which is invoked in ScalableExtraPrime) cannot be loaded, the main script won't work. So for me, it looks as though it would work, but it does not. The script ScalableExtraPrimeAdjust must be put in the same directory, it is called from there. And as you yourself confirmed, it is part of the plugin, not just an independent script that could be taken out. Where are the places to look in order to remove the remains of the plugin, in order to have a clean state for reload? Why do you assume that such remains are still there? In the logs, Cura confirmed the clean removal of the plugin. Since the deinstallation was done by Cura itself, it should have gone well. The line in the log: 2023-11-18 11:35:40,445 - ERROR - [MainThread] PostProcessingPlugin.PostProcessingPlugin.loadScripts [227]: AttributeError: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster' states clearly that we have an ERROR (not a warning, not a notice or something else) and should not be trivialized. We got stuck in the troubleshooting work, I fear.

The same import line has to be corrected in the file _init_.py too. But there is a new issue. After restarting Cura. Cura rejects the plugin and proposes to remove it (directly in the GUI: Re-installing does not help. From the log: 2023-11-18 11:35:36,622 - WARNING - [MainThread] UM.PluginRegistry.loadPlugin [541]: Plugin [ScalableExtraPrime] failed to register: 'module' object is not callable 2023-11-18 11:35:36,626 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: Exception: Error loading plugin ScalableExtraPrime: 2023-11-18 11:35:36,628 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: Traceback (most recent call last): 2023-11-18 11:35:36,628 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: File "UM\PluginRegistry.py", line 510, in loadPlugin 2023-11-18 11:35:36,629 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: to_register = plugin.register(self._application) # type: ignore # We catch AttributeError on this in case register() doesn't exist. 2023-11-18 11:35:36,630 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: File "C:\Users\rcast\AppData\Roaming\cura\5.5\plugins\ScalableExtraPrime\ScalableExtraPrime\__init__.py", line 12, in register 2023-11-18 11:35:36,630 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: return {"extension": ScalableExtraPrime.ScalableExtraPrime()} 2023-11-18 11:35:36,631 - ERROR - [MainThread] UM.PluginRegistry.removeCorruptedPluginMessage [575]: TypeError: 'module' object is not callable It's your turn 🙂

@Slashee_the_Cow You are late in the party, done that. The mentioned problems loading two scripts remain. This is what I meant: https://bobbyhadz.com/blog/python-attributeerror-module-has-no-attribute Thanks anyway.

I did some investigations and found out that my problem with underextrusion immediately after retraction is caused by quirks in the gcode, which only happen when I use a specific quality profile. Essentially, actual retraction is larger than the value configured in the settings and priming won't compensate. When I use a different, but similar quality profile (which I used heavily in the past with a different printer), all retractions and priming value in the gcode make perfect sense. Using the current quality profile in question, I get underextrusion and strange things appear in the gcode. I removed post-processing scripts, set extra prime amount and coasting to zero, and used a retraction of 2 mm in both cases. This is just an example: G1 X133.18 Y219.808 E191.60831 last extrusion of previous line G0 F1710 X132.305 Y219.808 E191.60831 travel M566 X1800 Y1800 G1 F7200 E182.56831 questionable retraction of 9.04 mm (setting is only 2 mm) G1 F18000 Z1.4 z-hop G0 F42000 X132.305 Y218.868 Z1.4 E189.60831 priming 7.04 mm - why? G0 X167.7 Y214.946 E189.60831 travel M566 X600 Y600 G1 F18000 Z1 nozzle down G1 F7200 E184.56831 retraction of 5.04 mm, why? G1 F1800 X167.568 Y213.748 E191.65641 priming 7.088 mm (this is too much for a small move) Either I am not able to understand what cura does or we have a bug. I have been perusing gcode files for a while now (along with printing models) and I am cocksure that Cura is misbehaving. I am still looking at the differences between the two profiles, and am going to align the settings one by one, in order to find the culprit. Something causes Cura to run riot. This is somehow a relief for me because the results of my efforts to fix this issue at at best very puzzling. A bug would be an plausible explanation. At this point I won't follow the path of using post-processing scripts to fix this by now, they are the wrong solution. My confidence in Cura has been shattered a bit. I will definitely write some scripts to quickly analyse and check the soundness of gcode files, that should save a lot of time and material (I will be using script tools that I master, not Python). Nevertheless, RetractContinue and ScalableExtraPrime are very interesting tools that I will keep in mind in for cases where they are suitable. Honestly, the best thing to do would be replacing the nozzle with one having a valve... perhaps someday.

I did dare to run the script (stood right beside the printer to switch it off in case of emergency), but after printing a piece exactly the same as before, I see no changes. The piece still shows gaps with the same size at a retraction distance of 1.2 and above, and a lot of stringing. It is doing nothing without the two other scripts I guess. I still need to l thoroughly do the math with the numbers in the Gcode file to confirm that. I would very much appreciate if anyone would try to fix the installation of this plugin.

And according to the logs, "ScalableExtraPrime" is recognized as a plugin, while the other two "ScalableExtraPrimeAdjuster" and ScalableExtraPrimeAdjusterTest" are seen as scripts.

In case you are looking for the settings for this plugin, they appear in the Material-Section, not in the the Travel-Section as I would have expected: As I said, not trustworthy, since the subroutine "ScalableExtraPrimeAdjuster" would most probably not work, it could not be loaded: Exception: Exception occurred while loading post processing plugin: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster' Same for "ScalableExtraPrimeAdjusterTest", although I don't see where it is used. Hope this helps.