Your bed reports -45°C 
So unless you're printing at the north pole either your wiring is messed up or something is wrong with your firmware. Could also be both 
2 Likes
Either the thermistor has become disconnected or the wrong thermistor type has been selected in the configuration.h.
Your analysis is correct in a sense. I have removed all of the electronics from the metal casing that is now supplied with the X5ST-400. There is a cable connector between the thermistor and the Chitu board. One of the pins was bad. I now have a more reasonable temperature range. However, there is no configuration.h ! The firmware seems to be an encripted file on these boards. I cannot access anything with arduino style editors. I would love to install Marlin 2 but so far no luck.
I now have the same problem that I had some months back in that all connection is lost due to a failed request for "line 4" over and over again. If I block repeat commands in settings I can occasionally get the temperature to rise a little but no print.
I should add that with a file on the SD of the motherboard I did get a print so I know the printer can actually function.
octoprint.log (24.7 KB)
1 Like
I've highlighted the part that OctoPrint appears to be having a problem with. The firmware is sending //sd cmd error cnt:23 len:11 :N4 M05*35 but that doesn't include an ok with it. You didn't mention whether or not you're trying to print from the printer's SD card (not to be confused with the Pi's microSD card).
Note especially that the firmware is trying to parrot back the N4 M105*35 command but now it's missing the one from the middle of that. So the calculated checksum of 35 should fail in this case and maybe that's what the firmware is complaining about.
I'd probably troubleshoot this as a bad serial cable or bad Pi power supply or the Pi is sinking power to the printer board.
| Send: N4 M105*35
| Recv: //sd cmd error cnt:23 len:11 :N4 Ma05*35 <--------------
| Recv:
| Recv: ok
| Send: N5 M105*34
| Recv: Resend:4
2020-01-28 07:03:10,469 - octoprint.util.comm - INFO - Firmware didn't send an 'ok' with their resend request. That's a known bug with some firmware variants out there. Simulating an ok to continue...
2020-01-28 07:03:10,503 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 4, current line = 6
| Last lines in terminal:
| Recv: Begin file list
| Recv: System Volume Information 0
| Recv: wait
| Recv: End file list
| Recv: ok L:1
| Send: N4 M105*35
| Recv: //sd cmd error cnt:23 len:11 :N4 Ma05*35
| Recv:
| Recv: ok
| Send: N5 M105*34
| Recv: Resend:4
| Recv: //last:3 curr:5 rcv:N5 M105*34
| Send: N4 M105*35
| Recv:
| Recv: //callback_pf error
| Recv: //sd cmd error cnt:24 len:11 :N4 Ma05*35
| Recv:
| Recv: ok
But you might want to read this issue though. It's about the non-standard responses from your firmware.
I never use the SD card on the printer but have tried with two different cards in situ and also with nothing inserted just to see. I have two Pi units, two Pi original power supplies and several cables. No joy there either.
The missing 1 in the N4 line is bizarre. When I display the file in Notepad++ I get N4 MBEL05*35 with the symbol BEL given a black background. You have the same file showing an "a". Probably just a language thing. BEL is ASCII 7.
In order to remove all problems, if any, caused by the Raspberry Pi I have just spent the best part of an hour installing OctoPrint on a Windows 10 machine connected through USB to the printer directly. The problem is exactly the same. Failure in line 4.
Just to make sure: Have you in fact also installed the two plugins indicated in the aforementioned issue?
Yes. Both installed.
Please create a new serial.log of the current state. That will tell us more of the whole story than just the excerpts dumped into octoprint.log on resend requests. I'm note sure if the last one from December still reflects the current state or not.
In any case, this is on your printer's firmware and I suggest you also complain to your printer's manufacturer about this issue, they might be able to actually do something about it, all we can do here is suggest workarounds like the aforementioned plugins.
Also maybe try a different USB cable between OctoPrint and your printer, because from the looks of what the printer does send back it's certainly not receiving what OctoPrint is sending and that reeks of communication errors due to cabling errors and/or undervoltage (of which I don't see any hints in your logs though). Could also be that your printer's board simply has a fault.
octoprint (1).log (182.9 KB)
As requested, the log file. I have tried to contact Tronxy but they are on holiday for the chinese new year. They never reply anyway. I have tried many cables already and from three computers. The printer will only function with a file on it's own SD card.
I have just ordered one of your premium hoodies to see if that makes a difference !
serial.log Not octoprint.log
Enable serial.log through Settings > Communication first, reproduce the issue, then upload the result.
Yeah, the core of the issue definitely is that your printer is not receiving what OctoPrint is sending. For example, it receives N0 M\x0310*35 instead of N0 M110*35 and then rightfully complains about the checksum mismatch for that. Something is going really wrong in the printer communication, so swap the USB cable, make sure it's shielded, has a ferrite bead, does not run next to motor wires. Also try if you run into similar issues when connecting from a different computer to your printer using Pronterface. And finally get in touch with Tronxy on this, it might also be a broken controller board.
BEL 0x07 looks like 00000111 in binary. (It activated the bell on the original Teletypewriter that would alert the operator at the other end.)
Zero 0x31 looks like 00110001 in binary.
So this doesn't seem to be a single bit getting accidentally toggled in the transmission.
As suggested though, you first have to sort out the trashy serial setup by using a proper cable.
Temporary fix: PrintedWeezl's suggestion of dropping the baud rate would actually help. If you had the ability to adjust the Marlin setup, compile/flash that to the printer you could drop the baud rate down by half until it's happy.
I have tried five cables so far. Some very short indeed. all with ferrites
This printer does not have Marlin but uses a closed version of Repetier.
That's good about the cable(s) but sad about the closed firmware.
You might try temporarily taping the 5V pin of the serial cable as suggested by PrintedWeezl on here. The theory would be that the printer board is sinking so much power from the Pi that it's now corrupting the threshold for high/low determination on the bits.
This doesn't explain why it would have worked before and not now, though, with the same hardware.
Nor why it gives the same result when connected to a Windows computer. I am trying desperately to remember what I did around the time of the upgrade. Did I change anything else ...
I have also ordered another board from Gearbest but with the virus and stuff it may be a long time coming. At least I shall have a second unit to try a Marlin transplant with.
A second printer controller board (with a resistor which pretends that it's a thermistor) is super helpful at a time like this. You power it up, connect it to your OctoPrint setup and send it a print job where you've groomed out the heat/extrusion commands. You're then exercising everything without necessarily wasting filament.
I have tried pronterface now and it does connect and stays connected. I can control movement and temperatures but as soon as I try to print it fails with "callback -pf error" etc..
I shall post more when the second board arrives. Having two boards will enable me to try to install Marlin on one but to retain a fallback system.