Partial infill shift with Simplify3D

[kscheff]

Hi everyone listening to this project,

summer starts to be over here in central Europe, so there is more time spending at the printer again. I wanted to share some recent findings during working on supporting the Cetus3D printer with this project.

When printing from G-Code generated by Simplify3D I noticed that there is a partial shift of the infill, half of the infill bonds fine to the perimeter. The shift I noticed is not a complete infill shift, it affects only 2 sides.

The strange thing is that printing the same object via UP Studio or with Slic3r generated G-Code there is no shift. See the picture of the 3 versions top layer for comparison.

Then drilled deeper into the issue by looking at the generated G-Code by this chain: Simplify3D -> up3dtranscode -> parse back to g-code. There I could not see any issues.

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. 500 samples/sec (1000 samples/sec was also possible, but there were more hick-ups). 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).

Visualizing the captured top layer movement data inside Simplify3D 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). I also looked on all the other layers. This shifting is in all layers present.

The Cetus3D printer has only 160 steps/mm on x/y compared to the other models > 800 steps/mm. So any processing quirks are more visible (factor of 5) with this printer. So we still might have transcoder related issues (precession/rounding or firmware limitation of the command parameters). When I have more time I might do the same exercise with my Up mini to compare...

Overview of the 3 versions printed:

Detailed view of the Simplified3D Version:

Simplify3D -> transcode -> parse -> g-code view in Simplify3D:

Captured data from the printer (Cetus3D) and translated to g-code for viewing:

capture with different translation processing (more raw data like):

Original STL: Cube20x20x10_with_hole10.stl.zip

Sliced G-Code from Simplify3D: Cube20x20x10_with_hole10.gcode.zip

captured position data: Cube20x20x10_with_hole10.Cetus.capture.zip

Back translated captured print data: Cube20x20x10_with_hole10.Cetus.capture.gcode.zip

[kscheff]

I found some time to analyze also the UP mini.

Execute abstract: The same misalignment pattern can be seen on the UP mini prints. However the amount of shift is much less compared to the Cetus3D printer. This difference in magnitude can be explained with the big different steps/mm settings of the two printers. The mechanism behind this misalignment is due to rounding issues between g-coder translation to umc and the printer firmware.

Here you see the picture of the top surface of the test object (cube 20x20x10mm3 with a centered hole of 10mm):

Here the original G-code view:

the captured movement data translated back to g-code and view to the top layer. The issue is best seen on the irregular hatches, since the printer needs to go around the inner hole. As a result the hatches do not fit together well:

Here the 2nd solid Layer from the bottom (this one has less capture artifacts):

Here are the source files of all this: C_mini.zip

I believe the issue is still rounding problem, which simply sums up on the hatch pattern compared to the inner circle with much less moves. The visual appearance of the actual print and the visualization of the captured data match well. So I believe we can now proof that the reported positioning data from the printer is the real movement of the head. So if we send down some move commands the USB pipe and the printer responds with a different final position than we expect, it means that we either need to choose other p1, p2, ... values which generate less or no error or we have to understand the resulting error and correct them.

[kscheff]

Finally I identified the issue in the calculation and error tracking implemented in the up3dtranscoder (hoststepper.c see pull request #40)

The issue was that the calculated MoveL parameters were wrong. Here I have done an example spread sheet showing the calculation for the MoveL distance in steps. The new formula refers to the plug request #40.

I have verified the fix on my Up mini and Cetus3D printers 🎱

[kscheff]

Since this repo is not maintained in the last months and I can't get any response, I have decided to setup a fork under a public organization called UP3D-gcode/UP3D and included the #40 fix. All binaries and source is available there: https://github.com/UP3D-gcode/UP3D/releases

[MaikStohn]

Thanks for your findings,

this repo is maintained by be in my free time, so sometimes it can take some time (some weeks) for an answer.

I will try to catch up with your changes and merge them in.

New development from me starting soon.

Maik