Communication error (printer <-> octopi)

Get Help
1

Hi,
I have a communication problem between the printer and octopi (on a RPi 3). The printer is not quite recent (EmotionTech microDelta) and runs using a teensylu (based on an 8-bits AVR).

What is the problem?

The print starts correctly. After each line of GCode sent, I got a "ok" with the line number.
After some time, the printer does not send back an "ok", but a "wait" instead. Octoprint keeps sending gcode line, and after a few seconds, some GCode lines should be resent.

During this time, the printer stops and there is a small bubble of PLA :confused:

The print is ok with a (quite old) repetier version on a laptop, so the printer is ok

I got the messages (serial.log):

[...]
| Send: N12067 G1 X-24.803 Y-9.044 E961.14217*91
| Recv: ok 12067
| Send: N12068 G1 X-24.333 Y-10.241 E961.18152*109
| Recv: wait
| Send: N12069 G1 X-23.783 Y-11.459 E961.22242*97
| Recv: wait
| Send: N12070 G1 X-23.183 Y-12.631 E961.26271*100
| Recv: Error:expected line 12068 got 12070
| Recv: 
| Recv: Resend:12068
2022-10-22 17:28:13,653 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 12197, current line = 12200
| Last lines in terminal:
| Send: N12191 G1 X-26.501 Y-3.989 E966.09617*83
[...]

What did you already try to solve it?

  • I tried to find others with the same problem
  • I reduced the speed of travels in Cura
  • I tried again with an old version of Repetier on a laptop: ok.
  • I tried to go in the sources (comm.py). It seems that supportWait setting may help. But I did not find how to set it!

Have you tried running in safe mode?

Yes

Did running in safe mode solve the problem?

no

Systeminfo Bundle

octoprint-systeminfo-20221023141534.zip (328.9 KB)

Here is the full serial.log from octopi:

octoprint(3).log (270.9 KB)

2

Looks like a faulty firmware that sends wait ("I'm waiting for more data to be sent to me") when it should be sending busy instead ("I'm busy processing what you sent already, hold your horses for a bit"). So a faulty implementation of the communication protocol by the firmware.

Two options: Flash fixed firmware, or rewrite the wait to busy via a plugin.

Quite unusual to see this behaviour on Repetier Firmware, usually we only see that with CBD/ZWLF. But the plugin for that might possibly help here too:

3

Hi Gina,
Thank you very much for your quick answer!
I think I will try the plugin way, it seems easier, as the original firmware may be difficult to recompile :/.
regards,

4

Hi,
I have tried to update the plugin. It replaces correctly the 'wait' by 'busy', octoprint do not send more data on the serial line, but the printer is still stuck :confused:

2022-10-23 21:11:46,447 - Send: N12862 G1 X17.915 Y-14.46 E1108.79599*79
2022-10-23 21:11:46,462 - Recv: ok 12862
2022-10-23 21:11:46,465 - Send: N12863 G1 X18.086 Y-13.978 E1108.81163*119
2022-10-23 21:11:47,460 - Recv: wait
2022-10-23 21:11:47,462 - Repl: wait -> echo:busy processing
2022-10-23 21:11:48,459 - Recv: wait
[...]
2022-10-23 21:12:17,433 - Repl: wait -> echo:busy processing
2022-10-23 21:12:17,434 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2022-10-23 21:12:17,439 - Send: N12864 M105*46
2022-10-23 21:12:17,452 - Recv: Error:expected line 12863 got 12864
2022-10-23 21:12:17,456 - Recv: 
2022-10-23 21:12:17,457 - Recv: Resend:12863
2022-10-23 21:12:17,462 - Recv: ok

I will first try with exactly the same gcode with the repetier tool on a laptop
Maybe should I have to update my firmware.
regards

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.