Heater 3: ActualTemp: 51.4 C TargetTemp: 50.0 C SetTemp: 50.0 C Hea *** HF 3: 0 Heater 2: ActualTemp: 248.1 C TargetTemp: 230.0 C SetTemp: 0.0 C Temp Reached: YES Hea *** HF 2: 0 Heater 1: ActualTemp: 240.2 C TargetTemp: 240.0 C SetTemp: 240.0 C Temp Reached: YES Hea *** HF 1: 0 Print-State: Not Printing Layer: 1 Height: 2.470 Progress: 30% Time Remaining: 0:17:46 Machine-State: (2) Running Program Program-State: (0) Program Stop System-State: (01) System Ready Simplif圓D -> transcode -> parse -> g-code view in Simplif圓D:Ĭaptured data from the printer (Cetus3D) and translated to g-code for viewing:Ĭapture with different translation processing (more raw data like):Ĭube20x20x10_with_Ĭube20x20x10_with_.zip first test When I have more time I might do the same exercise with my Up mini to compare.ĭetailed view of the Simplified3D Version:
So we still might have transcoder related issues (precession/rounding or firmware limitation of the command parameters). So any processing quirks are more visible (factor of 5) with this printer. The Cetus3D printer has only 160 steps/mm on x/y compared to the other models > 800 steps/mm. Visualizing the captured top layer movement data inside Simplif圓D G-Code viewer shows clearly the same infill shift problem then the printed part! So at least I got the capture part working for this visualization (ignore the red lines sticking to the part, these are the hick-ups on getting data from the printer). Next I translated the capture stream back to G-code for visualization (the result still needs more post processing, so you won't be able to print it). 500 samples/sec (1000 samples/sec was also possible, but there were more hick-ups). Next I wrote a little command line tool to live capture the position information from the printer (like the data that up3dshell reports) with a high data rate of ca. Simplif圓D -> up3dtranscode -> parse back to g-code. Then drilled deeper into the issue by looking at the generated G-Code by this chain: See the picture of the 3 versions top layer for comparison.
The strange thing is that printing the same object via UP Studio or with Slic3r generated G-Code there is no shift.
The shift I noticed is not a complete infill shift, it affects only 2 sides. When printing from G-Code generated by Simplif圓D I noticed that there is a partial shift of the infill, half of the infill bonds fine to the perimeter. I wanted to share some recent findings during working on supporting the Cetus3D printer with this project. Summer starts to be over here in central Europe, so there is more time spending at the printer again.
0 kommentar(er)
