Creality CR-100

Get Help
1

Hi and thanks for having me. Ill try to be good. I'm completely new to 3D printing but have some CNC experience.
What is the problem?
The creality cr-100 is a little toy and is currently a discontinued item for $A300 at Jaycar. Made for kids and dressed up like a little truck complete with exhaust stacks. No luxuries like bedwarming etc but the magnetic self levelling bed makes it easy to unload prints.
Prints gcode produced by slic3r faultlessly from the SD card. The TF card supplied with the machine was a POC which took a few frustrating hours to figure out.
Hooking it up to my rpi 3B+ running Octoprint the settings are Marlin firmware, 115200bps this happens:

You can see where I jogged some axes to see what would happen. The delay was about 10 seconds between the command and the move. I am unable to see any data in the SD card. If I manually send a M20 on the terminal nothing is sent. M119 also fails to send. There are no low voltage entries in kernel.log or syslog.

What did you already try to solve it?
I unplugged the printer from the Octoprint machine and plugged into my other rpi running printrun pronterface. Everything now seemed to work correctly. I was able to print live but with some odd quirks. The printer would only do one block at a time. I had to press pause and resume to get pronterface to send the next block the the printer.
I can post some pronterface logs if anyone is interested.
.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)

OCTOPRINT TERMINAL:
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: Firmware_Name:BiSun
Recv: Firmware_Url:https://www.cxsw3d.com
Recv: Firmware_Ver:0.1.6
Recv: Machine_Name:CR-100
Recv: Head_Count:1
Recv: ok
Send: N2 M21*18
Recv: Echo:SD Card ok
Recv: ok
Send: N3 M105*36
Recv: Echo:Get Head(0) T:20.7/0.0
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: N4 M105*35
Recv: Echo:Get Head(0) T:20.5/0.0
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: N5 M105*34
Recv: Echo:Get Head(0) T:20.6/0.0
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: N6 M105*33
Recv: Echo:Get Head(0) T:20.4/0.0
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: N7 M105*32
Recv: Echo:Get Head(0) T:21.0/0.0
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: N8 M105*47
Recv: Echo:Get Head(0) T:20.6/0.0
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: N9 M105*46
Recv: Echo:Get Head(0) T:21.2/0.0
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: N10 M105*22
Recv: Echo:Get Head(0) T:21.0/0.0
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: N11 G91*33
Recv: ok
Send: N12 G1 Z10 F200*52
Recv: ok
Send: N13 G90*34
Recv: ok
Send: N14 G91*36
Recv: ok
Send: N15 G1 X-10 F6000*40
Recv: ok
Send: N16 G90*39
Recv: ok
Send: N17 M105*17
Recv: Echo:Get Head(0) T:21.1/0.0
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: N18 M105*30
Recv: Echo:Get Head(0) T:21.0/0.0
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: N19 M105*31
Recv: Echo:Get Head(0) T:21.1/0.0

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
OctoPrint v1.4.0
Octopi 0.17.0
kernel 4.19.97-v7+

2

Oooof....

See this? This is the firmware on this printer inventing its own temperature report. What this should look like is something like this:

Send: N9 M105*46 
Recv: ok T21.2/0.0

The ok is pretty crucial here since it signals to OctoPrint that it may continue sending lines to the printer. Unless it sees something like this it can't "legally" continue sending stuff to the printer and communication stalls, timeouts occur, communication breaks down.

In short, this either needs a plugin in OctoPrint to work around the broken ass firmware flashed on your printer, or a reflashing of your printer with working firmware. The latter is probably the easier route (also since I expect there to be more nasty surprises in what's currently flashed on the machine if they managed to fsck up even something as simple as the temperature report). I recommend to look at getting mainline Marlin flashed on this thing, if you google around a bit I'd bet that someone else has already done that. While you are at it also make sure thermal runaway protection is enabled and that the thing is electronically sound (as in, google whether you should swap something like PSU or such - cheap printers have a habit of cut corners with increased risk of fire as a consequence).

3

Well I think that explains why pronterface has to be paused and resumed in order to send the next block.
It does not help explain however why pronterface talks to it ok otherwise, whereas OctoPrint seems to have all sorts of trouble.

4

OctoPrint enforces the agreed upon protocol more strictly (as not doing that has shown to lead to a TON of issues with various printers and firmware variations out there).

5

OK Thank you. Problem solved. Uninstall OctoPrint and see if I can do some pronterface stream editing. Then print happily until this toy blows up and I get a fancier squirter, trellis, steppers, interpreter etc.
Cheers from Western Australia

Pete