Dots in Lithophane with Octoprint not with SDCard

I am new to Octoprint only started to use it a couple of weeks ago but all has been going well until a couple of days ago when I printed my first Lithophane. It came out with several (4 or 5) black dots which show up as mounts of PLA sticking out from the surface. I tried to remove or smooth one down near the top of the Lithophane and that worked fairly well but I wondered why they appeared. Because this was going to be a gift I decided to immediately print the Lithophane again but using only the SDCard and not Octoprint. The SDCard print came out good without the black dots. I do not know if I will ever print another Lithophane again but if I do is there anything I can do to allow it to be done using Octoprint and not have the black dots.

I did not try to run Octoprint in Safe Mode. At this early stage, I thought it best to ask the community in case there is a couple of well know reasons and fixes that I can remember if and when I next print a Lithophane.

Did running in safe mode solve the problem?

WRITE HERE

I have attached the systeminfo bundle as requested.

I am using Octoprint 1.7.3 and a Raspberry Pi 4 on a Ender-3 Pro. Cura was the slicer and I am using Chrome on a Windows 10 computer.

In the picture I have outlined the black marks with a red circle including the one I was able to remove with the help of a sharp knife to cut away the mound of PLA.

octoprint-systeminfo-20220404135926.zip (176.6 KB)

Hello John,

Sounds like the print paused at those points for a while and filament oozed out to build those mounts. I would check whether you have usb connection issues which force the printer to wait until sufficient new print commands have arrived.
Try enabling the serial.log and then reproduce the problem (print the lithophane once more should do).

Creality printers have a (bad) reputation with regards to USB communication. My guess is that the Resend ratio: shown in the upper left of the OctoPrint page will be non-zero. Search this forum for "creality communication error" and you should find multiple suggestions for fixes. Another useful search would be "creality EMI".

The number one suggested solution will be a shielded USB cable with ferrite beads at both ends. You may also need to put tape on the 5v pin to prevent the RPi from providing power to the controller board in the printer.

1 Like

Thanks for the input. In terms of USB communications, the Resend Ratio was Zero. I have a shielded USB cable, taped the 5V pin, and added two large mix 43 ferrite cores. One on each end and the USB cable is wrapped three times thru each core to exponentially improve the choking impedance.
serial
Next time a print a Lithophane I will enable the serial.log as suggested. When I do this what should I be looking for in the log to indicate the cause of the print defects?

Is there a better method to provide Octoprint capability to an Ender-3 Pro and not have to worry about the print quality issues? Different motherboard, different com interface, different Octoprint hardware??? Having to run from the SDCard makes using Octoprint an extra step rather than a value-added software solution.

Your OctoPrint hardware (RPi 4) is sufficient. I believe the USB serial port interface is working for the majority of users. I can't speak to whether a different motherboard would make a difference but it might.

What usually causes these "dots" is a pause in the delivery of commands. The nozzle spends too much time in one spot and the filament oozes out causing the "dot".

The obvious cause of a pause would be resends but if you didn't have any, then something else is happening. The serial log has timestamps on each line so with some additional processing, it should be possible to identify anomalies in the communication.

Another possibility is that there are too many short movement gcode commands in a row. This usually happens with very detailed prints and since I see "dots" in the flat background of your lithophane, I don't think this is the cause.

There are two possible solutions to this "too many short moves" problem but both require support in the firmware. One is MEATPACK and the other is ARCS. Below is an extract from the response to an M115 on my LulzBot TAZ 6. I have ARCS but I don't have MEATPACK.

2022-04-05 07:24:40,856 - Recv: Cap:ARCS:1
2022-04-05 07:24:40,866 - Recv: Cap:MEATPACK:0

If you have ARCS support (G2-G3) then the Arc Welder Plugin can be used and this may help with the pauses (or stuttering).

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.