JCD
-
Posts
107 -
Joined
-
Last visited
-
Days Won
3
Content Type
Forums
Events
3D Prints
Posts posted by JCD
-
-
Jabbery,
I suggest to modify the infill AFTER the wall specially as it prevents the push on the wall
and put the infill as grid as the infill is necessary also to give the wall a strength
I use only PLA on an Anet A8 but as I have protected the hot end, I put only 50% (and not 100 as usual for PLA)
For ABS I read that usually there is no need for cooling
-
My suggestions :
1) uncheck brim only on the outside
2) change Infill pattern from concentric to grid (you have no infill on your part)
3) uncheck infill before walls (to have less visual impact of the infill)
furthermore isn't it dangerous (retraction) to have the cooling fan at 30% with ABS?
-
Jabbery,
Is it possible to put in the post the 3mf file by saving the project, for us to see what's your complete environment?
You have a brim on your model, is it only on the outside or everywhere?
If only on the outside, I suppose the wall printing on the interior will be alone on the bed, with a lot more opportunities to retract than if it was 'sustained' by the brim
-
Jabbery,
Have you tried in PLA, as ABS is a pain with retraction ?
-
Voila le fichier modifié
Modif faites
support horizontal expansion ramené a 0
support overhang angle ramené de 70 a 50
-
1
-
-
Pour ce genre de demande, fait un entegistrement du fichier .3mf, qui donne non seulement le STL mais aussi tous les reglages que tu as
-
In Cura INNER WALL means the wall which is behind the OUTER WALL, and this is true for the exterior wall of the box and the interior wall (the hole in the box)
On this line :
G1 X197.4 Y102.6 E231.46822 ; - 94.8 - incorrect should be 100 - 3.2 * 2 + 0.4 = 94
you are on the INNERWALL, which is 0.4 inside the OUTER WALL (on any side of the hole, hence the 2 x 0.4 difference with your calculation)
The corresponding line on the OUTER WALL is
G1 X197 Y103 E174.16633 ; - 94mm wide
and we see the 0.4 difference for the X and Y with the INNER WALL
So Cura is correct (but it does not take care of the effects I told before)
For the Cura Team
Maybe you can when slicing, track if you are in a convex or concave wall shape .
The concave wall shape is when if you have 2 following printing segments, (A>B then B>C, the middle of AC is outside the shape
For instance in the sample above
;TYPE:WALL-OUTER
G1 F3000 E160.37867
G1 F1800 X103 Y197 E164.97456
G1 X197 Y197 E169.57044in this case, modify the lines, to not extrude on the tiny travel before the corner (the histeresis make this unecessary after)
;TYPE:WALL-OUTER
G1 F3000 E160.37867
G1 F1800 X103 Y196.8 E164.9 (I have not calculate the exact amount of extrusion)G0 X103 Y197 (no extrusion here)
G1 X197 Y197 E169,5 (same difference as in the line above e.g 169.57044-(164.97456-164.9)
-
I think the problem (besides flowrate values) is due to the added technique of 3D printing.
1) look at the theorical movement in Cura :
I sliced a 20mm cube with a cubic hole in xy plane of 10mm
Below is the Gcode for the outside outer wall
We see that the movement is correct the center of the nozzle(here 0.4mm) is 0.2 mm inside the square perimeter
Now for the inside square hole
Here also the movement is correct, 0.2 mm outside the square perimeter
2) Now what is maybe happening
When you are printing a perimeter (either a square, a circle )you can look at the filament of 2 sides, the interior side of the perimeter, and the exterior one. Between the 2 sides there is a length difference the interior side is smaller (2PI x nozzleDiameter for a circle, for a square the diference is concentrated in the corners). So the plastic in excess will tend to move toward the inside.
Furthemore, every change of direction will have a slight dragging effect on the filament toward the interior, adding to the former phenomenon (the higher the speed, the higher the drag)
I think this explain the problem of the hole dimensions
-
1
-
-
I have not experience the two techniques on the same pieces so I do some 'crafstman work on my stl file if there is a dimensional problem ...
Your opinion is quite relevant anyway
I do'nt know F360 but I think in FreeCAD you can make two macros to automatically do the stuff, including a suffix in the STL filename to recognize which technique is it for
For example I did a macro to make polar function curbs like epicycloid
-
Maybe you're talking about this (see below)
-
I suggest you use FreeCAD to build your STL files
As a parametric drawing software you can write all of your inner perimeter with a diameter like d+delta
When you want a stl file for 3D printing set delta to +0.4mm and then export your stlfile in Cura
All the diameter using delta will be automatically updated by FreeCAD at once
Otherwise set it to 0 and export your stl file for your other technique
The difference between the 2 techniques maybe due to the fact that 3D printing is an add material process and milling is a remove mateiral process (with the size of the tools)
-
Have you take a look at my PostProcessing PlugIn called 'Bottom little holes Wall speed V2' ?
in the post
-
When I began to work on PostProcessingPlugIns, it was a pain as there is no way to debug the script
No message, even sometimes my plug in not appearing in the list.
So I tried to install a standalone Python with debugger and work on it. This is what this post is about ...
I Have windows 7 64 bit, Cura 4.0 and Python 3.7 with IDLE
I build two configuration, one for the Cura script folder (for me in \AppData\Roaming\cura\4.0\scripts) and one in the script folder for Cura in Python (for me in \AppData\Local\Programs\Python\Python37-32\Scripts\Cura)
The basic logic is I create a superClass MyScript derived from tje script class of Cura, in which I put all the stuff to manage the scrip, leaving only in the script the variables and settings definition, and the formulas working to modify the GCode
It gives a feel & look for all the scripts, gives more information to the user in the GCode, and also manage the way to debug a script in Python
To debug in Python, you have the same superclass, a DEBUG_SCRIPT script to prepare the GCode for debugging, a tKinter Window class to run the script in python, and a mini script class having only the functions necessary to do like the one in Cura (but only for debugging purpose)
In the file below you'll find the two configuration you have only t extract them in the corresponding folders and then restart Cura and deiscover ...
As PostProcessingplugIns you'll find
1 DEBUG_SCRIPT : to prepare the GCode for debugging a new script
2 Comment : a script only to add a comment a the begining of the Gcode (you can use it several times in one slicing process)
3 Remaining printing Time : to send to the printer LCD at each layer the time remaining up to the end
4 Lower Tiny holes printinting speed on 1st layer : to hav a better printing without filament dragging effect
5 LiftHead without annoying too large Z movement : to have a better quality for small layers
Now look at this scenario :
I insert all these scripts (number 1 to 8 to follow the result below), a few of them which will give an error that is handled
Here are the resulting pieces of GCode
1) Start of GCode
GCode during the 1st layer within a tiny Hole, speed reduced from 1800 to 600
end of a layer with information from several scripts
Now if I want to debug a script on the resulting Gcode file i have a the end of the slicing in Cura to save it in the IDLE scripts for Cura folder.
Then I go in Python's IDLE and run a script I want to debug
It appears a window to select the GCode file
Then the next window is to enter the settings for the script
if I close the window, result in IDLE
Or if I enter the correct params
If there were errors the IDLE debugger will give you a lot of information to modify your script
-
1
-
-
In fact I modified 2 parameters from your 3mf project file
- the support x/y distance from 0.7 to 1mm
- the support overhang angle from 60 to 50 degrees, this improved the result as at 1mm for x/y distance the collision was still there
-
Happy that smartavionics already did the trick 👍
-
Hello,
Are the G0's the only difference between the two flavors
If it's the case, try to do a PostProcessing Plug in to change all the G0's in G1 ?
In case I can do it if you want
-
I have no information on your exact dimensions and so on but take a look at
Support X/Y Distance (get it visible if not) and try to put in it a greater distance (1.5mm)
This will prevent a support to be too near from the object on the x and y axis, as it appear to be in your problem
-
I succeed to avoid this by changing the Support X/Y distance from 0.7mm to 1mm
To do this you have to change in the settings visibility the Support X/Y distance by clicking in the checkbox
Then in the settings modify the distance from 0.7 to 1 (or more if you want). This distance is the minimum one between the support and the object on the x and y axis. This maybe avoid the collision which occured in your trials
-
1
-
-
It 'll be more comfortable for us if you provide us with the stl file because :
- we will see what happen on the upper layers above the pictures you provide (zones which need for support or not)
- we can try out somme settings to try to fix it if possible
-
I have an Anet A8, and I use the 'sheet of paper' method to level the bed, maybe once on ten times, but the dragged problem occurs even after calibrating (i do'nt print under 30mm/s for the 1st layer)
With the script everything's fine
If I remember, this capability to lower down the speed for tiny holes exist in some other slicing sofware
-
Here is a sample piece for this problem, a plate with a cylinder hole which diameter is small (2 -3 mm)
if you look at the preview slicing for the first layer below is the picture
there is a problem if the speed of the red circle outer wall is too high. The picture below give an idea of what would happen, the blue line .
The plastic , which in this place, is alone and not glued to the brim as the red square, will be dragged by the movement of the nozzle.
So the hole is very badly initiated,
One solution is to drastically lower down ( to 10mm/s for instance) the printing speed for the outer wall and inner wall during this kind of movement.
You have to do that only on the first layer, on the other layers, the printed filament sticks a lot better the plastic on the level below, than on the hot bed
This is what this plugIn does; reducing the printing speed on outer and inner walls on the first layer if the nozzle changes direction over very short distances (such as those made to make a circle)
The plugIn is realised with 2 files, to achieve 2 main goals
1) allow a debbugging process using stand alone Python with IDLE interpreter (I shall show it in a seperate post later)
2) create a script superclass to get all the mechanic to have the scripts follow the same process in the GCode file
For this you have 2 files, myScripts for the super script class and the script file here BottomTinyHolesSpeed1.py
Below a picture of the begining of the GCode file after post process
You can see that 2 scripts were executed (BLHWS1 which is this one and RPT1 which is a new version of the plug in I gave in another post)
I tried to launch twice the 2 plug ins and as they are designed to be launched only once the super script class manage it and write it in the GCode
Also, in the LAYER 0, which is the one on the hot bed, the script modify the printing speed in the walls of the tiny hole
inside the red line the lower speed and in the blue line the older one
-
I Have an Anet A8, and the LCD is displaying while printing a percentage achieved.
It's annoying as it's not accurate (based on the number of code lines left (including the comments)) and not directly interpretabled.
So I made a PostProcessing PlugIn which puts on the last line of the LCD the remaining time until the end of printing, at the start of the print and after each layer
It's based on the delay (in sec) calculated by Cura in the GCode.
There is a parameter you can modify to adjust the time to reality if your printer is slower or quicker than Cura think.
For me the parameter is 0.935 (100 sec is adjust to 93.5 sec, my printer is quicker)
You will see in the code a number of lines about Python's IDLE debugging environnement. It doesn't matter when used in Cura, but I shall explain in a following Topic the system I put in place to avoid the pain of debugging in Cura.
Also the script is in 2 files, the second one (scriptUtils.py) have the commun functions that maybe used in several plugIns.
Both files are to be put in the script folder (AppData/Roaming/Cura/4.0/Scripts for Windows7 Cura 4.0)
Below a picture of the startGcode modified by the script
-
I have not an Ultimaker2 but changing the Gcode Flavor in the printer settings has other consequences as this value is checked to allow other parameters than the Nozzle Temp, modify start and end Gcode...
You'd better create a new definition file :
ultimaker2_0.def.json
in your AppData\Roaming\cura\4.0\definitions folder (if you have Cura 4.0 on a Windows7 OS)
content below
Quote{
"version": 2,
"name": "Ultimaker 2_0 (NozzleTempEnabled)",
"inherits": "ultimaker2",
"metadata": {
"author": "Myself !!!!",
"visible": true
},
"overrides": {
"machine_nozzle_temp_enabled": {
"value": true
}
}
}Then restart Cura and that's it, you can create your own UM2 printer
-
Excuse me,
I put the file in the wrong folder !!!
inner perimeters
in UltiMaker Cura
Posted
As the children tell in France when they have not discover the solution to a problem another child has asked for :
'Je donne ma langue au chat' (I give my tongue to the cat)
I hope you'll succeed !!