Topic: Y axis motors stopped working

Tagged: shapeoko, Stepper motor, TinyG

This topic has 15 replies, 3 voices, and was last updated 9 years, 9 months ago by cmcgrath5035.

Viewing 15 posts - 1 through 15 (of 16 total)

1 2 →

Author

Posts
February 25, 2015 at 7:10 pm #7463

marco_c
Member

I have been successfully using TinyG v8 with a ShapeOko2 for a number of months. Over the week end the Y axis started making ‘crunching’ noises and does not spin properly (eg, spins the wrong way, stop, goes back in the opposite direction, somewhat randomly). This happens during a homing sequence and is repeatable, as in it happens every time. The Y axis motors are wired in parallel off one motor controller.

X and Z axis are working very well, so I am assuming it is not the power supply.
Motors and power supplies (24 V) were purchased from Inventables as part of the ShapeOko kit.

If it is important, I an using Chilipeppr to drive the controller, but after the homing message is sent there is no involvement from the host, so I am working on the problem being isolated to the motor and TinyG.

What I have done to date:
1. Move the Y axis control to the ‘spare’ motor controller (#4) in case the controller was dead – no change in behaviour.
2. Pushed the carriage with power off in case of mechanical interference – all moves smoothly and freely.
3. Went through readjusting the motor current pot in case the motor was borderline stalling – made no difference.

My next step could be to loosen the drive pulleys one the motor shafts to identify if it is a problem with one specific motor or replace one motor at a time to see if that is damaged.

However, overall I am at a loss what to do next? Does anyone have any ideas I can try?

February 26, 2015 at 7:19 am #7466

cmcgrath5035
Moderator

Homing sequences are performed at yvm and yjh (for y axis).
You could reduce both (by say 1/2) just to see if that helps.

What firmware build are you running?Current is 438.02.

Somewhere between 410.xx and 438.02, the stepper pulse widths were increased, which might help here as well.

I am just curious – why run two motors on one driver if you have a tinyG?
Two NEMA23s might be marginal in that configuration.

February 27, 2015 at 12:58 am #7475
marco_c
Member
Firmware is 435.1, so it is a little out of date but not much. The board was purchased late last year (2014).

One of the options for setting up the dual motors is to wire them up to the same motor control. I wanted to keep one axis free in case I decided to implement a fourth rotation axis as well. As these are NEMA17 motors there should be no problem with the current. And, as I said before, the motors worked fine and the pot setting is at about half full range.
- This reply was modified 9 years, 10 months ago by marco_c.
February 27, 2015 at 7:00 am #7478
cmcgrath5035
Moderator
For your entertainment, here is one thread on the topic of issues related to stepper pulsewidth.
I don’t have precise records, but 435.1 fw is in the timeframe that this issue appeared. Dialing $yvm way back to 1000 worked fror me, but the ultimate solution was fw 438.02 at the timr.

And, a newer build, 440.13, is an even better choice. available here
or try the new downloader
- This reply was modified 9 years, 10 months ago by cmcgrath5035.
March 3, 2015 at 10:12 pm #7499

marco_c
Member

I have now updated the firmware to 440.13 and had to redo the config parameters (a warning about this would be useful in the firmware downloader!).

Still no joy with the Y axis movement. What I have noticed is that the motor ‘grinds’ and if I help it in the direction it is supposed to be going, it eventually starts moving smoothly on its own, once it is past a certain position on the axis). Is it possible that one (or more) of the coils in the motor are damaged? Any hints as to how I could determine that to be the case?

Can you also confirm if the G28.2 command has been changed so that all 3 axes are supposed to move together? I had that occur once withe the new software but this was not the case with previous firmware.

March 4, 2015 at 6:49 am #7501

cmcgrath5035
Moderator

FYI, there was a quick bug fix and you should install fw 440.14 when you can get to it, but it will not resolve your Y issue. And yes, you will have to reenter your parameters again.

I am not a G28.2 (or homing/limit switch) user, but there have been several rounds of fixes to G28.2 since the 435.xx days.

Motors fail from time to time, diagnosis is difficult for soft failure.
Assuming no mechanical cause (gantry binding, wheels too tight, etc.) it sounds like inadequate torque to get the motor spun up,
Are you sure wiring/connections are good?
You could try frogging (swapping) the tinyG drivers and motors, to see if the issue follows the driver.
What I mean is:
If now “Y1 is M2 and Y2 is M3”, change to “Y1 is M3 and Y2 is M2”. You will have to reverse the $2po and $3po polarity settings if you want the gantry to move the same direction as “+”.
If the same motor, on the new driver, still has an issue, a motor replacement is likely in order. Even if you could diagnose internal issue,I doubt you could fix it. It could be just a bad bearing in the motor, fixable once you find the right one.

March 4, 2015 at 9:05 am #7502

alden
Member

Have you checked your stepper wiring? If the problem moved from the Y axis to motor 4 that’s in indication that something’s wrong in the motor, or often the wiring itself. Your symptoms sound like 1 of the 2 motor phases is not energizing.

If you have a spare motor lying around try attaching that to the Y axis (Motor 2, I assume) and see if that works – or just re-arrange your profile to map the X axis to motor 2 and see if that works. This would be useful to isolate the problem between the motor driver and the the wiring/motor/mechanical system.

March 4, 2015 at 9:59 am #7503

cmcgrath5035
Moderator

Oops, sorry, I lost context of the fact that you were using one driver for both motors. Follow Alden’s suggestion.

March 14, 2015 at 8:37 pm #7542

marco_c
Member

Been busy with other things but finally got back to this today. Updated the firmware to 440.14 using TinyG-Updater and running SPJS 1.80. Tried the following:

1. As I have 2 motors on the Y axis, I disconnected each in turn to see if it made a difference, ‘jogging’ 100mm at a time to see if the problem was isolated to one motor only. Both motors did the same (grinding/stuttering in a section of the travel, smooth past that point).

2. In software, swapped X and Y axis motor controllers and the problem stayed with the Y axis. I guess from this it is probably not the controller but in the wiring/motors. Is this a valid conclusion?

3. I did notice that frequently, moving the Y axis would cause the TinyG to reset when it went from the ‘smooth’ section of travel to the ‘stutter’ phase. Not sure what this means, but it might help.

I am ordering 2 spare steppers to try out, but in the meantime does this info help to diagnose this any further?

Thanks.

March 15, 2015 at 5:54 am #7543

alden
Member

It sounds like the motor / wiring. Stuttering may be an indication of thermal shutdown of the chip (see if the chip is hot to the touch), but more likely one of the motor phases is not connected or is intermittently connected.

April 1, 2015 at 12:21 am #7580
marco_c
Member
It has been a while but I have now had time to play a bit more, including replacing one of the Y axis motors to see if it makes a difference. It makes no difference – the motors work in the extreme sections of the linear travel but ‘stall’ in the middle. Instead of spinning in a specific direction, the motor appears to spin a fraction one direction then a fraction in the other. This creates a jitter but does not move the assembly anywhere.

At the end of the section where it moves freely, the TinyG resets. This stops the motion dead, clearly. The jittering is also stopped when the TinyG resets itself (flashing red LED). Tried changing USB cable (one the basis of Rural’s post and resolution) but it makes no difference.

What puzzles me is that it works for the end sections of travel (near home and at the other end) but not for the 70% rest of the span. Any more ideas? I am about ready to tear out the little hair I have left!
- This reply was modified 9 years, 9 months ago by marco_c. Reason: Additional information
April 1, 2015 at 7:35 am #7582
cmcgrath5035
Moderator
If I re-read the thread correctly, when you swapped the drivers by changing settings, March 14 Step 2, the issue stays with the axis that has two motors.

I am wondering if your PowerSupply (24V) might be defective or for some reason going into premature current limiting. Wild fluctuations on 24V could explain the tinyG resets as well, perhaps delayed a bit by the filter capacitors on the 3.3V rail.
Because there are two motors on the Y axis, 2x the current will be required whether you drive the two motors from one driver, as you have been, or connect to 2 drivers (Y and Yrev).

Do you have a Dig MultiMeter available? If so, try to monitor a Vmot point on tinyG, such as the fan voltage selector pin block. That measurement would include power supply cabling ad connectors. That would be J12 on this schematic page
It might also be helpful if you post your tinyG parameters to a file for review. See
April 3, 2015 at 12:03 am #7587

marco_c
Member

Tried a few more things:
1. Moved the USB port to another one on the computer and changed over the cable. No change.
2. Put back the original motor instead of the replacement, but only connected one of the Y axis motors. No change, still stutters.
3. Tested the motor driver chips to see if they were getting excessively hot. All felt just warm to the touch. The hottest was Motor 1 (X Axis) and it was no problem keeping my finger on the chip indefinitely (ie, it really was not excessively hot in any way).

I measured the voltage as you suggested but it seems to stay at 24V or close to it.

I made a video with commentary of the setup, the problem occurring and took a dump of the TinyG configuration – see this https://www.dropbox.com/sh/sga69j2wq7jt74x/AAAmcM0R0ZG3EjL0D4yXGsfGa?dl=0.

April 3, 2015 at 8:58 am #7588
cmcgrath5035
Moderator
I like you build solution – recycling a desktop case to hold all the electronics.

Have a look at this:
On the left is a current set of parameters I am using, on the right are yours.
Big differences (Me vs. You): NEMA 17 vs NEMA 23, X and Z sizes, No Limit SW vs Limits and Homing, XYYrZ setup vs. XYZ(A not used) setup

Other differences:
$ja=100000 vs $ja=2000000 You are using the recommended value, I am not and I don’t recall if this was intentional on my part. You machine corners faster than mine, should not be an issue here.

$ex=1 vs $ex=2 I use Chilipeppr a lot, SPJS mamages flow control, I don’t think there is an issue here.

No switches vs Switches and soft limits enabled
— Because I have switches turned off, I don’t pay much attention to homing related parameters. The setting you have look sane to me.

Videos
1. I noticed that the time tinyG reset, on the initial Y move, it was before any funny noises occurred
2. If I understood your dialog correctly, all the moves you show are the results of homing commands from Chilipeppr.First Z, then X, then Y.
3. I wonder if the link between CP and tinyG is getting confused by the tinyG reset. When CP starts up, it sends a sequence of initialization commands to tinyG, to ensure that both ends are ‘in sync’.
3A. To see if this ‘out of sync’ is an issue, any time you see tinyG reset, you could disconnect, then reconnect the SPJS using the icon on the SPJS widget. Reconnecting to tinyG would resend the start-up sequence.

So, what is causing tinyG to reset?

Suggestion 1: Set a zero point somewhere well away from Home; move your gantry by hand, then Set Zero. The issue commands in the Serial console to move the gantry toward home, something like G0 X-200 then G0 Y-300 (premeasure so as not to bang into your rails). Do these moves also trigger resets and funky noises?

Suggestion 2: If you still get bad behavior on Suggestion 1 test, turn off all limit switches($xsn=$ysn=$zsx=0) and retry. This is a noise test, but noise should halt tinyG, not reset it so I am doubtful this is issue.

Suggestion 2: Turn off Soft Limits, set $sl=0. Then try to rehome.

(If Suggestion 1 test OK && Suggestion 3 test OK, perhaps an issue (bug) in Soft Limit handling).

ALso – what version of SPJS are you running? Most current is 1.80
April 4, 2015 at 2:08 am #7594

marco_c
Member

SPJS version is the latest 1.80.

I have solved the problem. It turns out there was a broken wire between the back of PC box and the motor. I decided question my assumptions about what was going on and wired one of the new motors directly to the TinyG – it worked flawlessly! I then checked the continuity of the wires between the back of the TinyG and the motor and one of the cores for the motor control, BUT, when the carriage was in the furthest position the break was ok and the motor signals got through (hence why it was working and the failing during the traverse. It also explains why both motors misbehaved (same cable) and why the problem remained with the axis no matter which motor controller was selected in software.

Replaced the cable with the intermittent core and it all works fine now. It looks like there are no bugs in the code after all 🙂

Thanks very much for your responsiveness, support and patience – great to be part of the community.
Author

Posts