Yes and no, I've had multiple cases when my uploaded, unpacked *.BIN saved the day.
Then the error cause was related to something else but in no case (!) to the packer.
I've dealing with such issues in the 80s already when downloading files via analogue telephone lines with 1200 Baud modems was horrific, CRC checks ensured integrity.
I agree that there could be issues with burning erroneus data to the mc, but the errors are related to other factors (faulty SD-Card / -Filesystem, Users removing cards too fast, even EMI).
You just created another possible error cause with that unpacked bin (HTTP download errors).
Then the error cause was related to something else but in no case (!) to the packer.
I've dealing with such issues in the 80s already when downloading files via analogue telephone lines with 1200 Baud modems was horrific, CRC checks ensured integrity.
I agree that there could be issues with burning erroneus data to the mc, but the errors are related to other factors (faulty SD-Card / -Filesystem, Users removing cards too fast, even EMI).
You just created another possible error cause with that unpacked bin (HTTP download errors).
All right, got your point. Since there was literally zero downloads of that BIN file, I've simply removed it.
Thats odd, we've never seen that 'blank error' before. Maybe something gone wrong while downloading/unpacking *.BIN file or we simply overlooked something in firmware.
It is most likely headbed thermistor error, you can try replacing whole heatbed from different printer and make test.
The blank error is coming from an M200 that's been successfully printing since I installed 1.0.0 on it (Total printing time: 633h11m). It's only recently that it's been stopping and producing this blank error (but not consistently).
I had that happen to me when I first installed 1.0.0
Switched back to 0.0.7 to print some jobs and then I upgraded again to 1.0.0. Never had a problem since.
From my limited point of view this means that the firmware had some problems while updating the first time or that some eeprom values were not deleted, initialized properly.
Updated the firmware to 1.0.0 on my M200 that's producing the temperature error ( NOT the blank error) and it ran successfully most of yesterday but on my first print job this morning it threw the error again and stopped. I'm downgrading again to stay productive........
If support would like to create a "test version" of firmware that writes a log file to my SD card.....I'm more than happy to sign an NDA and help track these errors down.
Thats odd, we've never seen that 'blank error' before. Maybe something gone wrong while downloading/unpacking *.BIN file or we simply overlooked something in firmware.
It is most likely headbed thermistor error, you can try replacing whole heatbed from different printer and make test.
I've seen the "blank" error a number of times, and I agree that it is related to the heated bed and not the extruder. I sometimes get it at the start of the first print of the day, then after a reboot everything is OK.
Another of my M200s has produced the BLANK error and terminated a 14 hour job. That's officially 4 of my machines producing either the "too high extruder temp" or the blank error. Only 1 of them is so frequent ("too high extruder temp") that I had to bump the firmware back a version to stay productive.
Finally had enough downtime to address this "Too high extruder temperature" error.
Printer started to exhibit other issues like the platform ONLY moving down so we started by replacing the original Extruder Cable and re-updating to the latest firmware. That appears to have fixed the original error (printing for 3 days since the fix without issue). We did start to receive secondary errors regarding the heat-bed and perforated plate. Swapped the perf-plate and still had issues. Ended up replacing the heat-bed and perf-plate and now it's printing like new. ;-)
I still think that the safeguards put in place are way to sensitive for the general public of machines. In small testing of their in-house machines everything might work great but out in the real world there are thousands of machines that are run a little differently from one to the next.
I still think that the safeguards put in place are way to sensitive for the general public of machines. In small testing of their in-house machines everything might work great but out in the real world there are thousands of machines that are run a little differently from one to the next.
-NS
You are absolutely right!
Batch and quality of parts from one build to the next of an M200 vary greatly as represented here on the forum, so many user post about issues that I've not experienced yet if ever, plus the mix of "Versions" of parts and software/firmware throws more variables into the mix.
My experience in mechanical design and attention to what others post here (I read the new posts every day) have allowed me to avoid most all of the issues but in most cases they where problems my machines did not have.
I keep the older versions of the desktop software (13 and counting) on my system while testing the newer, and I have 3D model of my printer with each change I've made represented and documented.