Open Quadra600 opened 10 months ago
Please add your zipped up project file. How do you expect anyone to debug an issue with almost nothing to go on.
Please add your zipped up project file. How do you expect anyone to debug an issue with almost nothing to go on.
Here--both the STL and the gcode.
The stl and gcode are of very limited use. That is why it is is requested that you attach a saved project file (3mf) from SuSi when opening an issue. A project contains a snapshot of not only the model but also all the settings you are using from the 3 in use profiles as well as any modifiers, variable layer heights etc.
The stl and gcode are of very limited use. That is why it is is requested that you attach a saved project file (3mf) from SuSi when opening an issue. A project contains a snapshot of not only the model but also all the settings you are using from the 3 in use profiles as well as any modifiers, variable layer heights etc.
Sorry
I had tried importing the Slic3r configuration, but the problem persists.... with a measured Z dimension always greater than the theoretical one.
Just looking at your gcode file and the last G1 height command in there is
;HEIGHT:0.201601 G1 Z19.908 F12000
Just looking at your gcode file and the last G1 height command in there is
;HEIGHT:0.201601 G1 Z19.908 F12000
I've seen that one, but I don't understand what I have to set to make it come out 19.78 as in the Slic3r gcode.
If I disable full Z_steps that last value goes up to 19.95 for me.
;LAYER_CHANGE ;Z:19.95 ;HEIGHT:0.200001 ; Layer Number: 99 G1 Z19.95 F12000
Well with a 0.15 first layer height and a 0.2mm layer height the closest its going to get is 19.95 as the alternative is to add an extra layer and get 20.1
If I was trying to figure out this on my printer I would get some known thickness gauges and then using the printer controls only (no slicer involved) command the extruder to go to specific heights and check that it actually goes to that height.
That would confirm that the steps per mm etc is correctly set up on the printer. While it should be as you can get results with a different slicer its still best to confirm. Naturally if you command the printer to go to a specific height then it needs to be able to go to that height.
I don't have Slic3er installed but PS doesn't have the Z full step setting, does Slic3er ? That was added to SuSi awhile back.
So my money is on your Z full step setting of 0.0042mm being an incorrect setting. Setting it to 0.005 also results in ;HEIGHT:0.200001 ; Layer Number: 99 G1 Z19.95 F12000
Its pretty much the only setting I can see that would make your prints taller. I've seen plenty of issues with prints being shorter, usually as they have their z speed/travel too fast and it skips steps but not bigger.
I tried printing just the first layer and the thickness was actually 0.15. I'll try making a new print by lowering the Z-axis speed--I wouldn't want that to be the problem. But I don't understand why, with Slic3r, this error does not occur. On Slic3r Z_steps is not present.
I set full Z_step to 0.005, halved the velocity, acceleration, and jerk for the Z axis, and printed a new test cube. Nothing--the height continues to be 20.47 mm.
The way I see the problem, there could be a rounding error or otherwise in the level calculation.
first level: ;LAYER_CHANGE ;Z:0.15 ;HEIGHT:0.15 ; Layer Number: 0 G1 Z0.15 F12000
last level: ;LAYER_CHANGE ;Z:19.95 ;HEIGHT:0.200001 ; Layer Number: 99 G1 Z19.95 F12000
I like it as a slicer, but if it gives me these errors it becomes unusable.
updated file:
The point is if the slicer is commanding the extruder to go to a certain height then if the printer is not going to that height then its the printer. If you can show in the output gcode where its telling it to go higher then its a slicer issue. Thats basic troubleshooting.
Now the slicer could be sending things the printer cant comply with (speeds, positions etc) in which case the settings would need tweaking but we have already seen that the slicer is more configurable than most so its a case of working out what is suitable for your printer.
Do you actually know what your z steppers steps per mm is so that the value in the slicer can be correctly set ? Can you read it back from your printers eeprom ?
What printer do you have btw ?
Levelling also has nothing to do with the slicer, its all firmware controlled. All a slicer can do is request it does a levelling pass or use an existing stored one. It doesn't slice with the knowledge of what the mesh level data actually is. None of them do.
The closest 'other' slicer is Prusa Slicer, have you tried that and does it give you the same problems.
Then, it is a printer designed and built by me, with a fixed plane of 600x600 mm useful and 600 mm useful height. The electronics is an original Duet 2 Wi Fi, powered by 24 volts, and equipped with Duex 5 expansion board. There is one motor for the X-axis, one for the Y-axis, and 4 independent motors for the Z-axis that move the XY plane up and down. The configuration is Cartesian. A self-leveling with an accuracy of less than half a tenth of a mm is performed at each print start.
To date, and in the course of assembly, I have used several Slicers, such as Cura, Ideamaker, Slic3r, and SuperSlicer. Of all these, the one I like best is SuperSlicer.... both for the configurability of the options (although there is no full Italian translation), and for the cleanliness of the working environment.
I have done dozens of tests with both Ideamaker and SuperSlicer. The problem is similar...but while in Ideamaker the dimensions are accurate...but not the print quality, in SuperSlicer I can get acceptable print quality (to be improved), but with the problem of the measured Z going beyond the theoretical value for me.
Could this be a printer problem, then an electronic or mechanical problem? I would rule it out, as all motion tests with comparator control give me an imperceptible difference--almost centesimal.
The Z movement is on Ø 12 mm round rails with SFU1204 ball screws. There are Nema17 motors from Stepperonline with P/N 17HS19-2004S1 managed through the Duet with 16 microstepping.
The speed being printed is limited to 80 mm/s, but I have already experienced actual printing speeds of 230 mm/s. This is possible due to the fact that the extruder is an E3D Hemera with Volcano hotend (also 24 volts).
The current print bed is being redone, but it is still perfectly flat.
P.S.: I am Italian and have difficulty writing in English. in fact, I am using https://www.deepl.com/translator
Sorry, even on Slic3r there is a setting similar to z_step
I installed PrusaSlicer to produce the GCode of the test cube and the result is the same:
;LAYER_CHANGE ;Z:19.95 ;HEIGHT:0.200001 ; Layer Number: 99 G1 Z19.95 F12000
https://github.com/prusa3d/PrusaSlicer/issues/4484
There is an old discussion in which they suggest using modifiers to adjust the height of the part. But this is a strong limitation for those who need to print many large pieces. You can't do a test print every time--before you print a part. My tests are currently limited to 2 similar objects, of 20x20x20 and 30x30x30 mm...and the "shift" upward is the same.
Perhaps it is a matter of adjusting the height of the layers.
Something like.
first layer = 0.15 Total height of the part = 20mm Number of layers beyond the first = 99 Height of layers = 20 - 0.15 = 19.85mm / 99 = 0.200505051
That way layer 99 should start at 19.799494998
Now that I think about it...could it be a matter of rounding the Z values?
Si tratta quindi di una stampante progettata e costruita da me, con un piano fisso di 600x600 mm utili e 600 mm di altezza utile. L'elettronica è una Wi Fi originale Duet 2, alimentata a 24 volt, e dotata di scheda di espansione Duex 5. C'è un motore per l'asse X, uno per l'asse Y e 4 motori indipendenti per l'asse Z che spostano il piano XY su e giù. La configurazione è cartesiana. Ad ogni avvio di stampa viene eseguito un autolivellamento con una precisione inferiore a mezzo decimo di mm.
Ad oggi, e nel corso dell'assemblaggio, ho utilizzato diversi Slicer, come Cura, Ideamaker, Slic3r e SuperSlicer. Di tutti questi, quello che mi piace di più è SuperSlicer.... sia per la configurabilità delle opzioni (anche se non esiste una traduzione completa in italiano), sia per la pulizia dell'ambiente di lavoro.
Ho fatto dozzine di test sia con Ideamaker che con SuperSlicer. Il problema è simile... ma mentre in Ideamaker le dimensioni sono accurate... ma non la qualità di stampa, in SuperSlicer riesco ad ottenere una qualità di stampa accettabile (da migliorare), ma con il problema della Z misurata che va oltre il valore teorico per me.
Potrebbe trattarsi di un problema della stampante, quindi di un problema elettronico o meccanico? Lo escluderei, dato che tutti i test di movimento con controllo comparatore mi danno una differenza impercettibile, quasi centesimale.
Il movimento Z avviene su guide tonde Ø 12 mm con viti a ricircolo di sfere SFU1204. Sono presenti motori Nema17 di Stepperonline con P/N 17HS19-2004S1 gestiti tramite il Duet con 16 microstepping.
La velocità di stampa è limitata a 80 mm/s, ma ho già sperimentato velocità di stampa effettive di 230 mm/s. Questo è possibile grazie al fatto che l'estrusore è un E3D Hemera con hotend Volcano (anch'esso a 24 volt).
L'attuale piano di stampa è in fase di rifacimento, ma è ancora perfettamente piatto.
P.S.: Sono italiano e ho difficoltà a scrivere in inglese. infatti, sto usando https://www.deepl.com/translator
Ciao prova questo file di italiano fatto da me, rinomina l'estensione in .mo SuperSlicer.zip
Per lo Z_step usa 0,0025 e prova con strati tipo 0.16 per il primo strato e 0.14 o 0.24 gli altri strati a seconda della qualità che vuoi ottenere.
Fammi sapere.
Allora... la lingua è ok....
Per quanto riguarda invece l'altezza... il problema persiste.
C'è comunque un problema... spesso e volentieri, anche cambiando il valore Z_step, il risultato non cambia. Nel senso che non viene preso il valore. Se è vero che quella funzione è attiva se ci sono 6 cifre decimali dopo la virgola, almeno nel mio caso le vedo solo se inserisco valori strani... come 0.00625. Altrimenti vedo solo 2 cifre decimali.
However, there is a problem--often and often, even changing the Z_step value, the result does not change. In the sense that the value is not taken. While it is true that that function is active if there are 6 decimal places after the decimal point, at least in my case I see them only if I enter strange values...like 0.00625. Otherwise I only see 2 decimal places.
For what i understand, you want some kind of z compensation?
what is the law for it? can you plot the z diff with different objects, so I can know what kind of z compensation to create? Object with different height, diferent overall sizes and different filament.
For what i understand, you want some kind of z compensation?
what is the law for it? can you plot the z diff with different objects, so I can know what kind of z compensation to create? Object with different height, diferent overall sizes and different filament.
At the moment I disassembled the bed to replace the printing mat and at the same time I have to fix one of the 4 SFU1204 ballscrews that is making noise. As soon as I get back up and running, I will do some more tests--perhaps disabling the mesh compensation function of the Duet.
Then I have to redo the tests anyway.... because my impression is that there is something that does not match, between the GCode command and the motion. And I still don't know if it is an issue related more to the slicer or the electronics.
I will redo the full calibration of the slicer, so I will also check the extrusion levels.
For what i understand, you want some kind of z compensation?
what is the law for it? can you plot the z diff with different objects, so I can know what kind of z compensation to create? Object with different height, diferent overall sizes and different filament.
The best would be a linear model (ax+b) like for horizontal errors though applying constant offsets may be hard to coordinate with horizontal expansion.
I would go with simple Z scale factor, call it Z shrinkage. In my experience PETG prints shrink about 0.25% horizontally. I haven't done good tests on vertical shrinkage because my test model had annoying tendency to curl 😞. On my recent print that was fairly tall (60mm) I have around 0.13 squish ("fixed" error probably due to Z offset and bed mesh) and about 0.06% shrinkage.
PS using OrcaSlicer but shrinkage experience should still apply 😃
New series of tests underway, but I have little time to devote to it.
I must premise that the printer is not sufficiently "orthogonal." The printing table is being redone and I am printing as best I can in cold plate. Since I have to disassemble part of the printer in order to mount the new platen, I have not yet accommodated the perpendicularity of the vertical posts to the platen. This may affect the success of the tests.
A first set of tests, with an empty cube with 2 perimeters, 2 bottom surfaces and 0 fill and 0 top surfaces, with dimensions 30x30x30, would seem accurate enough, but it also depends on how it is measured. I will test on a larger cube with 3 perimeters and good fill. X and Y compensation I can handle well. For Z, I haven't found a way to do it yet, but I also need to equip myself to measure the resulting piece better.
In any case, it would always seem to be missing 0.3mm in Z!
I will keep you posted!
Okay, maybe I got it.
I would like to have a test by other users. The size of the cube closed and 10% full is accurate. That of the cube open above and empty, however, is less than the thickness of the top surface.
I would like you to verify this possibility.
Thank you
Version
Versione 2.5.59.3
Operating system type + version
Linux Mint Cinnamon 21.2
Behavior
I am trying to print a cube of 20mm side, but despite the settings, the height of the object comes to me as 20.4 or even 20.7 mm. I tried printing the same object with Slicer and the height is perfect.
X and Y are also not accurate, but with compensation I solve.
Suggestions?