So printer has been working fine accepting commands like m115 and g1 and such.
However, it stopped responding to such commands.
The serial cable is fine, I tried it with another printer and it worked. I tried all the dtr/rts settings and it isn't that as the settings worked before and hasn't caused an issue. The BAUDRATE is correct at 115200 and no issues there. The port on the raspberry connected to the MCU is fine. And, I installed Klipper firmware from Repetier-server and it worked, proving that the connection works fine as it can use the same port to write to the MCU. When Klipper was installed it could respond to commands so the actual serial port connection is fine. However, when I reinstall the Repetier-firmware I get the same issue, the thing starts, spits out data but ignores all commands send to it.
Mesg:12:56:43.885: Dtr: true Rts: true
Mesg:12:56:43.885: Connection started
Mesg:12:56:43.885: Printer reset requested - emergency:false
Mesg:12:56:43.885: Dtr: false Rts: false
Mesg:12:56:43.906: Dtr: true Rts: true
Recv:12:56:44.327: Connection verified by:start
Recv:12:56:44.328: Printer reset detected:start
Send:12:56:44.329: N0 M110 N0
Recv:12:56:44.332: Detected EEPROM version:20
Recv:12:56:44.336: Info:Autoleveling enabled
Recv:12:56:44.344: Transformation matrix: 0.999993 0.000000 0.003764 0.000008 0.999998 -0.002148 -0.003764 0.002148 0.999991
Recv:12:56:44.348: Free RAM:84360
Recv:12:56:44.348: SD init fail
Mesg:12:56:46.133: Warning: Seems like we missed a ok - continue sending.
Send:12:56:46.133: N1 M999 ; In case we did not reset recover from fatal state
Mesg:12:56:48.136: Warning: Seems like we missed a ok - continue sending.
Send:12:56:48.136: N0 M110 N0
Mesg:12:56:50.139: Warning: Seems like we missed a ok - continue sending.
Send:12:56:50.139: N1 M105 ; fetch first temperature
Mesg:12:56:52.142: Warning: Seems like we missed a ok - continue sending.
Send:12:56:52.142: N2 M105
Mesg:12:56:54.141: Warning: Seems like we missed a ok - continue sending.
Send:12:56:54.141: N3 M105
Mesg:12:56:56.144: Warning: Seems like we missed a ok - continue sending.
Send:12:56:56.144: N4 M105
Mesg:12:56:58.147: Warning: Seems like we missed a ok - continue sending.
Send:12:56:58.147: N5 M105
Mesg:12:57:00.150: Warning: Seems like we missed a ok - continue sending.
Send:12:57:00.150: N6 M105
Mesg:12:57:02.153: Warning: Seems like we missed a ok - continue sending.
Send:12:57:02.153: N7 M105
Mesg:12:57:04.152: Warning: Seems like we missed a ok - continue sending.
Send:12:57:04.152: N8 M105
Mesg:12:57:06.154: Warning: Seems like we missed a ok - continue sending.
Send:12:57:06.155: N9 M105
It will just continue like that forever. I have reinstalled the firmware and restarted both the MCU and the raspberry several times and everything. No idea how to troubleshoot this.
Seems to me as if the repetier-firmware is in a refuse command mode similar to that mentioned here:
“However, for some errors and firmwares not in all cases a message is send, so it will look just like the printer is not responding any more when the printer goes into “wait for reset” mode.”
“We detected that on linux systems the drivers for some serial chips might get into a problematic state where they only send data but won’t receive anything which then causes the timeouts you see.”
“You find this in the serial connection definition under the name “USB Reconnect on Timeout”. Enable it and try if this fixes the problem when detected”
I tried this usb reconnect on timeout and did not help anything. It prints "start"(and the following info) and "wait". But never responds to any command. As if it does not receive them, but it does, since when I have Klipper installed it sends back ok, and I can install other firmware. They commands are just ignored.
Is there a possibility that the "refuse command mode" get's saved in-between installs? perhaps in an EEPROM or something?
I did try connecting directly to the MCU with my laptop as well using Arduino IDE serial monitor to send commands but it is the same case. I get "start" and the info and then just "wait" no matter what command I try. This used to work previously as well.