Printed, worked great. Printed again, got this:
Currently printing again, looking good again.
I wonder if the cable got jammed, or if the printer just needed an M999? (I have it one before the last print).
Using octoprint.
After I removed the runaway skirt:
Check the machine profile in your slicer.
Are you using Cura Lulzbot Edition or another slicer?
The printer definition should define the print area … you’d want to check to make sure those are correct.
If using Cura Lulzbot Edition you can go into Preferences → Printers and add a new printer, then select the correct LulzBot model and printhead model and it will define the printer settings correctly.
If using another slicer, you’ll need to enter all the dimensions manually.
I’m a bit confused about your use of M999. That’s not a G-code command that you would normally issue. It is designed to restart a machine that was stopped due to an issue.
Did you modify your start G-code or manually send an M999?
Start G-code will have a G28 (home all axes) before any commands that drive the print head toward the bed (e.g. prior to leveling or starting any job.)
Thanks for your thoughts.
Cura lulzbot, but it is not the slicer or settings–at least that is not a logical place to look based on my experience at this point.
From the above image, it did the first skirt circuit correctly, then went off the rails so to speak, for the next two skirt circuits.
And from the description, I had printed this file before (and am printing again right now) without the mishap.
I issued M999 manually after the mishap via the terminal after I cancelled the print, because clearly something was wrong. I also rebooted the raspberry pi / octoprint after that.
It was a one off though. So either a communications issue with a bad protocol that doesn’t detect or handle errored packets correctly (unlikely but possible), or a power surge (unlikely but possible), or a single event upset (unlikely but theoretically possible), octoprint and/or embedded linux bug (possible)…but I am wondering about the cable getting physically caught between the back of the bed and the y axis frame, as it does hit the back of the enclosure I have the lulzbot in.
But given the same file worked 1 time, failed, and is now working again, I think we can rule out the slicer and the file it produced.
Thanks for the tip about that G28, though…I do think that will come in handy in my future!
I don’t own a Sidekick… do you know if it has physical bump-stop switches OR does it use the “bump sense” system (bump-sense is based on the board firmware sensing the motor has run into resistance. My TAZ Workhorse uses physical bump-stop switches. My TAZ Pro uses bump-sense on the X & Y axes.
I ask because … if it ran into resistance, it can trick the printer into thinking it hit a limit and that can result in an axis being shifted. This can also be the reason for layer-shifts on prints.
Bump sense is adjustable depending on if it is too sensitive to resistance … or not sensitive enough via M914 (TMC Bump Sense).
The Sidekick has no switches, it uses bump sense to home the X and Y and homes the Z axis by going down to the bed with the BLTouch deployed to find z=0.
But running into resistance while the print is already in progress shouldn’t cause it to think it has hit a limit. The firmware isn’t watching the bump sense while printing, only during the homing process. So the resistance would have to be bad enough to actually make the stepper skip steps and loose position to shift the print.
Same thing applies to the Workhorse with switches. Try manually pushing the switches with your finger while printing and nothing will happen.
I’ve learned from experience that if something creates too much resistance during a print with TMC Bump Sense… the printer can layer-shift.
Also… if you press the mechanical limit switch on a TAZ Workhorse (mechanical limit switch rather than bump-sense)… the printer will refuse to move in the direction where the limit switch is pressed. It will believe the print-head is already hard against the switch and refuse to drive the head farther in that direction.
I don’t see any bump-stop or mechanical switches that the bed or carriage would hit.
Then it is likely “bump sense”. The bump sense (TMC Bump Sense) uses firmware to detect that the motor has met with resistance (because the amperage needed to drive the motor goes up and the firmware notices this and treats it as though it has hit the limit of travel for that axis).
If a part warps and a nozzle meets with resistance trying move across the warped up surface … it can trick the printer.
You can do a G28 to home all axes … and verify that the home position is correct.
So this weekend I was all ready to argue that what I said about the limit switches and bump sense not being active during a print was true. I’ve spent nearly every work day for the last two years working with these printers and surely I would have figured that out if it were true. 
Well, it turns out I was half wrong and half right. The limit switches are active during printing. Bump sense does not appear to be enabled, on any of the printers I tested.
I tried my Mini 1 at home with the burn-in gcode running and when I clicked a switch it refused to move in that direction and instead just did the moves in the opposite direction, which did cause it to shift it’s position. I thought maybe that was just the older firmware, 1.1.9.34, that it had, so I updated to 2.0.0.144, newest available for the Mini 1, but it behaved the same way.
So I waited until today when I could go to work and test this on a Mini 2, Workhorse, and Pro. Didn’t have a Sidekick handy to check.
The Workhorse, with 2.0.8.0.9 firmware does react to the X, Y, and Z switches during the print.
The Mini 2, with 2.0.9.0.9, does react to the Z axis switch and refuses to move up.
The Pro, with 2.0.0.144.6, does not react to the Z axis switches during a print. And I did remember that you have to press both Z limit switches at once. It ignores the Z axis switches during printing.
The Mini 2 X and Y axes and the Pro X and Y axes did not trip bump sense when I held against movement during a print. The motors all pushed as hard as they could until they started buzzing and rattling and skipping steps. They continued to push against me as I held them from moving in the direction of travel, pushing with way more force than the amount of force that would trip the bump sense when I pushed against them while homing.
When I get a chance I’ll try a Sidekick.
So in summary, for the configurations I tested, limit switches are active, bump sense is NOT active, during a print.
Thanks for the follow up
