Supramaker
-
Posts
46 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by Supramaker
-
-
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.
-
1 hour ago, Slashee_the_Cow said:
Cura probably wouldn't remove stray files in the scripts folder because it wouldn't expect them to be there in the first place.
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.
-
6 minutes ago, Slashee_the_Cow said:
What can I say - it works fine for me.
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 callableIt'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.
-
9 hours ago, Supramaker said:
So I searched and found a post-processing plugin called "ScalableExtraPrime":
https://github.com/Pheneeny/CuraPlugin-ScalableExtraPrime
and there is a similar request in the Cura github:
"Retract extra prime amount calculated according to travel distance #3658"
I could manage to load the main script "ScalableExtraPrime" (was wrong api version in the json-file) and I get the setting options in the settings panel, although I still see the same errors about "ScalableExtraPrimeAdjuster", which is definitely called from the main script.
So I don't dare to use it, as I could suddenly extrude the whole filament role at once 🙂
Please see the link, your help is very much welcomed.
-
The file/script/module "ScalableExtraPrimeAdjuster" cannot be imported from the main code "ScalableExtraPrime" (it has "no attribute", something ridiculous trivial):
File "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py", line 207, in loadScripts spec.loader.exec_module(loaded_script) # type: ignore File "<frozen importlib._bootstrap_external>", line 883, in exec_module File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed File "C:\Users\rcast\AppData\Roaming\cura\5.5\scripts\ScalableExtraPrime.py", line 14, in <module> from . import ScalableExtraPrimeAdjuster ImportError: cannot import name 'ScalableExtraPrimeAdjuster' from 'PostProcessingPlugin.PostProcessingPlugin' (C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py) Exception: Exception occurred while loading post processing plugin: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster' Traceback (most recent call last): File "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py", line 210, in loadScripts loaded_class = getattr(loaded_script, script_name) AttributeError: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster'
The same happens with "ScalableExtraPrimeAdjusterTest".
I cannot dial with that issue now, it would push me back (since I am not acquainted with python) and I must get the printer to work at least at an acceptable quality level. But I will sure try, weeks later I assume.
-
Here I am again.
I recollected both cases. This time the settings are more reasonable. The model has per-model settings making it slim (facilitates recognizing problems and saves material and time).
Left side is without post-processing (BLVMGNC300-RetractTower_No-RetrCont4Forum.gcode)
right side is with post-processing (BLVMGNC300-RetractTower_RetrCont4Forum.gcode)
RC does not retract during travel moves, but extrudes after a retraction instead:
Line 3237
Line 3315
RC „modulates“ its retraction in a strange way:
Line 5498
Line 5543
Not that bad, but I do not quite understand.
You mentioned a high retraction distance from my previous post. In the meantime I determined that up to 1.8 mm retraction distance, the print is perfect but stringing is massive. It can only be completely reduced beginning at over 2.4 mm. Unfortunately, gaps begin to appear already at 1.2 mm. At 1.6 the gaps grow several mm wide. The lines following retraction are started underextruded. Even huge values of extra prime did not help, but ruined the print completely instead. Why, is unclear to me. Extra prime should help in this case. No setting yields an acceptable compromise.
Which death should I die?
RetractionContinue did not help either. Not surprisingly, this is more a de-retraction issue.
So I searched and found a post-processing plugin called "ScalableExtraPrime":
https://github.com/Pheneeny/CuraPlugin-ScalableExtraPrime
and there is a similar request in the Cura github:
"Retract extra prime amount calculated according to travel distance #3658"
https://github.com/Ultimaker/Cura/issues/3658
The script is old but should work, supposedly. It is a pity that I cannot load it, the log says:
ImportError: cannot import name 'ScalableExtraPrimeAdjuster'...
(that's another script in the package).
Looks like a trivial error to me, not imported/declared correctly.
That was my second-to-last hope, before I engage tuning Pressure Advance.
But wait, there are still some Cura parameters addressing anticipatory pressure changes, similar to Pressure Advance. I will try that tomorrow.
Actually, the printer should print the rest of it self, some non-essential parts are still missing, which should look good 🙂
That is why I am trying so hard, but it is a chanllenge, believe me.
Have a nice day.
BLVMGNC300-RetractTower_RetrCont4Forum.gcode BLVMGNC300-RetractTower_No-RetrCont4Forum.gcode
-
Thanks for your interest.
Apparently, the speed limits in your printer configuration are set too low. I know that because I used a copied printer profile at first, when I used this printer for the first time, I got similar error messages.
Yes, I have a quite capable selft-made CoreXY printer, but it is not unique (there is a build template), other users set even higher speeds... but mine is just about 10 days old, so I am conservative 🙂
The intention of the fast travels is to diminisch stringing.
I will re-generate the gcode files using lower speeds and export the project files again (I was assuming that you would like to generate the post-processed instance yourself).
I understand that without detailed examination no comment can be made on the peculiar behaviour of the script.
That will take some time though.
-
I won't be embarking in configuring Pressure Advance right now, but that is high in my priority list. One issue at a time. But yes, Duet 2 WiFi supports Pressure Advance. For Pressure Advance, I think will have to look at following Cura settings:
"Coasting",
" Flow rate compensation Factor",
"Gradual flow enabled",
"Gradual Flow max acceleration",
"Reset flow duration"
"Flow equalization ratio"
not to speak about retraction, combing, coasting and z-hop (anything that changes speed or flow). Lot of things to be revised. Fell free to complete the list.
Coming back to Retract Continue, I took a quick look at the changes made by the script.
Just sliced a tower with/without Retract Continue (0.05) and compared the results. I found following unexpected results:
RC changes travel moves INCREASING extrusion (not retracting), while originally no priming but a retraction was taking place:
Line 3408 / 3416
RC changes travel moves decreasing extrusions at first, then increasing them again:
Line 3462 / 3470
Right now, I don't feel comfortable using this script. When combining it with other scripts, I am afraid that strange things might happen.
(if you are interested, find the project file attached, created without RC).
-
OK, I will calibrate the Pressure Advance of my board.
Don't know if what Cura does to emulate Pressure Advance must be switched off or changed, because then I would have two solutions for the same problem working in parallel - not good.
For some reason I was thinking that Pressure Advance was possible with Klipper only - sorry, still learning.
-
Wait - you mean that if my board supports Pressure Advance and Linear Acceleration and these features are activated in its firmware, then Cura would automagically generate a better gcode?
Or do you mean that the same gcode would be executed better by the board?
(Now urgenly checking the Duet 2 WiFi running the last RRF firmware version...)
-
3 minutes ago, GregValiant said:
It can cause blobs as the mm³ is always the same regardless of the length of the travel move.
Exactly the same applies to priming. I mean when priming takes place, the pressure will not rise suddenly, assuming the speed fits. But for different lengths it will not fit, that is the point. If it does not fit, you get a blob (too fast) or a gap (too slow). Extra priming would not be needed if the speed is tuned depending on the length of the next extrusion path (I think).
I am actually engaged in tuning coasting - same issue. It happened that I printed a piece similar to a conus, going narrower upwards. The coasting setting was appropriate at the bottom part of the piece, but I got huge gaps at the top. Again, the coasting amount not depending on the length of the extrusion path is bad.
I marked your reply as a solution.
-
6 minutes ago, GregValiant said:
If you intend to use Z-hops you should use the new version.
Thanks a lot!
I could follow your example very well.
In my experiments, I had 0.1 set. My printer survived 😀 I did that because almost no retraction was set from the settings.
OK, I see I am more on track now.
So the retraction setting itself remains unchanged and new retraction is added by the script along the travels.
This script works as retraction should have always worked.
Can I infer that priming is forced to begin just at the start of the new path?
"G1 F2700 E1736.58285" <== priming
Now we need a post-processing script to spread priming over the next starting extrusion path. No script available for that?
Perhaps I should really learn python, I have a book already in the shelf just waiting... Or Cura will generate better gcode in the future that does not need to be "patched"?
Thanks again!
-
1 hour ago, Slashee_the_Cow said:
2) The amount it changes is not relative to the retraction settings, it will only adjust the retraction by its own speed setting.
3) The script won't do anything. It only activates itself when it sees retraction (a negative change to the extruder position).
Thanks for clarifying so far.
Own speed settings? I thought changes would be proportional to the length of the travel.
4) Does the script work in a way to do the retraction with the speed needed to be just finished at the target coordinate of the travel? If not, when is it finished? If there is a de-retraction or priming, how is it timed? This last question is important, since ideally priming should not start after the new extrusion line.
5) And how does it behave when the travel path is composed of several movements (because it does not reach the target in a straigt line)? Is the retraction finished after the 1st travel movement or is the retraction fractioned as well?
6) I don't know if activating retractions with a length of zero would generate commands with E0 (if relative mode), I am still doing experiments. But anyway, it is still unclear to me if the "travelled" retractions inserted by the script are additional or not (with a retraction set to a non-zero value). I did an experiment: I set retraction of 0.01 just to be sure that the script would be triggered, trying to have mostly "travelled" retractions. As a result, I got small breaks again. This behaviour defeats the purpose of the script I think. The script should be able to execute the whole retraction while moving, so avoiding breaks.
7) When the script does its changes, are all other settings concerning retractions (de-retraction for example) still in effect? Does the usual retraction command in the original Cura output "G1 E-x" stay untouched?
8 ) How can I identify the retractions introduced by the script? I am now working on that actually, but this is very time consuming.
9) Should I expect g-commands like this (assuming relative extruder mode)?:
G1 X123 Y123 Z123 E-1 ; <== both travel and negative extrusion in just one line
10) If I could coalesce the effect of the setting "Z hop on retractions" in the same g-command, it would be perfect. Would it be possible in theory to achieve retraction, z hop and possibly wipe in just one command? The purpose is again to avoid the break caused by the z hop movement: When the bed begins to move down, the nozzle moves away and the filament is pulled back synchronously!
If someone would contribute to understanding this script, I would avoid a lot of nasty experimentation work, and others too...
So please!
I will end up learning python sometime.
-
Hello,
Using PETG, I am trying to eliminate stringing (as probably anyone using this material). I switched on retractions but in my case, when any retraction takes place, a small break occurs, during which material keeps extruding and leaves a blob (I tested many combinations of temperature, retraction length, retraction speed and prime settings).
Since any movement stop (or disruption of extrusion) is detrimental to quality, I am trying to use the "Retract Continue" post-processing script. As I understand, there should be no break as the retraction takes place simultaneously with the following travel movements. Is that correct?
But I do not exactly understand how this script works (and it is difficult to find a documentation).
1) Do I need to enable retractions in the main settings for this script to work?
2) If I enable retractions in the main settings and set a retraction distance there, will the script put additional retractions (proportional to the sum of the lengths of all following consecutive travel movements), or will it ignore the retraction length from the main settings?
3) What is expected if I enable retraction in the main settings with a retraction distance of 0 (zero)?
Or you could refer to the documentation if these questions are already answered there.
Thanks
Rick
How to deal with Post-processing script "Retract Continue"
in UltiMaker Cura
Posted
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 🤩