| | |
I built a gantry style mill. I surfaced the spoilboard no problem. I've tried a few times now to cut out my first project and here is what's happening. I have it set to relief cut with a 1/4" bit and it's set to make multiple passes at an increasing depth of 1/8" so it would be three passes to get to it's final depth of 3/8". It makes the first several lines no problem with the proper depth and then Mach seems to be adjusting the depth and before I know it it thinks 0 it's 1/4" below the actual work 0. It progressively gets worse and I can't figure it out. It's cutting an area 12 x 10 and it will cut out 12 x 3 of it on it's first pass before it starts going wrong. I can't see anything in the G-Code that is adjusting what Z is to change where it thinks zero is. Any ideas? When I run it in the simulation it looks perfect. In Mach it looks good too but the z position changes. I've tried to run this 3 times, each time I recompile the g-code from ArtCam and each time it messes up.
Sent from my DROID BIONIC using Tapatalk
Last edited by SpaceCase614; 10-05-2011 at 11:55 PM. Reason: Added G-Code
This is just a guess...
Can you manually jog the z-axis up and down and get repeatability of the position? Does the motor sound different when it is going up vs. when it is going down? Is it possible that your stepper motor is losing steps due to mechanical binding or gravity forces when moving in the up direction?
Yes I can get repeatability on z-axis movements. Motor sounds constant through all motion. This is my first "project" as in relief cut but I've done the spoilboard surfacing which was flawless and did a drilling patter with plenty of up down across my 28.5" x 59" table. The weird thing is that it seems to not be off by a random amount but it's exactly .25" off when my step down is .125" for my bit. I rechecked my z-axis movement distance and it's dead on. I'm using Keling 425oz Nema 23 motors.
Think I might have found the answer in another thread. I guess I'll get a PCI Parallel port and give it a shot.
http://www.cnczone.com/forums/diy-cn...ing_steps.html
If the problem is related to weak "drive" out of the parallel port, one other possible approach to fixing it would be to use a "buffer board" such as the one from CNC4PC linked below (to improve the signal characteristics and available drive current from the LPT pins):
CNC4PC
I ordered a PCI Parallel card and I also ordered that part from CNC although it's back ordered. Hopefully a combination of the two will solve this. It took me months to get this all up and running and it was disappointing yesterday to not see it work as expected but it is the first time it's done something with two axis moving at the same time.
Should I bother with the other steps in the solution thread? Changing the kernel speed and stuff? I'm currently running at 25000 Hz. Debounce and Index are 0.
Generally setting the kernel speed to 25,000 is a good idea when getting started. If everything is working well, then you can consider bumping it up to 35,000.
As for the other suggestions in that thread, the best approach would probably be to make one change at a time followed by extensive testing (in order to isolate the effects of specific changes). If you had access to an oscilloscope for monitoring the signals from the parallel port, you might be able to determine for certain whether or not the source of your problems was identical to what was described in that thread. Otherwise, proceeding one step at a time is probably the best approach.
I'm thinking it has to do with that because it only loses steps on the z-axis when the z is moving along with another axis. If run a test program to move the mill all over but the z is on a different line so it acts all by itself then it's fine. If I put in multiple movements on the same line then after some time it loses it's z zero but still thinks it's zero which I saw happening and didn't get over to hit my e-stop in time which snapped my bit off when I was testing. Doh. Made me realize with such a large table I need multiple e-stop buttons.
If your z-axis motor were different from your y- and x-axis motors, then I might also consider questioning whether or not the power supply had sufficient current output capacity, but since it looks like all of your motors are identical, it's hard to see how that would explain the problem occurring only on the z axis.
Yes all motors are identical. I found in yet another thread something that could explain it. They said because of the acceleration speed of my z axis and the sheer weight of the z-axis it loses steps on the up travel making it think zero is lower than it actually is. This is what it's doing but I'm going to run a simulation of 100 up down movements and see how far off I am at the end. Then cut my acceleration in half and see where I'm at. It makes sense to me because it only does it on the z and that's the only axis with gravity acting against it and my Z is pretty heavy. It holds strong and appears accurate but if it's losing twice what it's plunging as they say that would explain why losing it. I'm dropping my z speed to 30 in/m and accel to .5 in/sec from 60 in/m and 1 in/sec. Will test it out in a couple hours and post results.
Here are the results of my tests.
The code was simple.
G0 z1.000
G0 Z1.125
repeated over and over
Test 1: 50 cycles of code, 1" per sec acceleration
Result 1: Z axis is 0.0320 lower than start
Test 2: 50 cycles of code, .5" per sec acceleration
Result 2: Z axis is 0.0318 lower than start
Test 3: 250 cycles of code, 1" per sec acceleration
Result 3: Z axis is 0.379 lower than start
Test 4: 250 cycles of code, .5" per sec acceleration
Result 4: Z axis is 0.380 lower than start
Test 5: 250 cycles of code, .25" per sec acceleration
Result 5: Z axis is 0.380 lower than start.
Seems acceleration has nothing to do with it. Are we back to voltages coming from the parallel port? Total z-axis weight is probably around 20lb with a Nema 23 425oz motor holding it.
I can only imagine how much worse it will be the longer I run the code for.
Posting Permissions
| | |
LinkBack URL
About LinkBacks
