Synthetos Shop

Y axis motors stopped working

From the original Synthetos forum (2011–2025)

Started by marco_c on in TinyG Support. 15 replies, last activity Apr 4, 2015.

marco_c #

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?

cmcgrath5035Staff #

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.

marco_c #

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.

cmcgrath5035Staff #

For your entertainment, here is one thread on the topic of issues related to stepper pulsewidth.

https://www.synthetos.com/topics/a-bad-day-in-the-shop/

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

http://synthetos.github.io/

or try the new downloader

https://www.synthetos.com/topics/finding-hex-file-for-new-edge-build/#post-7470

marco_c #

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.

cmcgrath5035Staff #

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.

aldenStaff #

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.

cmcgrath5035Staff #

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

marco_c #

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.

aldenStaff #

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.

marco_c #

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!

cmcgrath5035Staff #

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

https://github.com/synthetos/TinyG/blob/master/hardware/v8schematics/v8g/tinyGv8g%20-%20schematic%20page2.pdf

It might also be helpful if you post your tinyG parameters to a file for review. See

https://www.synthetos.com/topics/forum-information-sharing-readme/

marco_c #

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.

cmcgrath5035Staff #

I like you build solution - recycling a desktop case to hold all the electronics.

Have a look at this:

https://dl.dropboxusercontent.com/u/50261731/kdiffout2.pdf

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

marco_c #

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.

cmcgrath5035Staff #

Troubleshooting wiring issues is tough in these.

Knowing what wire was detaching, can you explain tinyG restarting?
I am sort of guessing it was caused the first time the wire separates while under step power, likely a voltage spike due to the winding to driver opening(windings are rather large inductors).

This topic is from the original forum (April 2015). Your reply starts a new discussion linked to it.

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.