What is the problem?
I'm connecting a 3d Prusa i3 MK3S printer to a raspberry pi 3B+ via GPIO. I am not able to connect it.
What did you already try to solve it?
I have checked the cables and I have followed the PRUSA tutorial but I am unable to connect them.
Logs (octoprint.log, serial.log or output on terminal tab, browser error console ...)
Connecting to: /dev/ttyAMA0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x6a931bf0, open=True>(port='/dev/ttyAMA0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0125
Baudrate test retry #1
Send: N0 M110 N0125
Baudrate test retry #2
Send: N0 M110 N0125
Baudrate test retry #3
Recv: e\x00cho:Unknown command:0"<��O���������y�=�����\x7f�|�k�������[+������\x7f\x1eb?>�o_rd-u�O�ukj�:U���������;����;t'�Z���[ok
Send: N0 M110 N0125
Recv: uv{oz:M�\x7fe�u{��W)k�����1�����������������X Last Line: 0
Recv: Resend: 1
Recv: ok
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N0 M110 N0125
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N1 M11539
Recv: Error:No Line�������with�,�{����l����}\x7fu����]�����������{�o�����\x7f��{o��o-��>o��������o�[<�y�����_��=�X:io��o��e���������q���+�����]+����U.���� �2j�kk�ecyK��k�owo�coomqnf: "\x1a/~W.m~l\x14"()"(2)
See octoprint.log for details
Changing monitoring state from "Operational" to "Offline (Error: See octoprint.log for details)"
Connection closed, closing down monitor
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ...)
OP Version: 1.3.11
Prusa Firmware: 3.7.2-2363
Raspberry Pi OS: Octopi 0.16.0
Another log from serial.log:
2019-08-10 22:20:31,902 - Changing monitoring state from "Connecting" to "Offline"
2019-08-10 22:20:34,820 - Connecting to: /dev/ttyAMA0
2019-08-10 22:20:34,833 - Changing monitoring state from "Offline" to "Opening serial port"
2019-08-10 22:20:34,838 - Connected to: Serial<id=0x6977cb30, open=True>(port='/dev/ttyAMA0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2019-08-10 22:20:34,838 - Changing monitoring state from "Opening serial port" to "Connecting"
2019-08-10 22:20:34,854 - Send: N0 M110 N0125
2019-08-10 22:20:41,022 - Recv: u��k��k�
��mX�i�"����m�-ook
esjo>U������komm\����=���".2"(2)
2019-08-10 22:20:41,025 - Recv: ok
2019-08-10 22:20:41,038 - Changing monitoring state from "Connecting" to "Operational"
2019-08-10 22:20:41,058 - Send: N0 M110 N0125
2019-08-10 22:21:33,213 - Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-08-10 22:21:33,220 - Send: N1 M11539
2019-08-10 22:22:03,242 - Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-08-10 22:22:03,253 - Send: N2 M2118
Can you try instead to connect the Raspi using a USB-based serial cable?
I just did the test you told me about by disconnecting the GPIO and connecting the USB directly to the printer. It works perfectly, but I want it to work through the GPIO of the raspberry to have no visible cables. What could be the problem?
Connecting to: /dev/ttyACM0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x67bbe2f0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0125
Recv: Command not found!
Recv: start
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N0 M110 N0125
Recv: echo: 3.7.2-2363
Recv: echo: Last Updated: Jun 27 2019 17:35:17 | Author: (none, default config)
Recv: Compiled: Jun 27 2019
Recv: echo: Free Memory: 2021 PlannerBufferBytes: 1392
Recv: echo:Stored settings retrieved
Recv: adc_init
Recv: CrashDetect ENABLED!
Recv: FSensor ENABLED
Recv: echo:SD init fail
Recv: Error:No Line Number with checksum, Last Line: 0
Recv: Resend: 1
Send: N1 M11539
Recv: ok
Send: N1 M11539
Recv: echo:SD init fail
Recv: Error:Line Number is not Last Line Number+1, Last Line: 1
Recv: Resend: 2
Recv: ok
Recv: FIRMWARE_NAME:Prusa-Firmware 3.7.2 based on Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3S EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Regards
The GPIO connection response looks a bit like a baud rate issue or terrible noise on the receive side.
I'd check the GPIO wiring. It may need some shielding, twisted pairs, ferrite cores, etc.
2 Likes
Yep. That's where I was going by using that troubleshooting step (noise on the GPIO serial line). Also, you should know that out-of-the-box the Raspberry Pi doesn't use the good UART for GPIO serial; it uses the cheap one.
I remember writing all this up over on the Prusa forum on one of their threads but I think they deleted it. If you're (as Prusa) going to suggest using GPIO serial then you should teach your users how to do it correctly. It looks like they've at least added it to their online instructions.
From the Prusa instructions:
X. Editing serial connection
By default, OctoPrint doesn't include settings to connect to the MK3 via the serial port. Two config files must be updated and serial port added using the web interface. Some of the following codes are taken from a thread by Scott.w12. More information is provided in the following steps.
XI. Swapping ports used by GPIO and Bluetooth
The first thing to enable serial connection is to swap ports used by the GPIO (soldered pins) and the internal Bluetooth chip. We need to add a line in the config file on the boot partition.
Move the cursor to the very end and add:
XII. Disabling the serial console
Moving to another config file, where part of the code must be deleted to disable serial console.
Look for following string (text) and delete it
XIII. Rebooting RPi
For all changes to take effect, please reboot your Raspberry Pi Zero W.
XIV. Adding serial port
Last part of the configuration is in the web interface. Open your browser and type either "octoprint.local" or the IP address of the RPi Zero W. You might be greeted with the welcome wizard, please go through it first.
As soon as you arrive at the home screen, open "Settings" (top right), head to "Serial Connection", then "Additional serial ports" and insert following:
Save the change and reboot OctoPrint. After reboot, select the new port and connect to your printer.
Dear friends,
@OutsourcedGuru Thank you very much, I have followed in the first attempt the steps of the guide that the people of PRUSA had included in their manual.
@b-morgan and @OutsourcedGuru
Yesterday I did a few tests:
-
The first test I performed was to use the same RPI and same wiring but taking it out of the RAMBO box. Result: Failed
-
The second test I performed was to use the same RPI and change the wiring keeping it out of the box. Result: Failed
-
The third test I performed was to use another RPI I had out there with the two wiring described above and out of the box. Result: Failed.
I'm starting to despair of using the GPIO to hide the cables and I'm in the mind of using the USB instead.
Are you sure it's a noise problem and doesn't have to be the RAMBO connector?
I said it looks like a noise problem but there's no way to be sure unless taking steps to suppress the noise results in success. It could be the RAMBO connector but I think the only way to verify that is to switch to a new one. That's not a cheap solution.
I believe the GPIO solution is intended to be used with an RPi Zero W. After looking at the Prusa guide(s), two things stand out. One, the "cable length" is at most 18mm (the length of the pins) and two, the RPi power comes from the printer (and therefore a common ground).
It is a shame that there isn't an RPi Zero+ with more powerful components. It might be worth $10 (plus something for the pin headers) to see if that works before buying another RAMBO/Einsy board.
At the end of the day you need to ask yourself which you MUST have:
- print jobs which look great
- a printer which matches your sense of asthetic
Sometimes you have to make a compromise and I myself would rather have an ugly printer which produces beautiful parts instead of vice versa.
1 Like
It sounds like a problem I'm wrestling with but it's on a different platform (SKR 1.3 w/ a failed USB port). I've connected the Pi using GPIO and noticed I couldn't get my TFT screen working and Octoprint to connect at the same time ... after looking at the board schematics, the TFT screen shares the same serial (Tx/Rx) pins as the serial connection ... that's why Octoprint can't connect: your TFT already has those pins bound. Have a look .... hope it helps.
1 Like