Octoprint with MKS Gen L

Get Help
1

Ramdomly my Octoprint connection seems to halt, it only happens while printing, in manual mode everything works fine. When this happens my printer stops printing, the nozzle remains on the same spot, the bed and nozzle remain heated and in Octoprint the printer seems as connected. I try to pause or cancel the print but nothing happens, I have to restart Octoprint in order to be able to communicate with the printer again.

I run Marlin 1.1.9 on an Ender 3, my board is a MKS Gen L, I also have the TFT28 and decided to conserve the Reprap LCD, I even managed to install an SD to the board so I can put the SD either on the TFT28 or use it with the original LCD. I can print perfectly in pronterface, from the SD of the board or even with the SD connected to the TFT. But my goal was to connect Octoprint to the printer so that I can use a webcam and remote control it.

The USB cable I use is the typical blue that comes with an Arduino, don't know if it is shielded or not, lenght 30 cms. I don't know if the problem is noise from the motors or just adjust the timeouts in Octoprint for the USB connection. My baudrate is 250000, have tried with 115200 but the issue continues to happen.

My octoprint runs in a Raspberry Pi 3 Model B Plus Rev 1.3
octopi_version: 0.16.0
python:
| pip: 19.0.1
| version: 2.7.13

I'm new to the forum and don't know how to upload the octoprint.log but the printer halted when this happened:

Send: N137178 G1 X125.596 Y96.769 E365.09249100
| Send: N137179 G1 X125.663 Y96.907 E365.0965797
| Recv: ok
| Send: N137180 G1 X125.708 Y97.03 E365.1000594
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 137180
| Send: N137181 G1 X125.789 Y97.204 E365.10516100
| Recv: Resend: 137181
| Recv: ok
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 137180
| Recv: Resend: 137181
| Send: N137181 G1 X125.789 Y97.204 E365.10516100
| Recv: ok
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 137180
| Send: N137181 G1 X125.789 Y97.204 E365.10516100
| Recv: Resend: 137181
2019-05-07 20:05:19,450 - octoprint.util.comm - ERROR - Caught an exception in the send loop
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2941, in _send_loop
entry = self._send_queue.get()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 3994, in get
item, _, _ = PrependableQueue.get(self, block=block, timeout=timeout)
File "/usr/lib/python2.7/Queue.py", line 178, in get
item = self._get()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 4037, in _get
item = self._resend_queue.get(block=False)
File "/usr/lib/python2.7/Queue.py", line 165, in get
raise Empty
Empty
2019-05-07 20:05:19,495 - octoprint.util.comm - INFO - Ignoring resend request for line 137182, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:20,033 - octoprint.util.comm - INFO - Ignoring resend request for line 137190 == current line, we haven't sent that yet so the printer got N-1 twice from us, probably due to a timeout
2019-05-07 20:05:20,078 - octoprint.util.comm - INFO - Ignoring resend request for line 137190, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:20,631 - octoprint.util.comm - INFO - Ignoring resend request for line 137199 == current line, we haven't sent that yet so the printer got N-1 twice from us, probably due to a timeout
2019-05-07 20:05:20,670 - octoprint.util.comm - INFO - Ignoring resend request for line 137199, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:20,732 - octoprint.util.comm - INFO - Ignoring resend request for line 137201, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:20,791 - octoprint.util.comm - INFO - Ignoring resend request for line 137203, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:20,855 - octoprint.util.comm - INFO - Ignoring resend request for line 137205, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,145 - octoprint.util.comm - INFO - Ignoring resend request for line 137212 == current line, we haven't sent that yet so the printer got N-1 twice from us, probably due to a timeout
2019-05-07 20:05:21,191 - octoprint.util.comm - INFO - Ignoring resend request for line 137212, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,241 - octoprint.util.comm - INFO - Ignoring resend request for line 137214, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,301 - octoprint.util.comm - INFO - Ignoring resend request for line 137216, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,361 - octoprint.util.comm - INFO - Ignoring resend request for line 137218, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,412 - octoprint.util.comm - INFO - Ignoring resend request for line 137220, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:21,451 - octoprint.util.comm - INFO - Ignoring resend request for line 137220, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:41,688 - octoprint.util.comm - INFO - Ignoring resend request for line 138187, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:41,707 - octoprint.util.comm - INFO - Ignoring resend request for line 138187, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:41,722 - octoprint.util.comm - INFO - Ignoring resend request for line 138187, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:46,595 - octoprint.util.comm - INFO - Ignoring resend request for line 138333, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:53,108 - octoprint.util.comm - INFO - Ignoring resend request for line 138582, that still originates from lines we sent before we got the first resend request
2019-05-07 20:05:54,160 - octoprint.util.comm - INFO - Ignoring resend request for line 138595, that still originates from lines we sent before we got the first resend request
2019-05-07 20:06:04,166 - octoprint.util.comm - INFO - Ignoring resend request for line 138911, that still originates from lines we sent before we got the first resend request
2019-05-07 20:06:13,909 - octoprint.util.comm - INFO - Ignoring resend request for line 139180, that still originates from lines we sent before we got the first resend request
2019-05-07 20:06:18,724 - octoprint.util.comm - INFO - Ignoring resend request for line 139392, that still originates from lines we sent before we got the first resend request
2019-05-07 20:14:48,194 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Cancelling"

Until I cancelled the print.

I think the problem is with the Raspberry somehow becuase when I connect the MKS to my computer the cable I use is not shielded and has 3 m of lenght. But I'm not an expert and very rookie with Raspberry.

Need help or advice please.

2

Looks like you solved the problem. Replace the cable with an internal/metallic shielded cable or one with a ferrite core.

3

OK, i'll buy some ferrite cores and let you know if it solved the problem. Many thanks!

4

No luck, the problem remains, put the ferrites on both ends and it's the same. If anyone can help me attached are the octoprint and serial logs in the zip file Octoprint.zip (1.5 MB). Maybe what I haven't mentioned this before but when the printer pauses on the printer display in the last line a message appears "Press any key to continue" I press the button and the print continues but I cannot leave the printer unattended. I'm very dissapointed and don't know what to do if to downgrade to Marlin 1.1.8 or other solution. Please help!!!!

5

Oh... that sounds familiar. Search the forum for that phrase. The firmware is overwhelmed because its receive buffer is full and it uses this to catch a breath, so-to-speak.

Increasing the receive buffer size within the firmware might fix this.

6

Many thanks #OutsourcedGuru! Can you explain the very basics of how to increase the receive buffer size? Or when can I read a guide or something. Thanks again for your time!

7

Try a shorter cable. The one I have is about 6 inches long and doesn't have any ferrite cores on it. I used a MKS Gen L board on my Anet E10 for months connected to my Pi. Never had a problem with it.

8

This is the one I use

9

Honestly, there's nothing basic about reconfiguring your firmware. It's an involved process using the Arduino IDE software and compiling everything to be flashed to your printer's controller board. There's a big configuration.h file that has many different settings. The assumption is that your printer manufacturer makes this available in a pre-compiled HEX file, for example as well as a zip file with all the individual parts (to include that configuration.h). The thought would be that you search in that file, find the setting for receive buffer, edit it to be more and then use the Arduino IDE software to flash your printer controller board with the new attempt.

I wouldn't be the best person to teach you how to do this. Search around and see if your printer's own forum has more advice.

10

Hello !
I have the same problem, ender 3 with mks gen L + tft32 + marlin 1.1.9
Do you have found solution please ?
Thanks in advance for share
Have a nice day
Davy

11

Hi zagg, nothing so far I believe it's a dead end. My belief is that the board just can't handle Octoprint, even I have latencies trying to print from the SD of the TFT, the only thing that works is using the SD that I wired to the board, that way it works flawlessly.

I followed what OutsourcedGuru suggested me about increasing the buffers size but the problem remains in Octoprint. I've order a new board, the BIGTREETECH SKR 1.3, since I can use the TFT display and the REPRAP display of the Ender. Haven't tried it yet. It's a lot of time and I need to clear at least 3 or 4 hours to do this change.

Sorry for not being able to help you.

12

Hi Podmore. Order it, tried it and the problem remains, it's the board in my case, for whatever reason. Many thanks anyway.

13

That's really weird. I never had a problem with the Gen L and Octoprint, but I didn't have a TFT screen connected as well. I wonder if that could be the issue? Have you tried it without the TFT screen connected?

I've now switched to the SKR 1.3 board as well and it runs without a hitch

Andy

14

Hi ! Thanks for your fast answer. Ok for all, I will make some test this afternoon. I will recontact you if I found solution. Tell me if SKR 1.3 correct the problem pls.
Hope we found solution cause I can't stay 6h arround my printer for a full print lol
Have a nice day !
Davy

15

Try it without the screen connected. From what I've just read, USB and TFT screens share the same connections. GIve it a go and let us know.

Andy

PS I could be talking utter rubbish here, but it's worth a shot

16

I will try this afternoon and post result here.
thanks for your help !
Davy

17

Hi all,
I have tested ; without TFT32 connected all its work ... Thanks Andy for the trick.
Its work on 115200bds , on 250000 I have bug with my BLTOUCH.
TFT32 share link with USB link and we have a conflict :frowning:

If anyone have idea how to use TFT32 + Octoprint simultaneous I will really appreciate :wink:

Can we use Octoprint with MKS Wifi ? (I have the shield on the TFT32)

Anyone have tested MKS 1.3 + TFT + Octoprint ? have same problem or its works ?

Thanks in advance !

Davy

18

Glad you got it working Davy, albeit not with the screen attached. I tried my Bigtreetech TFT35 screen connected to my SKR 1.3 board yesterday with octoprint, and it worked without any problems. Also had a 12864 full graphic display connected too. Like others have said though, the TFT screens are very limited in their use, as they only have basic functions, but when you need to access movement commands quickly, they are helpful.

Andy
i

1 Like
19

Thanks Andy, is SKR 1.3 better than SKR GEN L ?
TFT are limited, maybe buy SKR 1.3 for replace GEN L is useless or not ?
I use 12864 display + octoprint, TFT is disconnected.
I'm hesitate to replace my board with SKR ... :wink:

Davy

20

There's nothing wrong with the Gen L board at all really so it's basically a personal choice. I bought the SKR 1.3 and screen together at a really cheap price otherwise I wouldn't of bothered. I haven't tried pushing the limits of my printer yet though so I can't really say if the 32bit processor is making that much difference as I generally print at speeds between 40 and 60mm/s.