Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: odex on February 23, 2013, 11:33:17 AM
-
After much troubleshooting I have boiled my problem down to the following: When attempting to execute a rapid involving 2 or more axis, IF one of the axes is making a very small move (<.020" say) while the other axis is making a larger move, the axis making the larger move will stall. Every time. I extracted the following code from a troublesome program to test the problem:
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G0 X0.3359 Y0.522
G1 X0.3382 Y1.8169
G0 Z0.125...
rinse repeat. That move from X0.3382 to X0.3359 is causing the problem. Change that to a larger X move and the problem vanishes completely. It is the act of making a very small move on one axis while making a larger move on the other axis that gives me trouble. Changing the length of the longer move has no affect.
I have written programs to exercise the mill in all axis motion. Rapids of varying lengths; can literally run all day without missing a single step at max speed. As soon as I try and rapid with a move that has a high aspect ratio between any two axis I get a motor stall. I dont seem to be lacking for power supply power or stepper torque, as I can rapid all of the motors at once without issue and I can mill at a respectable rate under load without issue.
I have disabled networking, disabled sound card, disabled all system sounds... I'm really just running mach3 at this point.
I have replaced my parallel breakout board. I have replaced my parallel cable with a shorter cable (suspecting some kind of EMF related issues). No joy.
Cranking down my rapid speeds to a crawl does NOT alleviate the problem. Changing my backlash %ofmax number does not alleviate the problem. I have had limited success with changing my acceleration rate, but its very much hit or miss. If I change my acceleration rate to something very low (say 5 IPM/M) it will periodically succeed at executing the test code. Again, note that rapids testing cannot reproduce this problem with ANY acceleration rate so long as the moves are not of high aspect ratio. I normally rapid at 90 IPM and accelerate at about 30 IPM/M and this has historically caused me no problems.
I am running keling 4030 stepper drivers at 36 volts feeding some NEMA23 steppers on an X2 mill. I have switched to a C35 breakout board using sheilding twisted pair network cables to talk to the stepper drivers (again, in suspicion of EMF noise of some sort). Did not change the problem.
I do not have a way to intercept and monitor the pulse stream coming out of the PC or out of the breakout board so I dont know if the stream is somehow corrupted.
I tried this on a different PC and got the same result, so it doesn't SEEM to be linked directly to the PC parallel interface.
Anyone ever seen anything like this? Any ideas? Maybe some sort of cross talk in the hardware? Software bug?
Thanks for considering
-
have you tried it with a lower rapid speed like 50 ipm
-
Yes, as I mentioned I can crank my rapids down to a crawl (less than 10ipm) and still get a problem. :\
it doesn't seem to be related to inertia or motor power type issues
-
sorry i must have missed that bit. :)
-
no worries, I've done a lot of troubleshooting and my presentation may not be the most coherent story!
Also, please note that while I have my nominal rapid rate set to 90 ipm, the machine is actually capable of significantly more (>120 ipm) I just have it de-tuned for conservatism sake.
-
what are the microsteps set at, and do you have the steppers driving the ballscrew direct. Is it a ballscrew or a leadscrew.
-
Ballscrews
16000 steps/inch
Toothed belt connection
pulleys turn freely by hand when not connected to steppers, have not been able to detect any manner of mechanical binding in my examining the motor installs/belt tension etc.
I forget the microstepping I have the drivers set to as it has been several years since I first set it up, but yes they are microstepping
-
Also, the pulleys are such that the motors are geared down, ie slower movement of the screw as compared to the motor; again I forget the exact ratio but iirc its on the order of 2:1
-
I've experienced a similar (same) issue, but thought it was my controls. Try changing the G0s to G1s to see if the problems goes away. I've not had another recurrence since eliminating G0s in my code.
I first experienced this issue when I switched to the later versions of M3 (.058+ ?) so I could use M10/M11 commands with my laser diode machine.
I do believe it is a Mach3 bug.
John Champlain
-
I just tried it again by replacing all G0's directly with G1's (ie keeping the previous feedrate). Works fine, no stalls.
I went a step further and replaced the g0's with G1 F90 moves... stalls
so with a g1 at the same rate as a g0 it will still stall :-[
-
are you using backlash comp.
-
yes. its fairly small,I think .004" on my worst axis.
UPDATE:
I rewrote the test code to use G1 moves instead of G0, and I'm using a speed of 30 ipm (which the machine is grossly over-capable of executing).
With backlash compensation ON, it stalls.
With backlash compensation OFF, it works!!
interesting development...
-
why are you using backlash comp?.
-
Also, I tried playing around with the % of max setting in the backlash comp
dropping it all the way down to 1% I still get a problem, so long as blc is enabled.
Disable blc, and the world is right again.
This feels like progress... or maybe just a new hole to dig in... haha
-
For overall positional accuracy. Accumulating a series of .004 move errors over the course of a program run can net a fairly sloppy result on the finish pass
-
I think your accel rates are too high. Short snappy moves will show this. Backlash comp. will as well. There isn't enough time to change direction of the motor and all the mass hooked to it. All of this has to be done in a fixed time window so your path will be accurate. Naturally a huge Arc allows time for an axis to slow and change direction. I know your machine can travel much faster than you typically run or even rapid at, but it doesn't have the guts to snatch the amount of mass around your trying to in such a short amount of time even though it is a short distance.
Brett
-
I thought that initially as well, but if I go and change that sample code to make a larger move in the x axis (go wild, make it move 9 inches instead of .00x), it will execute without flaw. I can do drills all day where I rapid back and forth on any axis or any combination of axes.
If for instance I REMOVE the x move from that sample code, the y axis WILL NOT stall anymore. Conversely, doing the x axis move by itself will not cause a problem. The x axis move shouldn't really affect it (stepper should have peak torque at very very low speed), but it does.
You are right, there is certainly an inertial mass effect, but why wouldn't it show up when making rapids in any other way? Its only the high aspect ratio (between move ordinates) that draws this problem out.
-
try making the x move .015, as this is easily above the backlash value.
-
if that works bring it down to .010 then .006. It should stall at .006
-
To address the inertial mass concern I just wrote and executed the following code several times:
G0 x0 y0
x.050
x0
x.050
x0
y.050
y0
y.050
y0
x.050 y.050
x0 y0
x.050 y.050
x0 y0
as you might imagine this produces very rapid, jerking motions of the table, its kind of violent even, but when its all said and done it returns exactly back to where it started without any motor stalls.
This is with backlash comp turned on.
-
@angeltech
yes sir, that is correct, there is a threshold below which this error happens and above which it does not, iirc it was on the order of .006
its something to do with the aspect ratio, either hardware or software side. I have done everything I can to rule out hardware (that I can think of)
-
Are you running in exact stop mode or CV? Does it chage the results if you change the mode?
Brett
-
During normal operation I run constant, but I have tried it on exact stop as well and I get the same lockup.
-
Try setting your backlash comp speed to 0.1 and let me know how it does.
Brett
-
great idea, I didn't even realize it would accept fractional values in that block.
SO IT GETS WEIRD.
with backlash compensation %speed set to 0.1, it very slow initiates its BC compensation move, which at 0.1 is very slow, then as soon as it gets to its rapid it hangs.
I rewrote the program to remove the x move ENTIRELY, and it works fine.
HOWEVER, at 0.1%speed I did notice that as its doing its backlash comp move, it creeps very very slowly, then takes a sudden jerk right before it hangs the motor, I will study the motion a little better and report back. Very odd.
-
OK, so get this
Per advice above I ran the program at 0.1% blc speed. I filmed this with my phone because it still happens a bit to fast to be sure whats happening, here is what I observed: The motor creeps very slowly through what I assume is its backlash distance, then, it suddenly LURCHES forward some MORE. NO IDEA what that is or why id does that. it looks to be doing this little jerk at the rapid speed.
The weird part is, when I run the edited version of the program, WITH NO X MOVE, it does not do this jerking behavior, it only does the very slow backlash compensation then goes about its business.
Is there something peculiar to the way mach3 does BLC that is biting me here?? is it having to interpolate how much to move each axis for the backlash comp and on a very small move on one axis it spills over data to the other axis??
this is an interesting development, I appreciate you suggesting the 0.1% speed idea.
-
NOTE: I repeated the above, but this time with a motor acceleration rate of 1 programed in. It again does its very slow approach to taking up the backlash, then makes what IS a rapid move (you can hear it ramping at the ramp rate), THEN it starts its rapid in earnest. Mach3 seems to be sneaking in a rapid move here for some reason, and it seems to have something to do with the x axis moving at the same time.
-
ALSO note that I'm able to observe at these low speed settings that mach3 is in fact doing the backlash compensation as two seperate moves, first the Y axis, then the x axis. It may be doing this as a result of the magntitude of the x move?? I will test with different magnitude x moves and see if it still separates out the two axes.
-
OK, new data:
I adjusted the program to make the x move go to x0.3 instead of x0.3359 (to make the x traverse distance larger), so instead of this:
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G0 X0.3359 Y0.522
I INSTEAD USED THIS
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G0 X0.3 Y0.522
The y axis motor does the same little odd jerk, but to a much smaller degree!!
Now, when I re-write the code again to this:
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G0 X0.2 Y0.522
The y axis motor does a nice smooth transition, so, somehow or another mach3 seems to be signaling a hidden little rapid move right after the backlash compensation, and it somehow is in proportion to the magnitude of the attached x move.
SO now I know:
1) its related to high aspect ratio moves
2) its related to use of backlash compensation
3) it involves a sudden rapid move right after the BLC move
4) the magnitude of the jerk is related to the magnitude of the other axis movement.
man am I glad I decided to post here today haha. At least I understand it a little better now.
-
OK, can you try those same test in CV mode and exact stop? This is interesting.
Brett
-
Just repeated experiment both ways, velocity mode doesn't seem to affect it
-
Forgot to mention, I also observed that mach3 is splitting the x and y axis backlash compensation moves up through each of these programs, regardless of x traverse distance, so I will assume that is the normal behavior
-
A) changing blc %speed to 100, but leaving the motor acceleration rate at 1, the program will still run, but will occasionally stall.
B) setting the BLC%speed to 0.1, but setting the motor acceleration to 30 IPM^2, the program will stall
C) setting the BLC %speed to 0.1, but setting the motor accleration to 10 IPM^2, the program will stall.
SO, 10 ipm^2 is pretty slow acceleration but it still wont work... and it doesn't seem strongly linked to BLC speed as changing that through its full range seems to have no affect.
-
OK, you have done some really good test. Do you see why I said it is your accel. now? Bottom line is this, backlash is not cumulative, you only see backlash when you change directions or have an intermitten tool load (think of a 2 flute cutter at a very low rpm, I mean low, 30 RPM low) imagine how that may push the gantry and then it would spring back between tool contact time. These are the only times you will see backlash. If you can hold .004 with your machine your positional accuracy will be .004 if you drill 1 hole or 1000 if this inaccuracy is due to backlash alone. However, inaccuracy due to missed steps can add up, they can be cumulative but most often are random. You have done the test now to know how severely under powered your machine is to be able to hold such a tight tolerance with speed. Now don't take this wrong, I'm not criticizing your machine or your ability, I'm pretty impressed with both. But, the simple fact is, we haven't figured out a way to beat the laws of physics. You see, the amount of backlash your machine has is irrelevant to distance you ask it to move. Backlash is just that, it is lost movement. So if your running a square for instance at 30 IPM. What ever accel you have tuned your motors to is what time will be allowed to slow the one axis to a stop and allow the other to get to speed (in exact stop, CV blends this transition). When you enable backlash, your requesting that motor to move your machine the distance planned by the tool path + the distance in backlash comp. in the same amount of time. Not only that, but the amount in backlash needs to be executed almost instantly else your tool path will suffer. Imagine you had a bus and a corvette that had to run the same road course in the same amount of time. That would be a big task in its self. How much harder would it be to accomplish if every corner was so tight the bus had to stop and back up to stay on the road? You see that lowering your accel to 1 your machine almost had the guts to cut the path you plotted for it. You also see that changing BLC speed had little effect. You could probably run the comp speed to 2 or 3 hundred % (I don't think mach respects anything over 100) because usually in BLC moves, you aren't actually moving very much mass, your just taking up space. But, just the inertia of a motor rotating and instantly having to reverse can be hard to hold. Couple that with the fact that when both axis get to the other corner, they need to be in the right place you can see why high production, high precision machines cost 100s of thousands of $ and weigh 10s of tons with no axis having over 15 inches of travel and motors big enough to match the price tag.
Brett
-
So in your line of reasoning, can you explain why the x axis micro-move causes the y axis stalling?
Bare in mind I have a masters degree in mechanical engineering, I do understand what you are trying to tell me but it doesn't entirely add up.
In other words, if what you were saying is the root cause, then this should occur regardless of x axis involvement. The fact remains that the only way to generate this problem is not with rapid movements or high speed machining, both of which I do a significant amount of, but only with high aspect ratio moves (by aspect ratio I mean the ratio between the amount of movement of either axis). Inertia is not the problem here, load is not the problem here. Load and inertia independently cannot reproduce the problem.
Can you explain the odd jerking motion generated at the beginning of a rapid move AFTER a backlash comp move?
Also, can you explain why turning backlash compensation off FIXES the problem? With or without backlash compensation, the inertial loads should be virtually identical.
With due respect I think you may not have it yet.
-
Quote:
"Not only that, but the amount in backlash needs to be executed almost instantly else your tool path will suffer"
wait, maybe you know something about mach3's speeds that I don't, do the adjustments to the backlash compensation settings not in any way affect the speed? They *seem* to. If its the 'instant course correction' that is introduced by backlash compensation, why is the condition insenstive to backlash compensation speed settings?
Maybe I misunderstand what that setting does... ???
-
NEW DATA:
in an effort to further address the inertia concerns, I ran the program some more.
This time I ran it with a rapid motor rate of 120 IPM and an accleration rate of 50 IPM^2. Ran like a champ SO LONG AS BACKLASH COMP IS OFF.
with backlash componsation ON, it will not run without stalling even with the rate at 50 IPM, and 10 IPM^2 acceleration.
Now, the inertial loads on the first case are ~2x the loads of the second case, the only difference being the software backlash comp.
-
The backlash comp speed is the speed at which the comp move will be made. The speed is a percentage of rapid, not your accel. even at 100% it will still take time to make that adjustment. The only way to make that time up is to push the accel higher, just briefly. If the next move is as small as your amount of backlash, where will it get the extra time?
The settings in BLC do effect the speed but to my knowledge it only effects travel speed, not accel. I think the accel is overridden briefly so that you end at the right place at the right time. This is why you won't see it when just working one axis, it has all the time it wants to take to end at a certain position. If it is has to meet another axis at another point at the same time it really has to push to make up for the lost time and motion the BLC move took.
Brett
-
Yes, Ok, thats how I thought it worked. SO at a setting of 30% with my rapids set at 90ipm, it should do the backlash comp move at .3*9=27ipm right?
which is odd because I can make that move all day at 27 ipm with backlash comp off. The only way it becomes a problem is if mach 3 is not actually doing the backlash move at the advertised speed, which it doesn't seem to be. As I mentioned it makes a sudden jump that I cant explain, grossly in excess of what it was commanded.
Still trying to understand what the software is REALLY doing, I get the physics.
Thanks for all the help
-
Do you know if mach 3 always does the axis backlash compensations sequentially rather than simultaneously? I'm observing the software command first the y axis, then the x axis backlash comp before it starts into the rapid movement. So they dont seem to be trying to meet each other at the same place at the same time, they are taking turns, as it were. At least in my scenario here... maybe at grossly different aspect ratios it does the moves simultaneously.
If I just had someway to seemlessly generate all my gcode with seperate x and y rapid moves I'd never have this bug again, in fact thats how I've manually fixed problems with this particular program :\
-
MORE DATA:
sorry for spamming my own thread haha ;D
SO, that little jerking motion I mentioned that you can see when you slow EVERYTHING down to a crawl? thats NOT backlash compensation. It only shows up when backlash comp is turned on, but it is NOT backlash compensation.
Why do I say that? I just paid closer attention, and the y axis DRO is incrementing during that brief jump. Then it paused and started to do its rapid.
So mach 3 is throwing in an actual axis move right before it does its legitimate rapid, immediately after a backlash comp move. No idea why. If there is a setting that affects this I would love to know about it, because it seems directly related to my problem. My motors are being commanded a very rapid series of moves at full speed ignoring the motor and blc settings.
-
OK, Your right about the .3*90=27. But, the next position it has to be at, at a certain time. However long it takes, taking into account your accel., it has to make the time difference up. If that point is a long way off, it has more time to make up the lost time. If it is a short move it needs to be there right now (because the other axis is) pushing your accel exponentially higher in order to achieve this, hence the lost steps.
Brett
-
MORE DATA:
sorry for spamming my own thread haha ;D
SO, that little jerking motion I mentioned that you can see when you slow EVERYTHING down to a crawl? thats NOT backlash compensation. It only shows up when backlash comp is turned on, but it is NOT backlash compensation.
Why do I say that? I just paid closer attention, and the y axis DRO is incrementing during that brief jump. Then it paused and started to do its rapid.
So mach 3 is throwing in an actual axis move right before it does its legitimate rapid, immediately after a backlash comp move. No idea why. If there is a setting that affects this I would love to know about it, because it seems directly related to my problem. My motors are being commanded a very rapid series of moves at full speed ignoring the motor and blc settings.
That's interesting.
Do you know if mach 3 always does the axis backlash compensations sequentially rather than simultaneously
I do not.
Brett
-
Yes, I understand what you are saying, though I'm having trouble relating it to what is happening here, so let me put it in other words and see if your rationale makes good walking around sense.
1) I move to a certain x,y coordinate on my table. I do this at a rate of 20ipm. Nothing fancy, just good old fashioned G1 motion of 2 axis at once. That part is, frankly, irrelevant, but it lead up to the next move.
2) Milll arrives at destination coordinates. Lookahead tells it the next move is back in the other direction on both axes. It has to make a very small move on the x axis, and a moderate move on the y axis, and its being asked to do it at a G0 rate and using backlash compensation. It initiates a backlash compensation at a snails pace, because i have commanded it to move at 0.1% of 90ipm, which should be .9ipm. This is the meaty part of the torque curve for a stepper motor. Only thing that could be better is if the thing was just dead stopped. Mach 3 actually commands this backlash compensation to happen FIRST in the y axis, THEN in the x axis. Again, this is happening at a snail's pace. I could paint a scene of this on a canvas its going so slow.
NOTE: there is no RACE to get either axis to its destination. You mention that the x axis move being a short distance being a problem becvause it doesn't have "TIME" to get there. In reality, it has how long it takes for the y axis to make a large traverse, which is ample time to move the x axis a short distance.
3) what happens next I have no explanation for. The y axis then lurches forward at a speed far greater than either the backlash compensation speed or the acceleration rate are set for. The x axis is already backlash compensated, so there should be no 'rush' to get anything anywhere. It just lurches forward in the already compensated direction.
4) The rapid move should now be ramping up. At anything other than a glacial pace, this will fail and the Y AXIS MOTOR will stall, so long as the aspect ratio is high. Mind you, I can rapid all day in any direction in any combination of axis so long as the aspect ratio is not high.
-
The y axis then lurches forward at a speed far greater than either the backlash compensation speed or the acceleration rate are set for. The x axis is already backlash compensated, so there should be no 'rush' to get anything anywhere. It just lurches forward in the already compensated direction.
Where is the y going when it lurches forward? Y0, Y.5, Y-.5 ?
Brett
-
Just went and checked it - its ultimate destination is a move from Y1.8169 to Y0.522. The lurch advances it to Y1.801 just before it does its rapid move.
The sequence goes like this:
1)Do slow backlash comp on Y axis. No movement displayed on the MACH3 DRO
2)Lurch to Y1.801 rapidly
3)Do slow backlash comp on X axis.
4) Rapid move both axis in an interpolated move to the new X,Y coords
The x axis may well be doing an incredibly small lurch as well and I just cant detect it (maybe sub-step resolution)
Thanks again, I know the details are fine level here and its very hard to keep track of it remotely without being able to see it!
-
How many lines of look ahead do you have entered in general config.? Can you try it with this set to 1?
Brett
-
yes sir, I've fiddled with that too, as I read a post somewhere that said the lookahead might trigger a beep which takes away interrupt cycles etc...
As it happens, all the sampling I have done up to now for the sake of todays forum posts have been with it set to 2 for lookahead. Prior to encountering this problem my nominal configuration was a lookahead of 100.
I just reran the snail's pace configuration with lookahead set to 1, it does the exact same lurch behavior.
-
I dont use BC anymore but when i did this was my rule of thumb which I always recomended to others. You may want to try it out.
My 50-50-50 rule which you may want to consider.
50% - The max velocity is 50% of where your steppers will start to skip
50% - Set the shuttle Wheel setting in configuration to .0050 to .050 ( .5 too slow )
50% - Backlash speed
This is a good starting point and refine upward, but always leave say 30% headroom
BC worked quite well but nothing beats getting rid of the backlash.
RICH
-
Also, it may be of note that CV or ES settings have no affect on the lurch.
-
Thanks, can you do the same program only the first move be in the same direction as it is going now but only by the amount you have BLC set up for each axis then feed to the original position in your test. I want it to take 2 moves to get to the position. First position will be equal to BLC, second will be remainder of the distance needed.
Brett
-
Thanks!
yah I totally agree with the conservatism. My max is actually on the order of 130ipm. I have tried to alleviate this problem with 50 ipm, which would be ~38%, and I still have problems with this one particular oddball scenario. In fact, if I turn OFF backlash comp I can run this section of code at 120 ipm no problem, did it earlier today just for demonstration sake.
I have milled dozens of projects, with lots of rapid changing of mill direction and lots of rapids. This may be the first time I've ever encountered a rapid move that involved such a short move on one axis. I am really starting to wonder if this little phantom un-programmed lurch is happening, but when played out at my normal move speeds is forcing my motors into a frequency well above what they could reasonably step. Then, once they are out of phase as it were, its just a good old fashioned stall :\
For all I know, when I'm commanding a G0 move, the backlash comp might be signaling a lurch at 200 ipm... just not sure yet. That woudl be incredibly odd, but I'm trying to find a scenario wherein this problem only creeps in under these very particular circumstances, and this is where that path has led so far.
-
I used CV, exact stop, different look aheads with values from 20 to 100 and never had problems.
I will remark that that was some time ago, but, why in the world do you have you Backlash Speed set to .9%?
I suggest that you just play with the backlash setting, and watch carefully what happens to see how it is implemented.
Sorry, have not read this thread completely, so maybe I'm not getting the gest of it.
RICH
-
@Rich yes sir this thread has been a doozy hehe! It was wisely suggested that i turn down my ramp rates and bc%speed settings to better see what was going on, thats the only reason I'm running so slow is for diagnostic purposes
@Chaoticone I'm not quite sure I follow this request. Do you want me to move +x +y to the turnaround point, then program in a very small -x -y move equal to backlash dimensions, THEN go on with the rest of the rapid?
-
OK, say you got from xo yo
G0 X0 Y0
G1 F30 X-2 Y-2
X-1.996 Y-1.996 *If backlash is set to .004
X0 Y0
Brett
-
Quick read of this thread.
What size steppers are you using ....in-oz?
RICH
-
@Chaoticone
ok, thats what I assumed. I did that with the following code:
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G1 X.3362 Y1.8129 <-- TAKE UP .002 AND .004 BACKLASH in the opposite direction ON X AND Y RESPECTIVELY
G0 X0.3359 Y0.522
repeat...
Running under the same snails pace settings this *seems* to alleviate the lurch condition in the Y axis. Tried under both ES and CV.
-
@rich
282 oz-in iirc
geared down ~2:1 via toothed belt drive
-
also @rich
its the same setup I've been using for years. only have any sort of problem with it with this very particular scenario
-
I think your steppers may need to be increased, could be wrong.
I had a skipping problem that drove me goofy, and i tried all kinds of testing, until one day I really analyzed the mill and found that
when short moves were required ( like those that will be required for 3D machining ) you need motors that can provide for acceleration
and that means higher motor torque. I had 287's, worked with no problems for years, then when doing very small moves found that they became border
line depending on the code. Went to 500's and problems went away. Also did away with the backlash.
FWIW,
RICH
-
I've looked at that as an option, I could drop the cash on that and give it a whirl, but then when I see this peculiar jerking behavior generated by mach3 I'm not sure where the problem lies...
Its hard to put into words the various test programs I've run this setup through, and the only way I can generate this error is if I make a very small move on one axis while making a normal move on another. So in terms of accelerations, I feel confident I've put the motors through much worse, completely without incident.
Also, dont know if you've ever seen the Hoss cnc conversion, but as it turns out he was running even smaller motors than I am, and his rapids are comparable to mine. From what I gather I'm in good company on this size mill with these size motors, but I'll never turn down more power!! ARR ARR!
-
Checked on my microstepping configuration btw: I am setup for 1/8 microstepping
-
Have some fun and apply your engineering talents to the problem.
Amount of torque required to just move an axis, axis torque profile over full travel, also on reversal, torque required to accelerate for the smallest movement ratio in the time frame available from standstill and also when running at anticipated max feedrate, torque required for machining. Relate that to your motor torque curve for how it is wired. See what it tells you.
Nothing beats testing though........ and measuring some values. ;)
RICH
MODIFIED: never compare machines unless the systems are exactly the same, else , it's just somewhat relavent.
RICH
-
@Chaoticone
ok, thats what I assumed. I did that with the following code:
G1 X0.3382 Y1.8169 F20
G0 Z0.125
G1 X.3362 Y1.8129 <-- TAKE UP .002 AND .004 BACKLASH in the opposite direction ON X AND Y RESPECTIVELY
G0 X0.3359 Y0.522
repeat...
Running under the same snails pace settings this *seems* to alleviate the lurch condition in the Y axis. Tried under both ES and CV.
Even as it finished going to x0 y0 there were no lurches?
Brett
-
I'm sorry, in the code you posted, the last line is a G0, needs to be G1. I dont think BLC has any bearing on G0s
Brett
-
All along its been a G0 move right there, and BLC has been having an affect. I dont know why it wouldn't, rapid moves need to be compensated too, right?
I can change the code and try again tomorrow afternoon when I'll have some time. I'm reaching the bad part of the time_of_day / IQ curve.
Thanks again for all the consideration
-
I would say yes, rapid moves need to compensated I'm just not sure how or when they come into effect.
Thanks for testing. It has been interesting to say the least.
Get some rest,
Brett
-
odex, your problem sounds very familiar to a problem I have with my lathe (http://www.machsupport.com/forum/index.php/topic,23454.msg164689.html#msg164689 - read the bit below the quoted g-code).
I thought it was just an issue with the tool change and put it down to an issue between Mach and the SS, but as I can work around it, I've just been ignoring it. I've never actually tried a plain G0 move to see if the problem occurs without a tool change.
-
Ok, thanks for the heads up! I'll have to give that thread a good read.
Several years ago when I built this machine I worked out what my worst case torque requirements should be, and I had some margin iirc. I'm attempting to re-do those calculations now. Bottom line is, I see a jog that mach3 is commanding when backlash compensation is enabled that I cant explain, and it is on the very axis that is inexplicably stalling for me. Generically, the answer for a stalling motor is more torque. If you have enough torque to extrude away the dovetails on your mill table, you will never have a motor stall :) So I expect that most people would just chalk it up to physics and walk away, either choosing to up motor torque or decrease their feed/acceleration rates.
I have enough torque that I dont necessarily have to have the endmill spinning to pull it through a peice of wood... - I have always been spindle limited on machining. I have done everything I can to generate the peak g-loads I could ever see on my table and I have always been unable to induce this oddball failure mode except for when I'm using backlash compensation and on very high aspect ratio moves. Throw in the odd lurch behavior and I become suspicious that either mach3 by default is doing something unexpected BY DESIGN, or one of my files has become corrupted, or there is some kind of either mechanical or electrical cross-talk between systems that is making this a nonlinear problem :\
I can upgrade motors and probably handle whatever accelerations mach3 feeds my gear, but it would be nice to understand if mach3 is systematically making people de-tune their machines to alleviate these little phantom failures that crop up that may or may not be associated with this peculiar jumping movement I've discovered.
I can work around this issue, I was just hoping someone reading the forum was so intimately familiar with the inner workings of mach3 that they would be able to give a little insight into how mach3 plans/executes moves like backlash compensation. At any rate this has been a learning experience for me, and hopefully for others.
-
This has been for me as well odex. Have you tried your test while adjusting the shuttle speed in general config?
Brett
-
I am not sure if the way Backlash is done has been changed but I do know that at one point in time Brian was talking about sending a very fast rate to the axis to take up the lash, much faster than the accel/velocity in motor tuning. The theory was that as the motor had no load of the axis then it could do that without risk of stalling. I think that is the way it is done in the Smoothstepper but as said not sure if it was changed to do it that way if using the parallel port.
Hood
-
NO, I hadn't! I remember adjusting that years ago, but in this recent episode I had not touched it. I just checked and it was set to 0.001!
I just googled it, as frankly I forgot what "Shuttle Wheel" settings do (yay for archaic names) and apparently that is tied directly to backlash acceleration rates... Boy am I glad you asked me this. Apparently on servo systems they tend to run terrifically small numbers for this, but on stepper systems it should be quite a bit higher.
I just adjusted it to 0.050 and it does make a pronounced difference. The odd lurching behavior is still there when I execute in slow-mo but seems somewhat dampened.
This morning I changed my stepper settings to half step to just get some more torque until I figured out what was going on, so its not really an apples to apples comparison, but this is a promising lead.
Thanks for mentioning
-
That's very interesting Hood. Yes, it certainly looks like there is a sudden move, but its AFTER the backlash comp move in my case (it registers on the mach3 screen DRO), so that may not be behaving as intended in this case.
It would be nice if there were a checkbox for this setting! Maybe there is but its named something I am just too slow to pick up on...
-
:) Good, it will be interesting to see how and when it changes the moves BLC generates. Please do keep us posted as this has been the most intensive testing posted so far that I'm aware of. You have a great test bed.
Brett
-
Sure will. I commented to someone earlier that it is like I have discovered a new virus, but unfortunately I am patient zero.
-
That's very interesting Hood. Yes, it certainly looks like there is a sudden move, but its AFTER the backlash comp move in my case (it registers on the mach3 screen DRO), so that may not be behaving as intended in this case.
It would be nice if there were a checkbox for this setting! Maybe there is but its named something I am just too slow to pick up on...
Thats the backlash Comp. enabled checkbox. ;D
Brett
-
AHAHAHA touche, sir
As a matter of usability it seems very peculiar that there would be an obscurely named variable under general settings that had the capacity to override motor settings...
At least it seems like that shuttle wheel setting should be under the backlash compensation dialog box, right? Right above the enable checkbox...
I would not have expected there to be another setting that affected BLC, and I would not have inherently known to look under general settings.
This still doesn't explain the odd lurching, but per the post above it may be an intended feature, but I dont see any way to control that feature. Some machines may run a screw preload that would preclude doing an incredibly rapid backlash jerk, so you'd think you'd want to allow some flexibility of control there.
-
The only way to good flavor of how BC is implemented is to just be very attentive to what is happening.
What one sees becomes a little deceptive when starting at a crawl to implementing at a fast rate.
FROM OTHER REPLIES I have made on the subject:
The Shuttle Wheel Accel is in seconds. How exactly is the" time" applied to the backlash "cycle"? Well I don't really know.
It's internal to Mach. By observing the difference in how the motor reacts to different settings you will see that it affects the overall time
it takes for Mach to take up the backlash and at say a value of 5 you will find that over five seconds the handwheel / shaft will turn
rather slowly. At 0.005 sec its almost instantaneous. In the real slow setting, and say you jog a distance of .1" you will find there
seems to be almost 3 distinct motor responses in the cycle,....... a small rotation then deceleration...... then backlash taken up
over a time...and then accel and move to finish the distance.
So to get of flavor of it you need to start slow, observe, listen to see what is happening over an operating range.
Work your way up in settings.
When implemented in rapid movement it can change some of the required torque values just because of the applied BC mechanical movements.
There may be some quirks in MACH on it's implemenation depending on the conditions.....I don't really know .......
I will repeat that if you get rid of the need for BC you'll be a much happy camper in the long run.
RICH
-
Agreed. But having my circles circular to within .0005 instead of .002 is just so lovely :-\
-
http://www.machsupport.com/docs/Mach3_CVSettings_v2.pdf
interesting comment in there
quote:
Backlash Speed % of Max – This is needed because backlash compensation is not
constrained properly by the acceleration parameter. In a stepper system this will result in
lost steps if set to 100%, while in servo systems 100% is just fine :)
"not constrained properly by the acceleration parameter"??
yes, I will agree with that. >:(
-
The theory was that as the motor had no load of the axis then it could do that without risk of stalling.
Not sure i agree with that thinking in practice. Backlash can vary depending on the loading produced by the movement.
At least that's what i found when measuring the torque to just move an axis the other direction post BC as compared to having traveled a distance
in that direction, stop, and then measure to continue in that direction.
ie; the movement is hard in one direction and as such it creates a condition where additional load was applied to say a crappy thrust bearing situation.
FWIW,
RICH
-
Work your way up in settings.
;D
RICH
-
I missed most of this as my e-mail notifications are not getting through. As Rich has said and i alluded to earlier, get rid of the backlash. I'm suprised you have it with ballscrews unless they're real cheap ones, could it be in the bearing mounts.
-
they're rolled ball screws not ground, one ball nut per axis due to space limitations. Worse case is just under .004, which is a little above the .003 I see quoted most places that talk about ballscrews. I could get sub .001 with a good ground screw, or I could upsize the balls in mine.
Or, a cheaper option, is to find a way to get mach3 to do what I expected it to do :)
Mind you even if mach3 does its compensation I wont be planning on doing any climb milling, but this little machine just doesn't warrant the expense of going to ground screws.
-
or get a machine with ground screws and dual nuts already on it.
Anyway good luck with it, the other guys will be far better at taking this further than me.
-
My NEMA 23 Stepper Motor: KL23H2100-30-4BM is engergized when i turn on the breakout board and load mach3. They jump a little when I use the up and down arrows, but they will not turn either way.
My Syba controller card generates 4.92 volts from only a few pins as per the attached picture. Is my problem that the signal from Mach3 isn't generating output from my c10 breakout board to the stepper drive. I only have 2x drive wired so far.
-
if the stepper makes a single move when you change direction, you may have your step and directions pins the wrong way round.
-
I did have the connections wrong. But now the wiring is just like this page. http://www.automationtechnologiesinc.com/wp-content/uploads/downloads/2012/08/KL-4030WithC10.pdf
My com is set to 5vdc not gnd.
-
I too was having issues with weird stalling on rapids in Gcode. Worked great with jogs.
A few months back i started seeing the issue, after I upgraded past 2.48 to 3.043.022
Well, it came back today on a critical "one shot one kill MIL job I have to get out tonight. Thank god I did a dry run with a laser edge finder (the job is a bear - trying to line up stuff on an already machined box)
I heard it stall on a diagonal. Always the same line. Rest of the code ran great.
After putzing around with this and that in 3.043.066 today (saw it back months ago thought .066 fixed it - wrong it turns out)
Went back to 2.48; did a full uninstall - reinstall, (restored my back ups of the macros sub dir and my xml from that version - thank god I'm anal about backing up stuff and keeping old cfg's)
No issue.
It's only on code rapids, where the x and y are at different speeds. Only happens with certain rapids; when it does it's fairly consistent - it always stalls at the same place, same ammount - the stall leaves the axis at the same wrong machine coord. In this case it was 220mil off. Every time.
If it were some marginal thing with hardware, pulsing, etc... it'd be more random. Nope. If you changed a pulse rate, pulse width, etc... it'd change but repeated runs would then lose the same distance.
Something went amiss in the version 3 build. It could be PC/OS environ specific. Maybe there was something in Arts original code that was a bit fragile, dependent on some compiler, machine config, chipset, etc... dunno.
But I'm sticking with 2.48. It works. I ran 2.48 for quite a few years, hundreds of jobs with it never had an issue.
-
Hi all !
Not sure if the stalling problem has been fixed or not, but I HAD been having the exact same problem.
My newly almost finished router would stall occasionally during Jog, and considering the size of the motors I have, made no sense.
(X - 2 x 1200 Oz.In on 2505 screw and Y&Z 640's with 3:1 pulley on 1605 screws)
Solution:-
Reinstalled XP - SP3
Reinstalled Mach 3 (new D/L)
:)
-
Did you ever resolve the axis lurch after the BL comp move -