I finally got thru that calibration page, but at early stages I managed to get plastic stuck to the bed hard enough in the center and the home (back left) corner, that it can't be removed. Some of it was able to be removed after printing the calibration over it again, but some of it still wont' come off, either by preheating the bed and trying that, or at room temperature, or by removing and freezing the bed topsheet. It doesn't appear to be "in the way" of printing yet.
I think I can use the bed top sheet off the broken Ender5 if I have to (it's a bit scarred up from it's previous owner's usage).
I then thought I might try a print of a portion of a dog paw skeleton, from the elbow down, so I could use that to have in my hand to work out hinging and motor control for it for the Snuggles project. I used Ultimaker Cura to position and slice it, and was using the option to "monitor" the printer during the print, over USB. It does not actually *do* any monitoring, however, it just connects to it and reads the temperature. It also can't actually directly command the printer, though it seems to imply that it can based on the onscreen controls and options. It does not show what the printer is actually doing, either. I used the standard method of copying the gcode file generated by Cura to the memory card and put that into the printer's slot, and the onboard menu to print it.
I'm still learning how best to orient things for printing, so I incorrectly decided to print it as parallel to the bed as I could, instead of vertically, so it took a very long time (hours) to print the support material for the actual part, only printing a tiny portion of the elbow and one of the toes before something wierd happened:
The printhead stopped heating. There was no jam, no feed issue, no stringing...at some point less than a centimeter above the bed it just ceased melting the plastic and trying to feed it. Printing kept going, though, as when I woke up from actually fallling asleep from exhaustion hours later it was well above the print height for all of the object except the bit of leg above the elbow; it would have finished that part in perhaps another few minutes to half an hour, if it had been actually printing anything.
Since I had Cura open doing that monitoring thing, I was hoping it might have logged what happened, but it doens't do any logging either. But...I was using the spare Win10 laptop (that doesn't have anything else installed on it ATM but the printer stuff, and has all the background Win10 crap disabled, and no networking, etc), and while I'd disabled all the screensavers, timeouts, etc., somewhere in some setting that I don't have access to yet (probably have to do a registry hack), Win10 has a sleep timeout, not just a screen blanker, so sometime after I dozed off the laptop went to sleep. I suspect that this is the moment the problem happened, but why it would happen I can't imagine, since Cura wont' directly control the printer, and the printer was doing all it's stuff by itself, why would the laptop going to sleep turn off just the printhead heating/extruding? It didn't turn off the heated bed, nor did it stop the rest of the process.
Before I did anything else I pulled gently on the PLA leading into the (direct-feed) head, and it was definitely gripped by the rollers in there. Then I verified the printhead didn't have a problem by using the onboard menu to turn on preheat, and it very rapidly was hot enough for me to use the manual control on the head to extrude some PLA, proving it wasn't clogged or jammed and that the heater works fine.
I couldn't (shoulnd't) have been any form of overheating, as the room was <60F and I'd fallen asleep wiht the printer enclosure door open halfway, so it wouldn't have been heat trapped inside the styrofoam enclosure. (besides, I would expect an overheat or any other error to shut down the entire printing process, as there isn't any point to continuing if the printhead isn't doing anything).
After a bit of poking around online to see what programs *could* directly control the printer and hopefully log the process, and finding that most that say they will do it are reported in various forums' posts to not actually work for that for one reason or another (including Cura), I decided to try out Printrun/Pronterface+Slicr, since that is reported to correclty work (with this specific printer even) and not only monitor a print but actually direclty print over the USB, and even display the printing progress graphically. Turns out that part of that grpahical monitoring doesn't actually work because Slicr can't generate correct "SVG" code that it itself can read or that Pronterface can read either, and both of them generate errors trying to do so, regardless of the model I tried to do this with. But it does draw the layers as they print (or rather, it turns them from red to green) in the top-view-only of the bed / progress view of Pronterface.
I successfully used it to print that little wolf-head that failed to print using the Creality software, though Slicr's "supports" are wierd--they get placed not only below the object, but *above* it in some places, where it is most definitely not needed. Since it doesn't show you in either Slicr or Pronterface what those supports are going to look like (they can't be made visible for some reason), you can't know what wierdness it's going to do or how much time and plastic will be wasted by it. (and you can't edit the supports in any way). This print was tiny, only a couple of centimeters across/high/wide, so no big deal, but it would be at least annoying to have this happen on a large print.
But neither Slicr or Pronterface have much in the way of control options (unlike Cura) unless you know and write Gcode to send along with your print to do these things, or manually edit the gcode files generated, etc. So I'll probably stick to using Cura to generate the gcode and use the memory card to print from using hte onboard printing control panel, as that worked well enough before the problem. I just won't connect the printer via USB to the computer, and then the computer can't cause any problems with the print process. Hopefully that will prevent having that same problem again.
I'm testing that theory now using a portion of a different paw that will be more like 1:1 scale ratehr than the 1:6 scale I was printing as a first test, and this one is printed vertical, using trees instead of normal supports, and it shaves a couple hours off the print time estimate to 9 hours+ instead of almsot 12.