Need Help!- Xaxis starts to "jump" during routing

[Firestar]

Hi, so I just finished building my first custom CNC router based loosely on the Buildyourowncnc.com machines and running off a G540/Keling setup with mach3 and CAMBAM (In trial modes till I get things working) and most everything seems to be fine, except...

When I am using mutiple depth passes on a profile cut the lower levels will start to shift slightly so that they are offset in the Xaxis direction. Then, if I cut for too long (maybe 8min) the Xaxis offset will go from shifting less than a millimeter between passes to shifting an inch or more! My hand spends most of the time hovering over the eswitch! My motors get pretty hot by that point (not too hot to touch, just too hot to hold for more than 6-7sec.) especially my Xaxis. Also, this is only happening on the X-axis, the y and z never falter that I can tell.

all my stepper motors are the keling 381oz/in, I'm using a 1/4" upspiral bit, and my feedrate is only 30-40 ipm at 0.08" depth per pass. Please help! Is it hardware, software or what?

[Daniel233]

Hi,
My guess would be to start by reducing the x axis acceleration in mach 3, out of curiosity what is it currently set at.
Daniel

[jsheerin]

I assume you would have noticed this, but do the shapes you're cutting appear on the mach3 preview screen correctly (in other words, check that the g-code is not to blame).

If you write a short little program that just moves the x back and forth and use a dial indicator or just make some reference marks somewhere, does it always come back to the same point? If it is repeatable, start reducing the feedrate. Go really low, like 0.1ipm. See if it starts having problems moving correctly. If so your parallel port probably can't source enough current to drive the G540.

[EBC]

try climbcut.

[ger21]

What is your pulse width set to in motor tuning?

[S3MIH3MI]

I had the exact same issue and slowed the feed speed down to 15 max 20 ipm.
And had the X axis a bit too tight. The heat issue was completely gone and the cut staid true. As soon as I played around with settings and the heat came back, so did the offset in the cut.

[Firestar]

Thanks for your replies everyone!

Daniel233, my x-axis max speed was set at about 120ipm, acceleration was at about 30ipm/sec/sec. I'll try reducing it to 15ipm/sec/sec?

jsheerin, yes, I did check the gcode, everything looks fine in both cambam and Mach3. I'll try reducing the super-low feedrate test and see.

EBC, is climbcut a cambam or mach3 setting?

ger21, the pulse width is set to 2us in all axis.

S3MIH3MI, I'll try to slow down the feedrate on my cuts a lot and see if I can avoid the heat up. Does that mean my motor is underpowered and I should potentially bump it up to like a 900oz/in NEMA 34?

Since it seems like everyone is saying "try slowing down" I'll give it a try. Slow is fine with me right now as long as the cuts are accurate.

[Firestar]

*UPDATE*
So I reduced the feed-rate and xaxis acceleration and that seems to have taken care of my slight offset shifts between layers (edges look nice and clean) and the motors are definitely cooler, but while I was doing some test runs I found out how the large offsets were occurring. It would seem that during the cut, mach3 will start a movement (I can see the tool point change in the mach3 visual window) but the real tool point stays still. So that when it starts to move again, the cutting tip is in a different position in reality than where mach3 thinks it is. Oddly, this problem only seems to occur when making a movement in the X-axis, and seems to occur almost randomly, although once it starts, it keeps happening till I hit the eswitch.

[Firestar]

So I also tested repeatability by moving the xaxis at very low speeds (1 ipm and 0.1 ipm) and then zeroing the axis out at 20 to 40 ipm where I had previously observed good results. It was way off. It also made distinct clicking and thumping sounds at low speeds. If this means my computer can't source the current to run the gecko over the parallel (I'm using the motherboard port) then would using an add-on parallel port card solve this problem or would I need a new computer or an easystepper?

[jsheerin]

You might try the same thing with your other axes - run them at really slow speeds and see if they behave erratically. With my machine, I don't remember it making odd noises at the very low speeds - it just didn't move consistently. Sometimes it would move and sometimes it wouldn't. It would only have problems on the Z at normal speeds, but iirc at very slow speeds all the axes had problems. However, the noises you describe sound more like the motor is stalling. The motor shouldn't stall at low speeds though - it should be making max torque there. All the suggestions to reduce feed rate and acceleration would help with that, but it should still run okay at very low speeds as well... You might remove the motor and try turning the x axis by hand to make sure it's not binding anywhere. If it's not binding and other axes have issues at very low speed, I'd suspect the LPT port, and read on.

Here's the thread where I was figuring this out, see post 17 or so and on:
http://www.cnczone.com/forums/gecko_...g_problem.html
Unfortunately my old website disappeared a while ago and the images in that thread are gone, so I'll repost them here. The first two pics are screwy step pulses from my onboard LPT port. The last shot is from my add on port and what the first two pulses should have looked like. The pulses should have a height of about 5V, rising up from 0V which is 1 division above the bottom of the scope screen. My solution from post 21 in that thread was this, which also describes the last attached scope trace:
I installed a Rosewill pci parallel port card and this fixed my motion problem at low speeds. It's sourcing 8.2mA of current in this setup - 4.6V into a 560ohm resistor. The downside to this card is that it can't source enough current from pins 1 and 17 (only about 1mA available) to be able to control the general purpose outputs of the G540. Under load the voltage sags down to ~0.58V from 5V. Luckily there are two ports on one card, so I'm working on a cable to use some of the 'good' pins from the second port to drive pins 1 and 17 on the db25 connector going to the G540. So I'm seeing the light at the end of the tunnel.

To add to this, what I ended up doing was going to Radioshack, buying some 25 pin connectors, and using them along with some CAT5 cable to make a sort of y cable that used some pins from each of the two LPT ports of the Rosewill card and combined them into one connector at the other end for the G540. It's a pretty cheap fix to try, but without a scope to look at what your current port is doing, it's tough to say that's what the problem is with 100% certainty.

[Firestar]

Thank you, I'll try testing the other axis at low speeds first. I already checked the x-axis and everything runs smoothly with no binding. I do have a generic looking Manhattan PCI Parallel port card I could install and test as well. It may not solve my problem (wish I had an oscilloscope) but since its a free, easy mod, I might as well try it.

[jsheerin]

An easy way to test your parallel port would be to assign pins to an output that you can hold high. For example a direction pin or a pin to turn on your spindle, flood coolant, etc. Then toggle whatever setting in mach 3 to make the LPT pin go high. With a DC volt meter, you should measure 5V between that pin and ground. Then connect the pin to ground with a 560 ohm resistor. Measure the voltage across the resistor. If it's fallen a lot (like below 3V or so), your LPT port is probably causing problems. If it's still high (like say 4V or higher), you're probably fine. You can calculate the current from I=V/R, and I believe you need 5mA to drive the opto-isolators on the G540's inputs.