FLSUN Super Racer issues with Octoprint

Get Help
1

What is the problem?

I have these TWO issues with Octoprint/USB port on my Super Racer with Robin Nano V3 board.

Issue #1 - When USB plugged in, there is a delay in startup
When the USB cable is plugged in (Octoprint is not connected to serial yet, just plugged in), when I start the printer, the screen shows no sensor output for 5 minutes. After about 5 minutes, the sensor temperatures show up and everything can be controlled as normal. I cannot connect to the printer from Octoprint via serial until this delay is over. Once the delay is over and the temperature values show up, I can then make the serial connection. Why does this delay occur when the USB is plugged in?

If I unplug the USB cable and start the printer, it immediately shows the sensor temperature. It only happens when the USB cable is plugged in.

Photo of the first state (first few minutes): https://files.catbox.moe/8lx1y6.jpg
Photo of the second state (5+ minutes): https://files.catbox.moe/sziykl.jpg

Issue #2 - When octoprint connected, sometimes axis do not work properly

This is a scary issue because it causes the effector to be moved in a position that is unsupported, causing the arms to break off!

Please look at this video: https://drive.google.com/file/d/1pUSSXZjLaO840xoC2WcEi5B7LKvXauIw/view?usp=sharing

In this video, I am moving the z-axis down using the on-screen controls. But notice, the effector does not move down, it moves sideways. That is because sometimes one of the axis will not move. The other two rails will move up and down, but one seems stuck. This only happens when Octoprint is connected (and only sometimes).

To be clear, if I unplug the USB and start the printer normally -- it works fine and this problem has never occurred like that.

In summary:

  • If I start the printer without the USB connected everything is fine (it boots quickly AND it travels up and down with Z correctly).

  • If I start the printer with the USB connected it has a problem (it boots slowly AND it travels left/right with Z incorrectly).

  • If I start the printer without the USB connected, then connect the USB and connect Octoprint everything is fine.

What did you already try to solve it?

  • Re-flashed stock firmware
  • Installed a Power BLough-R | Hackaday.io for the pi's USB port
  • Contacted the manufacturer of the printer (FLSUN) they could not help me
  • Asked in the Super Racer facebook group. Others have reported seeing this issue but nobody seems to know what the cause is.

Have you tried running in safe mode?

Nope

Did running in safe mode solve the problem?

I didn't try this yet, but I will, and will update this post after doing so.

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

https://files.catbox.moe/36mf79.zip

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

  • Printer: FLSUN Super Racer
  • Mainboard: Robin Nano V3.0
  • PI: Raspberry Pi 4 w/cooling fan case
  • OctoPrint: 1.6.1
2

Hi :slight_smile:

Unfortunately your problems are firmware issues and we can't do much about them.

One option would be to buy a usb hub with ports that can be turned on and off via a button or switch and to connect the printer to the pi when it's booted.
grafik

Just curious - what did they say?

3

Unfortunately your problems are firmware issues and we can't do much about them.

Yeah, I figured it probably was something like that and there was not much that could be done. But I figured I've wasted so much time on this, it was worth a shot.

Just curious - what did they say?

We had a back and fourth and there was some confusion about my problem but ultimately:

Hi friend
I'm very sorry, we haven't encountered such problems before. I have contacted my colleagues in the testing department to install Octoprint for testing, and I will contact you in time if the results are available.

4

I reeeeaaaallly doubt that it has anything to do with Octoprint. Pretty sure it's serial connections in general.
You said you know that you can establish a connection when the values show up.
So I guess you already tried to let it boot and then connect Octoprint.
Which means Octoprint wasn't even involved at that point - the printer was just connected to a pc (or a pi).

5

So I guess you already tried to let it boot and then connect Octoprint.
Which means Octoprint wasn't even involved at that point - the printer was just connected to a pc (or a pi).

Yes your summary sounds right to me. Just the presence of having some active USB device plugged in (but not even connected via serial) seems to be triggering this phenomenon.

6

Well fingers crossed - maybe the find a solution.

In the meantime I would either buy such a hub or wait until the printer is ready and then power up the pi.

1 Like
7

you can also control usb in software: install GitHub - mvp/uhubctl: uhubctl - USB hub per-port power control
and execute scripts to turn usb on or off, by button or what-not
note: for rpi it's all-or-nothing though, not / port

8

I just wanted to follow up in case anyone finds this thread in the future on Google. Upgrading to this custom firmware solved both issues for me https://github.com/Guilouz/Marlin-SuperRacer-MKS-Nano-V3

9

thanks for this link. Sorry for the late response, but were you using version 1.3 or 1.4 of the firmware? im having this same problem.

10

I am using super racer version 1.4 and have had similar issues. Even on a complete power cycle the octoprint z control was moving the head in the x-y direction. There were two times that octoprint moved the head beyond its limits - once where it snapped off the guides.

Octoprint had been working fine for a few prints but the problems all started when I cancelled a print. Then nothing worked right.

I deleted the printer profile and recreated it. All is back to normal - I think.

As far as the usb side - I had octoprint disconnecting a couple of times. I slowed the transfer to 57kbaud and that cleared up.

Still - I think Octoprint got lost somewhere and started sending the wrong gcode for basic control.

I have never had an issue with the super racer running from an sd card.