I'm using octoprint for android and I hit an issue with USB communication. When printing sometimes the "ok" acknowledgement comes with temperature data and it messes up the data feed. This interupts print and causes some layer shifting, or total stack.
I'm not sure if this is issue with this implementation. The problem can come from marling itself. I'm just giving it shot, to gather more info.
Steps to Reproduce
connect to printer via usb
send M105 continously, or lister to firmware temperature stream, then send any other printing command like G's or another M's or just fake some printing
watch feed
Recv: T:207.09 /210.00 B:59.96 /60.00ok <--- THIS IS THE PROBLEM
Recv: T:206.94 /210.00 B:60.18 /60.00 @:40 B@:5
Recv: T:206.61 /210.00 B:60.20 /60.00 @:42 B@:3
Recv: T:206.31 /210.00 B:60.08 /60.00 @:46 B@:25
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.
Send: N140 M105*34
Recv: ok T:206.31 /210.00 B:60.08 /60.00 @:46 B@:25 <--- THIS IS OK
The longer is intervar between reading temperature data, the less is a chance to interption of printing.
Expected behavior:
The temperature data should not mix with "ok" ack's or any other output.
Description
I'm using octoprint for android and I hit an issue with USB communication. When printing sometimes the "ok" acknowledgement comes with temperature data and it messes up the data feed. This interupts print and causes some layer shifting, or total stack.
I'm not sure if this is issue with this implementation. The problem can come from marling itself. I'm just giving it shot, to gather more info.
Steps to Reproduce
The longer is intervar between reading temperature data, the less is a chance to interption of printing.
Expected behavior:
The temperature data should not mix with "ok" ack's or any other output.