X-Axis suddenly stopped moving in parallel?

New Home Forum Mostly Printed CNC – MPCNC Troubleshooting – MPCNC X-Axis suddenly stopped moving in parallel?

This topic contains 17 replies, has 6 voices, and was last updated by  Joe User 1 year, 9 months ago.

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
    Posts
  • #4056

    John
    Participant

    So I started wiring up some endstops and when I went to test them, the X-axis suddenly started behaving as if it were wired improperly. As in one motor moves forward and the other moves backward. I tried resoldering them but the problem is the same. It’s as if there’s no way to make it move forward on both motors at the same time anymore. Before I started installing endstops, I had no trouble. Things moved as they should have. Any ideas? I’ll keep working on this, but if anyone has a ready solution, I’d really appreciate hearing it. Perhaps I should re-flash the firmware? I’ll try that next.

    #4057

    John
    Participant

    Not sure why or what, but recompiling the firmware and uploading it fresh fixed the problem. If anyone else has such a problem. Try that first.

    #4058

    John
    Participant

    Uh oh…. It happened again. It suddenly goes haywire while travelling. I was performing a simple jog back and forth to test my endstops (which worked at first), and then it suddenly stopped moving properly and the endstops have stopped working too. This is looking like a problem with the Arduino. :/

    Edit:
    Another compile and upload fixes it again. Let’s see for how long.

    Edit:
    Not long… it works for a few minutes then goes haywire. I’ll try ordering a new Arduino Mega.

    #4060

    Ryan
    Keymaster

    Take off the end stops and see if that fixes it. Then add them back one at a time to find your problem. Now you see why I don’t include end stops.

    #4062

    John
    Participant

    Ok, I’ll try that. Thanks.

    #4069

    SteveC
    Participant

    OK calm down, yes, don’t just randomly order a new Arduino 🙂 . They don’t go bad all that easily and are are pretty simple. The RAMPS board is also pretty simple. If the stepper motor sets are moving opposite each other (which is actually them rotating in the same direction) then you have an intermittent wiring problem. It can’t be any other problem, right? They are both connected to the same stepper driver but just have one set of coils reversed. Can’t be a software problem or Arduino/RAMPS problem or even a motor driver problem.

    #4071

    John
    Participant

    The thing is, it is something other than a wiring problem. As vicious1 pointed out, taking off the endstops solves the problem. If I don’t have the endstop wires connected to the ramps board, the motors have no trouble. Without the endstops I can jog the spindle as much as I like and the amount of time that the cnc is turned on seems to be irrelevant. The problem seems to be related to the endstops being activated. They work properly for a few activations, but then the x-axis, and only the x-axis begins to malfunction. I’m currently looking at the code to see if there’s any problems with how the endstops are being handled. Why is it that resetting the arduino doesn’t fix the problem, but reflashing it does? Perhaps some charge is being retained and whatever flaw is causing the problem isn’t resetting. Perhaps waiting a longer amount time during the power cycle will solve the problem without reflashing. I’m looking through all of this now. It most certainly isn’t a wiring problem.

    Please don’t misinterpret my tendency to update posts as progress is made as some type of freak out. I simply feel that if I am working through something, writing my experience as it happens helps me keep it clear in my head as well as allowing others to see what is happening as I go along. It helps others help me, as well as helps me help myself. =)

    A new arduino (non-chinese cheap clone) could solve the problem. If not, I certainly could find a use for a new arduino. I haven’t bought a new one yet, but it will probably happen if nothing else seems to be wrong.

    #4073

    SteveC
    Participant

    OK, I was going off the symptom you first mentioned: “As in one motor moves forward and the other moves backward”. Is this still happening? Still just on the X axis? If so then it must be a wiring problem. Agree? If this is not the exact symptom and you are getting intermittent motion (but proper paired motor rotation) then yes let’s look at the other possibilities. I wanted you to avoid chasing down red herrings.

    I will be happy to help out if you give me as much detail as possible. Professionally in debug situations I have probably “seen it all”, including all manner of strange intermittent power on issues including the “charge retention” you mentioned and it’s interaction with firmware. You don’t have a spindle motor running when this happens right?

    #4074

    Asho777
    Participant

    My 2cents worth, I fully agree with what Steve has stated, in that both the X Axis steppers are feed from one driver and plug.

    So you would think that the problem you have described should be wiring related. You have checked and tested the wiring to be correct!

    So for me I would now look at one of the two stepper motors as being the issue.

    I would take the tooth belt off both of these motors, by sliding the pulley off the shafts. Put a piece of coloured tape around the two x axis stepper motor shafts. This is so you can see in which direction the motors are turning.

    Looking from over one side of the machine over the two X axis motors, run some test and take not that the motors from where you stand should turn in the same direction. Keep on testing until you see the problem you are having. Meaning that either the front or back motor starts the turn in the opposite direction. Make sure that you have everything connected including the end stops, as this may or may not have induced the problem.

    I would have the Z motor handy to use as a test replacement, for a possible faulty X axis motor. Once you see the problem again and have establishes which motor changes direction, replace that motor with the Z motor. Run some more tests and if you do not see the issue again the problem was in the stepper motor that you had taken out.

    All mechanical and electrical problems are best solved by the process of elimination. If the above does not give you any position resolve to the issue we can take it further.

    But for now lets try the above.

    Cheers
    Greg.

    #4084

    Ryan
    Keymaster

    So you have narrowed it down now. It should have nothing to do with the ramps boards.

    Are you using my marlin, with no edits? You should at least for now. Wire 1 end stop Normally Open and try it out. Figure out which axis is causing the problems. It could also be repetier or whatever control software you are using. Make sure you are plugging them into the right 2 pins as well. you have min and max and only use 2 of the 3 pins.

    #4089

    John
    Participant

    Thanks for the suggestions, everyone. My friend came to town suddenly yesterday so I had to go out and have a few drinks. Then I was pretty useless when I got home. =)

    I’ll get back on this tonight when I get home from work. From here I can describe exactly what I’ve done so far.

    I connected the motors properly (2 wires switched on one motor of the two motors in parallel) and soldered all contacts. I covered each solder point in shrink tubing. It will jog on all axis without trouble for any amount of time.

    Next I began making endstop switches. I used the same type as are on my Ultimaker and connected them in the same way. 120v5amp/240v3amp (if I remember the values correctly) I threaded the eyelets on the switch with the wire, twisted the wire back onto itself at the base of the wire, and soldered it firm before shrink tubing those connections. I used the two connectors directly under the switch itself, not the third under the open end of the metal lever. On the other end of the endstops I attached 2 wire flat plastic connectors (the kind that connects the power switch to your motherboard in your desktop, I’m not sure of their proper name). I crimped them onto the stripped wire with needle nose pliers and gave a nice little tug to be sure they were firmly connected before sliding them into the plastic housing. I then began connecting them as such: from left to right, Xmin, Xmax, Ymin, Ymax (http://www.element14.com/community/servlet/JiveServlet/showImage/2-97448-190183/RAMPSendstopConboard.jpg) I connect them to the Signal and Negative terminals, leaving the Positive terminal open. I haven’t gotten into the Z axis yet since I want to print a housing so that the endmill can reset itself after a tool change.

    After connecting all of the endstops, I began testing them. I jogged to each endstop using the Pronterface UI in Cura. After several successful stops on all the axis, the Xmax side motor begins to reverse/hold position while the Xmin side motor seemingly continues to function properly. Next I tried unplugging both the power and usb for a hard reset. I did not wait a long time. Maybe 15 seconds. Just enough for most electronics to start up fresh. The problem persisted. I tried turning off the power and unplugging the USB again and this time unplugged all the endstops. Again, only a 15 sec or so reset. The problem persisted. I downloaded the Marlin firmware from this site (the first link which seems to be the default). I loaded it into the Arduino IDE and compiled and uploaded it. I made no changes to anything. Everything went back to normal with no endstops installed. I turned everything back off, reattached the endstops and everything happened all over again from working for a short while to malfunctioning on the X-axis Xmax side. A reflash fixes the problem, a short reset does not. Perhaps waiting longer after turning off and unplugging everything would prevent the need for a reflash, I haven’t tested that yet.

    I did not count the number of activations required to initiate the bad behavior yet, but that will happen tonight. I plan on counting each activation and the order that it occurs before the fault. If it is happening consistently on a particular number of activations, it is probably a programming problem. If it is random, that does not eliminate a programming error, but it makes it less likely. Alternatively, a problem with the cpu on the Arduino could cause such an error (think 90 Mhz Pentium division error). The reason I doubt it is a wiring problem is that the motors work flawlessly without the endstops. So the motors should be fine, no? The endstop switches are extremely simple devices and are working properly for some time before the fault, so I doubt their wiring is an issue. If they did not work at all, or if their behavior were more erratic I would think it could be wiring, but the fault seems to occur when the spindle is in the middle of the X/Y axis. It doesn’t occur immediately after an endstop activation, but perhaps after a click or two of the jog button. I believe it has occurred after traveling away from a successful Xmax endstop activation. While the X-axis is malfunctioning, the Y and Z axis motors still behave correctly, but now those endstops have begun to malfunction. I’ll double check that Xmax endstop first.

    I’ll start documenting everything more thoroughly and I will start the process of elimination once I get home from work.

    Does this clear anything up for anyone? Personally I’ve seen a couple of areas to check while writing this that I didn’t see before, namely that xmax endstop. I’ll replace the whole thing if I have to. I have the spare parts.

    #4090

    Ryan
    Keymaster

    Oh okay.

    You need to enable the max end stops in the firmware. Do a quick test, just run the min end stops, probably works fine.

    You need to enable and I think define the max values in the firmware, enable for sure. I am pretty sure you need to tell your control software you are using max stops as well. By default this is off for all machines.

    Sorry for assuming you were only using mins.

    #4091

    SteveC
    Participant

    John and vicious1,
    Sure the endstops need to be properly set up in the firmware but can we all agree that there is at least a second problem here? One symptom is that the X max motor is operating differently than the Y min motor. The X max motor cannot operate differently than the X min unless there is one of a few problems: intermittent wiring, a bad intermittent X max motor, or possibly marginal stepper driver current that the X min and X max motors respond to differently (I think a long shot). Agreed?

    Greg’s suggestions are spot on. Also you could swap X and Y everything.

    Steve

    #4092

    John
    Participant

    Vicious1, thanks for the info! I’ll test only with min endstops and then try enabling the maxes. It may just suddenly work. Stranger things have happened.

    Steve, if that is the case, why do I experience no trouble at all when there are no endstops connected?

    #4094

    John
    Participant

    Things have seemingly gone from bad to worse. First I tried removing the max endstop cables from the ramps and the trouble persisted after homing and jogging around a bit. Then I tried enabling the max endstops in Marlin, but they seemed to be already enabled as evidenced by the code below (please tell me if I am reading the config file wrong). Then I removed the endstop cables completely and the trouble has persisted despite long power downs and reflashing. The disable settings were already commented out in the config. Unless enabling the endstops is done somewhere other than configuration.h or configuration_adv.h, they should be good to go. Tomorrow I’ll start looking at the soldering and the motors themselves. I may try swapping the drivers around as well. If it is indeed a power issue, that could be the culprit. After looking more closely at the motors as they struggle to move, I’m no longer convinced it is trying to go backwards as much as it is unable to move. That may indeed be a connection problem or some other power problem. Steve, I apologize for doubting you. You may be right after all. I spent a whole day soldering and wiring those things, I thought for sure they would be ok. Especially after working perfectly when not endstopped, and having trouble only while endstopped. I guess coincidences of this magnitude must happen eventually. I’ll keep at it until the problem is resolved, and I’ll inform you of the results. Unless anyone thinks of anything that hasn’t already been mentioned, I must admit that we’ve come up with all the possible problems and solutions. Thanks for the help. Sorry for my arrogance.

    -John

    // Uncomment the following line to enable CoreXY kinematics
    // #define COREXY
    
    // coarse Endstop Settings
    #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors
    
    #ifndef ENDSTOPPULLUPS
      // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined
      // #define ENDSTOPPULLUP_XMAX
      // #define ENDSTOPPULLUP_YMAX
      // #define ENDSTOPPULLUP_ZMAX
      // #define ENDSTOPPULLUP_XMIN
      // #define ENDSTOPPULLUP_YMIN
      // #define ENDSTOPPULLUP_ZMIN
    #endif
    
    #ifdef ENDSTOPPULLUPS
      #define ENDSTOPPULLUP_XMAX
      #define ENDSTOPPULLUP_YMAX
      #define ENDSTOPPULLUP_ZMAX
      #define ENDSTOPPULLUP_XMIN
      #define ENDSTOPPULLUP_YMIN
      #define ENDSTOPPULLUP_ZMIN
    #endif
    
    // The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
    const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
    //#define DISABLE_MAX_ENDSTOPS
    //#define DISABLE_MIN_ENDSTOPS
    
    // Disable max endstops for compatibility with endstop checking routine
    #if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS)
      #define DISABLE_MAX_ENDSTOPS
    #endif
    #4095

    karltinsly
    Participant

    John, you and the others all sound like you have a pretty good handle on the possible causes of your problem. I did want to mention that if there is an open (bad connection) on one of the legs of a stepper motor, you’ll get very erratic behavior, including random starting, stopping, and reversing directions.

    Good luck – hope you find a solution soon!

    Karl

    #4098

    SteveC
    Participant

    Hey John, no worries at all. Karltinsly’s is really good description of an open in one of a stepper’s windings or connections. Just disconnect one of the stepper wires and you will see this when it is driven.

    Did you set the driver current limit with this procedure? https://www.youtube.com/watch?v=89BHS9hfSUk . Just make sure you pick the proper equation for your drivers.

    Steve

    #5231

    Joe User
    Participant

    I’ve had similar problems on the Z-axis of my Mendel Prusa i3. They would run in parallel most of the time but would occasionally run amok in different directions. It turned out to be a dicey RAMBo pin to PCB solder joint (the RAMBo has separate connectors for the two Z motors.) I’m 95% sure you have a similar “air gap” in a wire or maybe a cold solder joint. I’d try replacing all the cables and redoing all solder joints. It could even be a broken conductor in a cable that sparks/connects intermittently. One last idea: are the stepper conductors and the end-stop conductors sharing a cable anywhere (in the same sheath?) I’d keep them apart and separated physically by a few inches at least The current flow to ground when a NO end-stop closes might bother the stepper pulse signaling?

Viewing 18 posts - 1 through 18 (of 18 total)

You must be logged in to reply to this topic.