[cjdavis618]

I have the backlash compensation on and the machine will pause and jerk forward on a straight cut. Seems like on every level there will be some straight line cuts that will cause it to stop, then jerk forward to continue. It is causing the feedrate to be unstable and the part to look like crap and I can't figure out why.

If I disable the Backlash comp, it has no trouble. The gcode is the same between tests.

Any ideas?

I do have Shuttle Accel set to 0.1 and that helped the drop to zero problem I had, but these are seperate symptoms. The other problem showed up once the Shuttle was adjusted.

[neilw20]

The only time it is worth using is to accurately position for drilling.
With linear interpolation, all axis are slaved to the slowest axis at any one time.
When an axis is reversing to compensate for the backlash it is not moving so it is the slowest axis, and is STOPPED. All axis must stop during this reversal.

FIX THE MECHANICAL PROBLEM. Or make your program to allow for you mechanical shortcomings.

[cjdavis618]

Well, considering that I have the CNC fusion kit with oversized balls, and I have replaced all couplings with helical, etc etc etc. The only place left is the Ball Screw and nut itself. Loctite on everything and as close as I can get is .005 on my Y axis.

I have not had the kit for 6 months, much less been using it that often. maybe once every 2 weeks for an hour or so.

Right now the kit is going to have to stay as is and the backlash comp shouldn't be stopping on a straight line. All Mechanical problems are solved if the nut and screw was doing the job correctly. I will replace them soon with a double nut system. But for now, I need the machine to work so I can make some dang parts.

I've watched the code and during the straight run when it stops, there is not any change in direction or on the line of code itself. It just stops, then jerks forward.

[neilw20]

How fast is your computer?
How much ram?
What operating system? Downgrade to Windows 200 helps.
What other programs are running, or are scheduled.
What graphics system, screen resolution settings?
Do you have the tool path display window displaying toolpath?
Have you set the motor tuning/update rate too fast?
Any of the above can cause jerks.

How well are your gibs adjusted.
Are your couplings correctly fitted?
That's more to check for the backlash problem

[ger21]

Open the windows task manager and keep it on top while it's running and see if the CPU usage is at 100% when it stops.

I'm assuming that you're saying if you have code like this:

G1 X0 Y0
G1 X20 Y0

that it will stop right in the middle of that move?

[cjdavis618]

Open the windows task manager and keep it on top while it's running and see if the CPU usage is at 100% when it stops.

I'm assuming that you're saying if you have code like this:

G1 X0 Y0
G1 X20 Y0

that it will stop right in the middle of that move?

Yes, it never happens on the same line of code (Tested by using the run from here a few lines ahead and the problem doesn't happen again.) and the and the distance is usually half way between end points of the line of code. I can easily tell when the backlash comp is working on the direction of move. But like I said, this happens way past the backlash comp distance. For instance, the direction will change from left to right on X axis, and it will move 2.5" to 3" in a 6" move and stop, the jerk forward. (No Y axis or Z axis change in the code) If the problem was mechanical, there would be a stop and then constant movement when the motor picked up. But this is just a jerk forward of a higher speed than the feedrate. It is like mach knows it is behind and needs to catch up or something. This is a stepper kit.

The machine is a 2.8 Ghz Athlon X64 x2
2 Gigs ram.
AGP MSI board.
Matrox AGP video card. 64 MB.
1024x768 on an LCD using analog
The toolpath is on, but I never use that screen.
It is running windows 2000 server with all non essential items shut down.
CPU usage is running constant 24-32% when the problem occurs. This is verified with process explorer to make sure that no services are "interrupting" the priority.
I have also set it to run on one processor using affinity 1 and then raised the priority of the program to above normal.

I have been through the basics and I am a Network tech by trade. So The computer part is not the problem. The mechanical parts have been checked out and if the mechanical was the issue, then it would also occur during ops without backlash comp. But it doesn't.

I will take another PC that I have as a spare that I loan out that is a reliable pc and put that there for a while. That way I can eliminate the PC hardware as the problem.

[ger21]

In the BIOS, is there an "automatic overclock" feature? I don't remember what MSI calls it. But I have an X2 and an MSI motherboard and it did weird stuff with that feature enabled. I don't use that PC on a machine, though.

What version of Mach3 are you using? When someone has a strange problem, the usual answer is to reinstall or try a newer version.

[cjdavis618]

It is the latest one on the web. As of a couple of weeks ago I think. I'm not able to do anything with it now, but later today I will see which version. I don't have the mill set up at the moment because I am in the middle of a gecko upgrade and maybe this problem will "disappear" when that happens. I have an idea that this may be a xylotex problem as well. It doesn't seem to be a "logical" software problem, nor does it appear that the the PC hardware is at fault. But I am stretching all I can out of the xylotex kit on this X3 conversion.

There are overclocking features, but you won't catch me using them. If I want a faster processor, I will buy one. I don't believe the fraction of extra speed is worth the expense of bigger cooling and shorter life of the processor. Good thought though. I have defaulted the bios to make sure and started from scratch. I will also adjust the AGP aperture if it occurs again since toolpath was mentioned.

[neilw20]

ACPI off?
If it is displaying toolpath, try turning that off. Extra video writing can do it.
Make sure AGP setting matches the video card. I have had CPU writing to non-existent screen memory. Took 3 years to find that. Default AGP was 128. Card was 64. Identify by dragging an explorer window over the screen boundaries and see if it gets jerky at all when dragging quickly partially off screen.
Nothing in the scheduler?
Intermittent/noisy mouse generating excessive interrupts. Unplug fro a while while doing a heap of rapids backwards and forwards.
hmm...

[ger21]

I have defaulted the bios to make sure and started from scratch.

On my motherboard, that feature is ON by default.

[neilw20]

You can turn off the ACPI in windows. Disable it. Who needs it. We're not an answering service. We service answers.
There is a clock dithering thing in the BIOS to spread noise across spectrum instead of at one frequency. On by default? Who needs a wandering clock? !
Keep disabling hardware in windows till it goes away.
IDE drive repairing itself?
Disable network car for a while.
Keep killing things. You will find it eventually.
Is that native screen resolution?

[cjdavis618]

I don't have any power options turned on in bios. Nor are they set in windows. Windows Server disables that by default.

Like I said, I can't run any tests right now until I get my conversion done. Then I will look at it again.

As for ACPI, I disable all of that anyway.

It still goes back to this doesn't happen if the backlash comp is off


Thanks for the help anyway. I'll look at this again in a few days when I get the new system cutting again.

[Khalid]

I did try backlash compensation on and i am getting same jerky results.... Especially when i am jogging toward one side it also jerk intermittently...I dont know why this happening?...

[neilw20]

IMHO for Mach3 to do a move it feeds commands into a queue which has some stats on the diagnostic screen. The low level driver takes the commands out of the queue on a regular basis and the axis keep moving.
If the queue ever gets empty all movements stops.
The problem is that the upper level Windows program feeds the queue, and must keep data up to it so that it never gets emptied by the driver.
If Windows goes off into the weeds, and stops feeding the queue for a fraction of a second, then the machine stops momentarily, hence the jerk.
If the jerk has sufficient deceleration then the stepper can lose steps also.
I believe when running at 25KHz that's the rate at which the queue is being emptied. Thats 25 queue entries per MILLISECOND !. If you slow the axis rates low enough you might overcome the queue being emptied.
Hit ctrl-alt-del and have a look at performance. Is all the CPU time being consumed?

[cjdavis618]

Have you turned on Backlash comp and tested this? I understand you have a prebuilt machine and do not seem to have any backlash. But could you try it and post your results?

[neilw20]

Backlash:
http://www.cnczone.com/forums/showpo...70&postcount=2

It MUST jerk when an axis changes directions.
One thing I have seen CAM programs generate that cause this (by feeding rubbish into the queue) is lots of small moves in the same direction.
Like:
G0 X0
X0.1
X0.2
X0.3
X0.4
...
X1

The lines after G0 X0 are redundant, and causes the toolpath graphics to do too much work.

G0 X0
X1

Will do the job properly.

The cam programs often do things in slices, with total disregard from where they have been, or where they are going. Just a dumb heap of dots in effect.

[cjdavis618]

I'm not sure we are on the same page here.

The lines that are stalling are lines like this one.

X-2.6907

It will get x-1 something from current position and stall. I am aware that the comp must "jerk" on an opposite direction move, but there is nothing else happening on this particular line that should stall. This is following the same pattern the same direction.

And yes I had already tried dropping the feed rate from about 35 to about 15 to see if that was the problem. They are ALL straight line moves with no other axis moving


The drops only occur only if Backlash comp is on.


I get the point that we all should have no backlash to compensate for. I am leaving backlash on because I don't like oval holes.

[neilw20]

Can we see you G-Code file please.

[cjdavis618]

Attached. It was created with Alibre cam.

It is a simple motor plate for a Rotary table. It mostly happens on the X travel in either direction. Which I'm guessing is what Khalid's is also doing.

I have attached the part file if you need to see it. It is a simple horizontal roughing op that cuts out the profile of the the plate and then performs the ramped hole cuts. The final plate size is 2.5 but the rough stock is 2.75. So there is alot of material removal that is done around the sides first. That is when this occurs. Straight line cuts when only one axis is used. Doesn't matter what level of cut.

I have run this same file both without comp and with comp. I only see the problem with Comp enabled. I have also tried other files and re-posted this file and same result occurs. I have only seen it happen with x- lines with no other axis movement.

[Khalid]

I earlier said that when i jog one axis in one direction only i.e x=1 to x=100 then i am getting jerks or stopping of machine...It shud not be happen while jogging in one direction bcos no backlash compensation required along the staright line...