Timecodes for the layer shifts are in the corresponding .txt files
My Linear Rails (Particularly Y) are in a pretty bad way, so it could be that (SM have said they will replace)
However, it is interesting to note that I have had numerous (8+) fails of this print, and all of them fail at about the same Z height, and in both of the videos, there is no Z stepping going on at the point of the failure.
FYI, the “Pause 01.mp4” file is another (probably unrelated) issue - see this GitHub issue and this thread.
Interesting. Are you using the latest firmware? Seems like whatever is happening is not happening at the toolhead. Perhaps the cable chain or filament tube is getting caught up/pinched somehow? You mentioned that it’s happening at approximately same z height every time? Watching as it happends is probably a good idea. I would pay extra attention to the cable chain and filament tube…
Regarding the pausing, seems like a slicing issue. Probably minimum layer time. Have you looked into that?
Ah I see. You´re using octoprint? Maybe try uploading same gcode to the printer and print without usb connection. Perhaps the layer shifting problem are related to the same source as the pausing problem? I haven’t tried octoprint on my J1 but from what I’ve read here on the forum, the j1 and octoprint is not a great combination. At least not with past firmwares and i would assume, not with the latest firmware either…
Seen layer shift also when printing from the printer memory
USB 1.0 would be plenty fast enough - it’s an 18MB file, so to transfer the entire file would take <2 mins even on USB 1.0, and it’s a 3 hour print job
As per the issue I posted, the problem is almost certainly that the Marlin config of the J1 is not appropriate for use with Octoprint. See here for recommended values.
As you can see in the J1 source code, the buffer sizes are way too small (Or even disabled entirely)
The default Marlin values are conservative, even for a normal speed sprinter. For a high speed printer, they are woefully inadequate
