17.10.1 on UM2+ Homing error drives Y axis motor negative after endstops triggered

[exileonmainstreet]

I have four UM2+ machines running TinkerGnome 17.10.1. I run the machines constantly 24/7 in a production environment. Every once in awhile, the G28 command at the start of a print will cause the head to home normally except that when the endstops are triggered, the printer will continue to drive the Y motor toward negative territory, causing a horrible grinding/vibrating noise. Power-cycling is required to recover from the error, as the machine apparently can not detect that it is in an error state.

Checking endstops after the system comes back up shows all endstops triggered. Had a look over the code but nothing jumped out at me. Any ideas?

[gr5]

It would be good to keep track of which machines have this issue. Maybe in a log book along with other notes? It might be that one of the machines has an intermittent wire coming from one of the limit switches.

[exileonmainstreet]

Thanks for the quick response. Good idea. I will keep a logbook going forward. However it happens to each of the four machines. It never happens immediately after the machine has been power cycled. All machines are down today for cleaning and maintenance. I will pull the Y endstop switches and resolder.

[gr5]

Well that seems improbable that all 4 machines would have flakey wiring on the Y limit switch. I wouldn't bother taking them apart then. More likely a bug in the software.

I would try version 16.01 which is reportedly more stable and probably has all the features you need. I'd put that on 2 of the machines to see if that helps.

[gr5]

Or if that's too much trouble try turning off geek mode on 2 of the machines. My own pet theory is that geek mode combined with other increased loads on the cpu leads to trouble sometimes.

[gr5]

I have tinker on 4 UM2 printers. Several different versions of tinker. They all seem to work fine for me.

[exileonmainstreet]

So far so good on the Geek Mode test. I've run dozens of trials and the only startup y-axis negative errors are happening on the two machines with Geek Mode enabled.

[gr5]

That's good to know. Good feedback.

Power-cycling is required to recover from the error, as the machine apparently can not detect that it is in an error state.

So I let that go before but I was hoping you could explain more. If the limit switch isn't detected the printer make a horrible sound. A loud sound. It sounds like something will break. But it doesn't. It only goes on for maybe 3 seconds max. More likely 2 seconds. Then the printer works mostly fine because it has homed close enough not to matter.

Or are you saying the Y axis moved the wrong way during homing and homed in the wrong corner such that from then on if you try to print anything it fails that as well?

Is it possible that if you didn't hit power it would have been mostly fine after that (simply it might have been off by a few mm in home position)?

[exileonmainstreet]

To clarify, the G28 homing command at the start of a print would send the print head to the left and to the back as normal.

But for some reason every once in awhile after reaching the home position the Y axis would continue to try to go out the back of the machine as if the Y-endstop hadn't been triggered (but I know it did trigger because I confirmed it later on with GCODE M119 entered manually in the Octoprint terminal window after power cycling). During the error state you could see the motor spinning, but it would overpower the teeth on the belt such that the belt would vibrate with a horrible loud sound. During this particular error the motor would continue malfunctioning indefinitely.

For example I have forgotten after starting a print on Octoprint to wait until I visually confirmed successful homing before leaving the 3D printing workshop. Some long time later I'd come out to find the printer still haplessly trying to move the print head out the back of the machine in the Y direction.

Power cycling corrects the error in that it stops the malfunction and many subsequent prints will home and work just fine. Until the error occurs again that is. Maybe one print in a dozen would exhibit this error.

Setting standard mode instead of geek mode seems to have fixed the problem.

[gr5]

Wow. That sounds like a bug. I've heard the horrible sound but never for more than 3 seconds. The printer is supposed to only move the size of the bed and no farther. So it should only try to move about 220mm and then give up and just assume it's homed at that point. This is a new bug i didn't know about. Maybe I've only had X failures in the past. The X homes at position 0 but the Y homes at position 220 (roughly). Maybe there is a sign error where it keeps going forever in the Y but not the X during homing.

No. I don't think so. More likely the arduino had a semi-crash. Most likely the homing switch works fine but the arduino gets some kind of memory error or stack error and gets stuck in some code loop forever.

[exileonmainstreet]

Just a quick update, switching to standard mode (not geek mode) seems to greatly reduce the instance of the Y-axis G28 homing bug but does not eliminate it. I will try going back to 16.01.

[jofleck]

Same bug here. My printer shows that one of my end stop switch is broken. I'm using an upgraded Ultimaker 2+. With the original firmware everything works fine,

Update: This happened only once. The machine did a horrible sound because the printhead was at the end stop and the motor tried to move the printhead. After a printer restart the error didn't occurred again.

[Sisko4]

Same here, i use TG 17.10.1 since about a month now and it happened 2 times this week. It happens right after the cooldown phase when i start a new print and don´t powercycle the UM2+. But it does not happen every time, i run this machine also nearly every day and most of the prints start without powercycling. I don´t know what is causing this, but it is for sure in a certain time frame.

[gr5]

@jofleck and @Sisko4 - almost certainly the printer has trouble reaching the end stop. Just move it a tiny bit farther from the edge of the printer. Even just 0.1mm should be enough but I'd move it more than that to be sure. I have 4 printers with TG on them. Printers I use regularly. Just now I checked and one of the 4 is on version 19.03 and the other 18.03. The other 2 printers are busy now.

[gr5]

The comment about temperature (happens before second print) makes sense. Parts of the printer expand more than other parts with heat. You have a limit switch right on the very edge of working where if you push the head to that switch by hand you probably can't get it to click (you can hear the click) if you push with minimum force. Because the head is hitting something before the end stop switch.