Taller LR3 build

I recompiled the firmware and reflashed it, didn’t make much difference.

So far the only thing that really helps is starting with a cold board. When I turn it on after a while of not being used, it works well for 5-15 minutes or so, homing is really accurate. After the first homing, I can hear the endstops clicking simultaneously at the same time, so both sides are aligned. Works perfectly for the first 10 or so attempts. And then some minutes later, things start to get strange.

I will see if I can modify the firmware to spit out some more debugging info about what happens during the homing process.

I looked at the marlin code and enabled some debug info about what is happening during the times when endstops fail. Long story short: marlin works in an infinite loop, executing some gcode, then checking for endstop changes, sd card changes, etc, then starts over: executes some gcode, checks for endstop changes, etc etc.

In my case the problem is that the endstop event handling is delayed. Marlin does see the state change, but sometimes it happens immediately, sometimes after some milliseconds and sometimes after half a minute. There can probably be a million reasons for this. Figuring out which part of the program blocks for so long would probably take forever, especially when all debug info needs to be sent to a serial port and some Marlin modules don’t have it defined.

I’m assuming this is either a hardware problem with the card, or marlin firmware bug (not very likely if it works for everyone else). It is probably time to order another card.

Debug info below. The problem is somewhere along the 3 “busy processing” lines. It keeps spinning the motor for way too long until the endstop state change is finally handled.

Not the pins, the heatsinks themselves. Make sure they are not making contact with any pins or the potentiometer. This used to happen with big heatsinks on the A49’s years back.

Just checked it - the heatsink has cutouts at the bottom to prevent this from happening. Not touching any pins for sure.

Downloded the latest Marlin 2.1.1, went through configuration, compiled, flashed - same problem. The day is pretty much wasted :slight_smile: Ordering new card.

Also try just M119 a bunch of times when not triggered. Wiring to the endstops could be intermittent.

2 Likes

@jamiek I did about a few thousand times. But it is possible that your comment fixed my problem :slight_smile: Not sure yet.

Thing is: I can’t execute M119 command while the motors are homing or doing any other movements. If I send M119 while it is homing, I will only get the response after it has homed and the steppers are idle(r). The holding power is set to 80% of moving power in the firmware. So basically whenever I send M119, the motors are not working at their max.

So… if there is interference from the motor cables, M119 might not show it.

Next thing I noticed is that the endstop LED indicators may not always correspond to the values that Marlin sees. The LEDs are ON even when I reset the board and Marlin has not even booted. Marlin also has noise canceling and pullup/pulldown features, which probably means that in some circumstances it may think the endstop is open even though the corresponding LED might be happily shining.

Regarding the cables, I used a slightly thicker cable for the endstops, because that’s what I found in the local store and “thicker is better” anyway. Now I’m also thinking thicker might also be better for catching interference :smiley: And the endstop cables are all packed together with the motor cables in nice black sleeves.

With the suspicion that the motor cables can actually interfere with the endstop cables, I lowered the Y/Z power from 900 to 500 and did about 50 auto home cycles without any issues since then.

Yet another update :smiley:

Lowering the motor power certainly helped! Then I decided to up the power again and see if I get the same problems again. Homing started to fail, but not immediately, after several minutes.

Then I lowered the power again, and the problem went away, but also after several minutes.

So at the moment homing works better when the board is cold and it also works better with the motor current down.

I need a beer.

When the motors are enabled, there is the max current flowing through them. As it sits there, the power is turned on and off with pwm. When they move, the direction of the current changes. The direction changes every 0.16mm.

It doesn’t work that way. The interference will have less resistance, but so will the signal. The signal to noise ratio is what matters. And it should be very strong, when the endstops are wired normally closed.

EMI is complicated. But the major component is that the area of a loop and the change in electric field cause a current to flow through the loop. If the area is larger, or the changing field is larger, you get more emi current. The electric field is changing quite a bit, because the motors are sending a lot of current and it is turning on and off. The loop is the area between the stepper wires. That is why cat 5 had twisted pairs. Each twist changes the direction of the loop, so they mostly cancel each other out, which lets many pairs transmit in the same sleeve. Replacing the wires with twisted pairs would reduce the emi, but shrinking them would reduce the signal as well as the noise. Unless I missed something. EMI is complicated. Since there are normally closed endstops, there should always be a current flowing through the wire. The current hours from 5V to the signal, through the endstop, and back down the ground cable. There should be about 1mA all the time, which should be much higher than the emi current.

You can reduce the noise through force. You have a loop to ground that is sometimes open. You can wire in a capacitor between signal and ground. When the switch opens or closes, the response will be slightly delayed (proportional to the size of the capacitor). That will make short most blips go away, but make the accuracy a small amount lower.

The thing that makes this hard to believe is that a lot of the firmware from MarlinBuilder releases has been used by hundreds of users and we have had thousands on previous versions. There is a first time for everything, but we haven’t changed anything in months.

I have spent a lot of time looking at logs, only to find out that the logs change the timing. I worry the logs are a red herring. But there is a first time for everything.

You said you are changing speeds. What else is different from stock? Have you done an M502 to restore all the settings?

There is a first time for everything. But in an effort to fix your problem: Why are you the only one having this particular issue? What about your software or hardware makes it different?

Maybe not the only one? Is this the same issue?

I had a thought…

Intermittent issues with the endstops is a weird one, should never happen. The software doesn’t care if the board is warm or cold, and the actual temperaturs doesn’t really change much from a “cold boot”

What might happen though is a voltage dip. If the voltage on the stop line doesn’t rise enough when the circuit is opened, it could do somethingmlike that.

A couple thongs to check:

  • Put a multimeter on the 5V line. If it dips at all, then it coupd be a bad or.weak regulator. Those could be supplemented with an external 5V PSU. You are looling for a dip in the voltage when the motors are operating.

  • Also check the signal line voltage. A mumtimeter should not draw enough to change the voltage any, but check that it is very near 0V when the switch is closed (not stopped) and higher than 2.5V when the circuit is open (at endstop) this is the voltage that you get with the pullup resistor “feeding” the signal line while being drained by the LED indicator.

  • If the 5V rail is not sagging, try an extra pullup resistor. Iirc the pullup resistor onboard is 470k. 5V going through 470k isn’t a lot of current, about 1mA or so. The signal line can handle literally 100 times that much. Another 470k between the 5V pin and signal pin would double that, and using something like a 220k would be safe and definitely signal a logic high. This could.elimimate noise issues. It could also make the difference if the logic pin is sagging because of the LEDs.

  • Noise could be a problem, too. Crosstalk from the motor drivers could be confusing the logic board. The higher current draw from additional pullup resistors should drown out any noise keeping the open circuit from triggering.

  • More extreme, but power efficient and noise proof is to wire your stops with 3 wires. On the switch, there is NO, NC, AND C. (Normally Open, Normally Closed, and Common.) (+) goes to normally open, (-) goes to normally closed, and (s) goes to common. No resistor should be needed, but a 220k resistor could go on the positive pin for short circuit safety. This will give a direct connection to 5V when the switch is triggered for a very definite logic high. If the firmware doesn’t pick that up, something in the hardware is toasted.

I think my problem is same as Karolis’s.
Below are links to videos of my problem. You will hear a loud noise, so turn the volume down to play. :joy:

I’m waiting for a new motherboard to change the motherboard and test it out.

z-home malfunction

y-home malfunction

@vanillasky9, seems very similar, yes. Not sure if that’s related, but I noticed we are using the exact same stepper motors from stepperonline.

The only difference form my setup and the rest of the machines here is that I am using a taller YZ plates. Everything else seems to be almost identical. Yesterday I was testing all day with the default firmware and default settings.

One other thing I need to mention is that the problem only occurs with dual endstops and the first endstop ALWAYS works. No matter if it’s Z1 or Z2, whatever gets hit first will work fine. It is the 2nd one that fails.

From the information on this and other threads in the forums, I got an impression that this is an issue with the board, which I can try to investigate and possibly fix myself. I am not sure I want to go this way ATM. I’ve spent so much time and effort on this that getting a new board just seems easier. If another board works, I will know this was a board problem and try to return the old one as defect. If not, I will go through all @SupraGuy suggestions.

Thanks again for all the comments and help.

Are you sure your endstops aren’t swapped?

1 Like

Sorry. I got confused about who is the OP on this thread.

1 Like

First cut in progress!

4 Likes

So I did my first cut, and (surprise!) it wasn’t deep enough, as I used the wrong offset in Fusion 360 2D contour. But since I have homing on my machine which (kind of) works (with lower motor power, stealth mode enabled and lots of prayers), I thought there is no need to worry. I fixed my gcode, homed the machine again, moved to the same coordinates and started a new cut on top of the previous one. And (another surprise!) the new cut was off by around 1mm on the Y axis. Not pretty!

This made me wonder how accurate those cheap mechanical endstops are. Is 1mm difference from the previous cut normal? Would optical endstops be more accurate?

Absolutely not. They should be more than accurate enough for our uses.

Kind of? Why stealth mode?

Because reducing motor power and stealth mode (probably reduces power even more) help with the endstop issues I’m having. Apparently when it does home, it still doesn’t do it very accurately.

Probably the best thing to do while I’m waiting for the new board is either not use homing or restore motor settings to defaults after homing.

I highly suggest you stick with ALL the firmware settings as we have them while doing any testing. Changing firmware introduces thousands of variables that make it too difficult to help.

Try just physically separating your end stop wires from all the rest by more distance to see how much that helps.