Separate names with a comma.
Discussion in 'Getting Started' started by mkudzia, Apr 14, 2020.
Hmm, this gap shouldn't happen! Mind sharing the 3mf file and the gcode file so I can troubleshoot?
The doors for Bell 206 printed with ASA and HIPS as support
This looks legit as - if you notice this irregularity corresponds to Support layer irregularity - this is related to the fact that Prusa slicer genrated support layer-zs don't line up (are offsets) from model layer-z
I need to check on the gcode file if this thing on S3D preview is
A) issue with script where it skipped layers (bug)
B) issue with S3D preview - where it has issues presenting thicker layer that is a result of post processing script generating a much thicker prime tower layer due to optimization done and S3D now showing the thickness correctly.
Dont think I dont care anymore. But my time is blocked rightnow.
I first have to fix my tools again, then I can continue testing the post processing script.
But I'm on it.
@mkudzia I had some time today.
And I fixed my tools and tested the gcode which I generated using the postprocessing.
What I can tell so far is
that the temperatures are optimized
and it is very nice to see the fast toolchanges.
But my T0 does ignore generating the priming-tower right after it is selected. Is that possible?
Gcode for the priming tower is generated well for T0 but it seems to be build up at the wrong time. I had to abort the test and cannot tell for sure but it looked like the tower is generated after the tool printed or inbetween layer changes? If that information is importend I print another "fish". Otherwise not.
The gcode is added to the repository I forked.
I use 3 tools. The number is uneven. Might this affect things?
I will have a look and let you know
Hey, pushed newer version of code - with some fixes including the default tool handling
(PrusaSlicer doesn't add T0 at the beggining if the print starts with default (T0) tool.
This has been fixed
One thing I removed is the 'aggresive' prime tower optimization; still trying to troubleshoot it but it ends up not injecting prime code for some layers.
Without the optimization it seems to work fine.
Fixed the issue with prime tower optimization
Wrong condition was used - and as such it was too aggresive(BROKEN)
Please pull the newest code and test
Thank you alot!
I will do other tests the next days and report back to you.
Again it took some time to figure out other problems but the post processing works now.
I still see two things that might be worth a discussion:
- There is one more optimization which *could* be implemented: See the short tower jumps to the "last position" in the video. I explained it there.
- I have to test if the temperature of my own T0 is dropping as well if the tiny test-tower gets bigger (longer time span between the selection of T0). Otherwise there might be still some tiny bug
or I have to fix my prusa slicer profile once more.
Afar from that I will probably not print without the script anymore. Thank you alot!!
Forgive my ignorance, but I've followed all instructions, triple checked file locations, links, etc. and I'm still getting an "Error Code:2" message.
I'm also not seeing Python launch at all.... unless its happening super fast.
I've checked permissions on all the scripts, apps, and file locations to make sure there are no permissions issues.
My print (single extruder test, Tool 3) is going fine right now, GCode generated following modified naming convention as in the readme to note layer height.
Any suggestions? obviously the initial machine setup is at least functioning to complete this print. Am I missing all the goodness within the Scripts?
I wonder why your file is in "Appdata/Local/Temp".
Do you instantly upload your gcode to some board?
I save the file so some folder like the Desktop and it gets postprocessed there. Afterwards I check the generated file and upload it manually.
no, I have the print host upload blank, I just export to file, and upload via browser to Duet Wifi. I'll dig around a bit and see why its trying to upload the output file.
The tiny tower temp not dropping is a feature.
Basically my temp optimized is build the following method:
- Set the IDLE tool temp to be lower by pre-configured delta for each tool
T0 215, idle temp 160
Let's assume T0 becomes idle and in between T1, T2 prints
The optimizer will estimate the print time (idle time) between when T0 was deactivated and when it's next activated
In the config files for post process script you got two settings which specifies how fast hotend cooldown (C/s) and fast it heats up (C/s)
Ofcourse this is estimate and we assume cooling and heating in linear (where actually is exponential - but its close enough in the space between Temp Active and Temp Idle)
Then it checks how much time it takes to cooldown and heat up from Tactive to Tidle and back
If the cooling down and heating up interval estimate is higher then the actual idle time - this means we will never hit the idle temperature
At this point the post process script - DOESN'T insert code to lower the temperature/heat it up
It will only insert it for tool change periods when there is time to cool down to Tidle and heatup back to Tactive
So in your case - it's not that the print time of the small tower is to low; it's actually the time between tool deactivation/activation is to short
Today I saw another error.
I wanted to slice this raven:
Python always crashed because of a memory limit (2GB) -> my installed python was 32bit.
I did now switch to python x64 and it worked.
Yep, go 64 bit
The memory managment in it is not the most efficient (but fine for most prints)
2GB 32bit limit is defo not enough
Added accurate filament usage accumulation that includes the object and generated prime tower.
Script now also updates the values generated by PrusaSlicer in the gcode
Post-processed GCode will now include proper statistics for
- filament usage [mm]
- filament usage [g]
Those values include the usage of objects AND prime tower.
Those values will be properly read and shown in the Duet Web Control so the job dashboard should provide
more accurate print time estimates based on filament and file progress
I got this error just now, after the update.
I did activate Debug = true to see this.
I did then comment
out and it worked.
I need your some help.
I used Python version 3.8.3 on Mac OSX.
I get an error when exporting GCode.
This problem seems to be related to the encoding and file name.
Is it displayed because used by mac OSX?
and I've tried change the PrusaSlicer language to English, but the problem is the same.
Fixed, stupid coding error - master branch updated