🇺🇦 We stand with Ukraine! 🇺🇦

Layer shifting only when using OctoPrint (bis)

Layer shifting only when using OctoPrint (bis)

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

2 Likes

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...

Also, power-related problems can also manifest themselves as serial-related problems. Verify that you've got solid power.

I have the official Raspberry 4 pi power supply.

I tried with a new usb cable (insulated), same issue. I give up unless someone has an idea...

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...

Here is the serial log of another failed (layer shifted) printing: https://d.pr/f/Djbz6y

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:

2019-12-16 13:58:50,127 - Send: N10 T1*10
2019-12-16 13:58:51,737 - Recv: echo:Active Extruder: 1
2019-12-16 13:58:51,743 - Recv: ok
2019-12-16 13:58:51,746 - Send: N11 M105*23
2019-12-16 13:58:51,753 - Recv: ok T:230.0 /230.0 B:74.8 /75.0 @:99 B@:127
2019-12-16 13:58:51,760 - Send: N12 G92 E0.0000*90
2019-12-16 13:58:51,766 - Recv: ok
2019-12-16 13:58:51,769 - Send: N13 G1 E-1.0000 F1800*34
2019-12-16 13:58:51,774 - Recv: ok
2019-12-16 13:58:51,778 - Recv: ok
2019-12-16 13:58:51,780 - Send: N14 G1 Z0.400 F1000*42
2019-12-16 13:58:51,787 - Send: N15 G1 X66.179 Y98.500 F4800*124
2019-12-16 13:58:51,788 - Recv: ok
2019-12-16 13:58:51,792 - Recv: ok
2019-12-16 13:58:51,793 - Send: N16 G1 E0.0000 F1800*11
2019-12-16 13:58:51,798 - Recv: ok
2019-12-16 13:58:51,799 - Send: N17 G92 E0.0000*95
2019-12-16 13:58:51,804 - Send: N18 G1 X99.319 Y98.500 E1.1904 F1350*8
2019-12-16 13:58:51,804 - Recv: ok
2019-12-16 13:58:51,809 - Recv: ok
2019-12-16 13:58:51,810 - Send: N19 G1 X99.392 Y98.842 E1.2030*109
2019-12-16 13:58:51,812 - Recv: ok
2019-12-16 13:58:51,813 - Send: N20 G1 X99.144 Y98.953 E1.2127*104
2019-12-16 13:58:51,815 - Send: N21 G1 X98.774 Y99.198 E1.2287*106
2019-12-16 13:58:51,815 - Recv: ok
2019-12-16 13:58:51,817 - Recv: ok
2019-12-16 13:58:51,817 - Send: N22 G1 X98.429 Y99.523 E1.2457*109
2019-12-16 13:58:51,819 - Send: N23 G1 X98.184 Y99.842 E1.2602*102
2019-12-16 13:58:51,820 - Recv: ok
2019-12-16 13:58:51,822 - Recv: ok
2019-12-16 13:58:51,822 - Send: N24 G1 X97.984 Y100.203 E1.2750*94
2019-12-16 13:58:51,824 - Send: N25 G1 X97.837 Y100.606 E1.2904*88
2019-12-16 13:58:51,824 - Recv: ok
2019-12-16 13:58:51,826 - Recv: ok
2019-12-16 13:58:51,827 - Send: N26 G1 X97.763 Y100.963 E1.3035*83
2019-12-16 13:58:51,828 - Recv: ok
2019-12-16 13:58:51,829 - Send: N27 G1 X97.739 Y101.311 E1.3160*82
2019-12-16 13:58:51,831 - Send: N28 G1 X97.739 Y156.788 E3.3088*94
2019-12-16 13:58:51,831 - Recv: ok
2019-12-16 13:58:51,833 - Recv: ok
2019-12-16 13:58:51,833 - Send: N29 G1 X97.761 Y157.650 E3.3398*85
2019-12-16 13:58:51,835 - Send: N30 G1 X97.825 Y158.517 E3.3710*89
2019-12-16 13:58:51,836 - Recv: ok
2019-12-16 13:58:51,837 - Recv: ok
2019-12-16 13:58:51,838 - Send: N31 G1 X97.931 Y159.380 E3.4022*84
2019-12-16 13:58:51,839 - Recv: ok
2019-12-16 13:58:51,840 - Send: N32 G1 X98.080 Y160.237 E3.4335*89
2019-12-16 13:58:51,842 - Recv: ok
2019-12-16 13:58:51,842 - Send: N33 G1 X98.270 Y161.085 E3.4647*95
2019-12-16 13:58:51,844 - Recv: ok
2019-12-16 13:58:51,845 - Send: N34 G1 X98.502 Y161.924 E3.4960*82
2019-12-16 13:58:51,846 - Recv: ok
2019-12-16 13:58:51,847 - Send: N35 G1 X98.775 Y162.750 E3.5272*86
2019-12-16 13:58:51,849 - Send: N36 G1 X99.088 Y163.561 E3.5585*95
2019-12-16 13:58:51,849 - Recv: ok
2019-12-16 13:58:51,851 - Send: N37 G1 X99.441 Y164.356 E3.5897*84
2019-12-16 13:58:51,852 - Recv: ok
2019-12-16 13:58:51,853 - Send: N38 G1 X99.832 Y165.133 E3.6209*93
2019-12-16 13:58:51,853 - Recv: ok
2019-12-16 13:58:51,855 - Recv: ok
2019-12-16 13:58:51,856 - Send: N39 G1 X100.260 Y165.890 E3.6522*110
2019-12-16 13:58:51,858 - Recv: ok
2019-12-16 13:58:51,858 - Send: N40 G1 X100.726 Y166.625 E3.6834*110
2019-12-16 13:58:51,860 - Send: N41 G1 X101.226 Y167.336 E3.7147*97
2019-12-16 13:58:51,864 - Recv: ok
2019-12-16 13:58:51,865 - Recv: ok
2019-12-16 13:58:51,866 - Send: N42 G1 X101.761 Y168.021 E3.7459*100
2019-12-16 13:58:51,868 - Send: N43 G1 X102.330 Y168.680 E3.7771*98
2019-12-16 13:58:51,868 - Recv: Error:checksum mismatch, Last Line: 29
2019-12-16 13:58:51,869 - Recv: Resend: 30
2019-12-16 13:58:51,871 - Recv: ok
2019-12-16 13:58:51,872 - Send: N30 G1 X97.825 Y158.517 E3.3710*89
2019-12-16 13:58:51,873 - Recv: ok
2019-12-16 13:58:51,873 - Send: N31 G1 X97.931 Y159.380 E3.4022*84
2019-12-16 13:58:51,876 - Recv: Error:No Line Number with checksum, Last Line: 29

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.