I built my lowrider with the SKR Pro board and TFT screen but I decided I’m tired of chasing the screen around the table. I have installed a Raspberry Pi running Octopi and connected it via USB to the SKR board.
Initially it seems like it all just works. Octoprint was able to connect to the lowrider, I can move the machine around using the move buttons on the Octoprint web UI and I can input commands to the Octoprint terminal and see the expected output. However, I don’t seem to be able to actually run a “print.”
Whenever I try and run a gcode file Octoprint seems to indicate that the print succeeds immediately, but the machine does not move or respond in any way. I am running a known good gcode file that has run succesfully many times when I start it via the TFT screen.
I tried looking at the terminal to see if anything helpful popped up there, but I didn’t see anything that really stood out. I notice it is reporting Recv: Not SD printing continually. Maybe this is a case of the TFT screen and Octoprint fighting for control?
Is there anyone running a similar setup that might be able to point me in the right direction? Perhaps I missed a step configuring octoprint, or there is something else I can do to try and figure out whats wrong.
So I am trying to print a file that I uploaded to Octoprint, so it lives on the Raspberry PI’s SD card, not the card in the TFT screen. So I assume when I hit print in Octoprint it is going to stream that file over serial.
I did remove the SD card from the TFT screen as well.
Ah, okay so I do actually see it doing something in the terminal now.
After sending a print I see:
Changing monitoring state from "Operational" to "Starting"
Send: N0 M110 N0*125
Recv: ok
Changing monitoring state from "Starting" to "Printing"
Changing monitoring state from "Printing" to "Finishing"
Send: N1 M400*38
Recv: ok
Changing monitoring state from "Finishing" to "Operational"
Incase it is relevant, during idle I see this on loop:
Oh, this is a good guess. I am using the mpcnc post processor by flyfisher604 to generate gcode in fusion 360. I believe that is configured to have a stop at the beginning / end of the job as a reminder to manually turn on / off the spindle. When running the file with the TFT screen, I always have to hit resume to get the job going. I wondered how octoprint would handle that, and perhaps the answer is not at all.
I believe I can disable that in the post processor, I will try that next.
I use a similar setup: Octoprint running on an RPI, connected via USB to the mini-rambo running Marlin. After I hit “Print”, the buttons on octoprint usually change or otherwise display some sort of pause/resume button, and I just have to press those at each M0/M1.
It looks like I found the problem. I uploaded the version with no stops and that ran the job as expected. However, upon uploading that file I noticed that it reported a file size of 6.2KB but all of my other uploaded files reported a file size of -. I reuploaded the file with the pauses back in place, and it worked just as you described with the Octoprint buttons changing and allowing me to press play again to resume the job.
When I intially uploaded my files, I did a big drag and drop onto the octoprint UI with everything that was originally on the TFT’s SD card. It seems there was a bug in octoprint and I ultimately just had a bunch of blank gcode files.
I have attached a screenshot of what this looked like below in case anyone else runs into this in the future and stumbles on this thread. Thanks for the help all!
