What is the problem?
I used to print with my Raspberry pi 3 for many years, first with a Lorei printer, then with my Tenlog D3. I have made an update of my logic board and since then my printing almost always fail due to layer shifts. The very same gcode file printed from my SD never fail.
What did you already try to solve it?
To exclude the possibility that something was going wrong with my raspberry SD card and/or my raspberry and/or my OS, I've setup a new Raspberry 4 from scratch with a HQ SD card and the 'official' octoprint distribution. Nothing else is installed on this new raspberry. Unfortunately, I have the very same issue. Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
Link: https://d.pr/f/BaewEJ
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
OctoPrint version: 1.3.12
Octopi version: 0.17.0
Printer: Tenlog TL-D3
Firmware: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.mendel-parts.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:2
OS: Raspbian GNU/Linux 10 (buster)
You state that when you upgraded your logic board, the layer shifts started.
You need to check your slicer settings etc to ensure they are compatible with the new board. Since the issue only started with the new logic board, the Pi and Octoprint cannot be the issue
But this is the very same sliced file that is failing when printing with Octoprint and printing correctly from the sd. My new board may just be more ‘demanding’ than the former one, and may reveal a new issue with Octoprint, I don’t know...
Ok, on the first hand we have a (minor) problem with the filamentreload plugin:
2019-12-08 22:26:49,508 - octoprint.plugin - ERROR - Error while calling plugin filamentreload
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/__init__.py", line 219, in call_plugin
result = getattr(plugin, method)(*args, **kwargs)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_filamentreload/__init__.py", line 107, in on_event
if event is Events.PRINT_STARTED and self.no_filament():
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_filamentreload/__init__.py", line 99, in no_filament
return GPIO.input(self.pin) != self.switch
RuntimeError: Please set pin numbering mode using GPIO.setmode(GPIO.BOARD) or GPIO.setmode(GPIO.BCM
Way more concerning are the checksum mismatch errors:
| Recv: Error:checksum mismatch, Last Line: 31
They are all over the place. Resulting in numerous resend line requests:
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 31
| Recv: Resend: 32
| Recv: ok
Either there is a problem with the board firmware and/or the USB connection
Also concerning layer shifts: Check for the correct current of the stepper drivers and the printer mechanics.
Thank you for pointing out my problem with the FilamentReload plugin, I have forgotten to reset it after the installation on the new Raspberry 4. Now, this should be working again correctly. The /plugin/filamentreload/status returns:
{
"status": "1"
}
At any rate, I don't think that this provoking layer shifts.
I will try to change the USB cable, just in case. I have a 3rd logic board that I will test to exclude that this is an issue with the USB port on the board.
For the last point (current of the stepper drivers and printer mechanics), I do not believe that this is an issue otherwise, again, the printing from the SD card should also trigger layer shifts, which I've never seen...
If after changing the USB cable and the logic board I still have layer shift issues, this may unfortunately mean that my Board Firmware might be incompatible with Octoprint. That would be a very sad conclusion for me...
I have layer shifts with the 3rd logic board. So it is not a faulty USB connection on the board. I have fixed the filament reload issue, so this was not the issue either. Here if the partial log (I've stopped the printing when the first shift came out): https://d.pr/f/wYgMGg. I will use another USB cable. After that, well, I guess I will give up using octoprint with this printer...
I see that so far you haven't created and shared a serial.log. Try that as the final resort, if there's anything going over the serial line that might explain why the firmware drowns OctoPrint in resend requests that might maybe explain it. Also you haven't told us if the same issue happens in safe mode. Test that as well and report back.
From the looks of it, there's a ton of communication issues going on between your printer and OctoPrint.
Thank you for your answer. I am starting now a new print with the serial.log activated (was not 'on' so far). I will post it here ASAP. Next, I will try the solutions from the post you've pointed...
Something weird is going on there which looks like either there's a race condition in OctoPrint's logging or your printer is reporting ok for lines which it didn't actually yet check, or worse, extra oks. Sadly the firmware identifier string is about as generic as they come and could mean pretty much ANY Marlin version or vendor fork between 2011 and now, so chances aren't so slim sadly it could be the latter.
I fixed an issue that could explain the former in 1.4.0. The third RC appears to be very stable for people, so if you want you could try that and see if it improves things for you by switching to and updating from the Devel RCs release channel (not the maintenance one):
Even if it doesn't improve things, another serial.log from that might clarify whether the printer is indeed sending more oks than it should or it was the aforementioned issue in OctoPrint.
It's a tad weird that it requests a resend for line 29 when it should already have received 43, and somewhere around N13 the oks start to look really messed up:
I have setup my octoprint with Devel RC3. I am starting the printing, I will soon post whether the layer are still shifted and I will attach the log files.
In the meanwhile, just a quick note. With my former logic board with which I could print flawlessly, I had however an issue. The tool 1 command was not working from the 'Control' tab at first. I had to use the terminal with a command like 'T1 S230'. Then, I could use the 'Control' tab commands. Also, when I was starting a print, I had to go to the 'Terminal' tab, Advanced Options and do a 'Fake acknowledgment' to have the printing starting (it would remain stacked otherwise). With the new logic board, I don't have to do this last step (printing starts 'alone') but I still have to perform a terminal command to set the Tool 1 'manually'. I don't know if this can help to track the problem with my printer...
Impossible to print from the Devel RC3: my printer tries to print out of the frame of the bed with tensions on the belt and jumps of the motors...So, no logs to post, I had to cancel immediately...
It's the responsibility of your printer to enforce boundaries. To me it sounds like communication issues and jumbled coordinates. Frankly at this point I'd try a new firmware build.