Home › Forums › TinyG › TinyG Support › Trouble with Motor 4
Tagged: help
- This topic has 9 replies, 3 voices, and was last updated 8 years, 1 month ago by
DougWilson.
-
AuthorPosts
-
September 30, 2016 at 8:05 pm #9930
DougWilson
MemberMy Dad and I built a CNC machine. We initially were running single motors at 12V for X, Y and Z but found that our X axis was binding if Y was near it’s max or min. So we decided to add a 2nd X motor and ballscrew and switched out the 12V power supply for a 24V.
We started off with driving both X motors from Motor 1 having wired them in parallel. For short moves less than 100mm the motors stayed in sync. For longer moves it was apparent that they were getting out of sync and starting to bind again.
So, we moved the 2nd X motor to Motor 4 on the TinyG. Initially we couldn’t even get Motor 4 to turn, even with the current set comparably to Motor 1. We fiddled with the wiring and eventually got it to turn, but the wrong direction. Easy fix… we switched the wiring at the TinyG and got it going the right way. Sorta…
The problem we are encountering now is that Motor 4 ALWAYS turns at a different speed than Motor 1 even though both channels have the same settings across the board. We thought it was maybe the motors themselves but after switching them around the identical behavior was observed: the motor on Motor 4 did not turn at the same speed and was stuttering, stalling, starting and stopping throughout the moves. (For move we’re just doing G1 F100, etc.)
Things we have tried that didn’t work:
– Reset to factory defaults
– Different motors for Motor 4.
– Slave Motor 4 to Z axis
– Slave Motor 4 to Y axis (we’ve seen ShapeOko machines with Dual Y work with TinyG)
– Adjusting current up and down
– Adjusting Jerk values (I believe they are currently at defaults)
– Adjusting Feed ratesThe config is here: http://pastebin.com/Y8SUZht9 Let me know if there is anything else I can provide that might help. We really could use some help troubleshooting this one.
September 30, 2016 at 9:24 pm #9931cmcgrath5035
ModeratorLooking at your parameter set, you have $1sa=0.9 and $4sa = 1.8.
Is that a typo?
If the motors are the same, this pair of setting would have one moving twice as fast as the other.
$_sa=1.8 (200 setps per rev) is the much more common motor.September 30, 2016 at 9:43 pm #9932pca
MemberIt’s possible it’s a hardware issue. Are you certain that you have your stepper motor controller set to the same microstep value in each case?
If one was, for example, at x8 and the other was at x16, they would move different distances for the same number of steps.
October 3, 2016 at 12:27 pm #9943MemberWe double checked and have both motors set to 1.8. The behavior is still the same as described.
The microstepping is also set to x8 for both.
I’m trying to get a video of it to provide more insight but I’m leaning to hardware issues.
October 3, 2016 at 9:04 pm #9948ModeratorAn up to date parameter dump to pastebin might help too.
October 12, 2016 at 3:14 pm #9958MemberLatest config is here: http://pastebin.com/Y8SUZht9
Still no joy with Motor 4. We’ve switched back to a single X motor for now but now the board will no longer home the Y axis.
How do you know when the board is the problem and not the user?
October 14, 2016 at 6:52 am #9959ModeratorI pulled these from your PasteBin:
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z…]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 3.8900 mm
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z…]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 8.0800 mm
[2mi] m2 microsteps 8 [1,2,4,8]
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z…]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 8.0183 mm
[3mi] m3 microsteps 8 [1,2,4,8]
[4ma] m4 map to axis 0 [0=X,1=Y,2=Z…]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 360.0000 mmTwo issues (maybe)
$4ma is set to X axis, as is $1ma. Most users would set $4ma=3 (or 4 or 5) if in fact motor 4 was unused. I am not sure what effect your settings might have.What sort of mechanical machine do you have (ShapeOko, Ox, ??). What I find strange is $1tr=3.89mm while $2tr=8.08mm. Most machines have the driveline (pulley, belts, etc) the same on X and Y. These are legitimate values, firmware wise, so I am just checking that they are intentional.
You ask “How do you know when the board is the problem and not the user?”
It is not easy to answer. Most of the time, if tinyG boots and the parameter set is correct, tinyG just works. That is why we ask about your settings.Some other ‘unusual settings’
X size larger than Y size – Legitimate, but not the way most folks configure typical machinesZmin limit switch – does it really exist? It is enabled
A frequent issue with limits not working is miswiring, e.g. wrong switch wired to port.
I’d suggest shutting off all limits and homing, concentrate on X and Y jogging, then add Z jogging motion (all in air first).
How do you communicate with your machine – CoolTerm, Chilipeppr, other?
October 14, 2016 at 12:50 pm #9960Member$4ma is set to X because we are trying to run dual X. It’s a machine we built ourselves. Initially we only had a single X motor but due to racking we’re trying to move to dual motors. But, as the title of this post, Motor 4 isn’t cooperating.
$1tr=3.89 is correct. We went with dual Chinese ball screws on the X axis so they don’t match the lead screws we have on the Y and Z.
X > Y is because of where we have the computer/chilipeppr in relation to the machine. It just makes more sense for us; less mental gymnastics is a Good Thing.
The Z Limit switch does exist. We’ve had too many problems with random plunges and broken bits with TinyG and Fusion 360 to risk running without it.
Currently all the jogging works fine.
Currently we use both CoolTerm and Chilipeppr on an iMac. We started off with a MS Surface 4 tablet running Chilipeppr but had a lot of trouble with it so we switched to the iMac. In retrospect, I don’t think it was the Surface tablet that was the problem. Chilipeppr itself seems to have a lot of trouble with TinyG. Basically the TinyG stops responding to any commands so we are continually having to cut the power to the board, restore power and then reconnect Chilipeppr. CoolTerm doesn’t appear to have this same problem but due to how tedious entering commands is we haven’t used it nearly as much.
All in all, we have not had a good time with TinyG and are seriously regretting not having simply gone with a Mega 2560 and RAMPS 1.4.
October 14, 2016 at 9:25 pm #9961ModeratorThanks for the info – all makes sense .
I have never used a Surface for anything, sort of assume it is IE based browsing (or Edge). Neither IE or Edge seem to run CP well (YRMV), likely due to JS issues.
Only other suggestion I have is a full parameter reset and reload – some users have experienced relatively silent parameter corruption. There are ‘hidden’ parameters also stored in EEPROM(parameters not intended for user tweak)that occasionally become corrupted.
Steps
1. Make sure you have a parameter list backup – you will need to reenter most.
2. Use CP on Chrome or CoolTerm
3. Send the command $defa=1, which will reset tinyG to factory defaults (FW compiled in parameters)
4. Restart tinyG (reset button), connect with CP or CoolTerm
5. Re-enter all your unique parameters, one at a time, from the CoolTerm Command line or the CP Serial Port Console.Hope that helps
October 15, 2016 at 9:54 am #9964MemberWe’ve reset to defaults multiple times already with the same results each time.
We were running Chrome on the Surface. Aside from the other issues I described the screen was just too small to hit buttons accurately in Chilipeppr, even with a mouse instead of the trackpad.
-
AuthorPosts
- You must be logged in to reply to this topic.
