http://www.youtube.com/watch?v=oKGabw603x0

Thanks for the answers Guys.

Dave, good to hear from you. Hope those medical issues are now behind you.

Could you recommend a bit of G code to test if that is the issue?

I did more testing today, and I think my initial conclusions that it was
threading related is wrong.

I had tested rapids back and forth, and it returned to it's starting point.

Feedrate moves back and forth also return to the starting point reliably.

Threading back and rapid forth lost motion.

I have now determined that feedrate back and rapid forth also loses motion.

Regards
Mark

Dear dkowalcz2000

   many thanks for clearing up the question about different thread pitches for X
& Y axis.....Such info is extremely valuable to all us Newbies!!
   Regards
   Andy

[Non-text portions of this message have been removed]

David:

   Replying to list as well to keep everyone apprised, there's no reason why a
g540 wouldn't work with TCNC.  Mariss has kept the use of the parallel port pins
on his box to a very conventional "2-9 OUT, 1,14,16,17 OUT, 10-13 and 15 IN
which is the same port setup that we're all using.

   This article helps explain the difference - no one is using strict EPP for CNC
(and there's no other difference with SPP nowadays) but there's really no harm
in calling it that.

http://www.beyondlogic.org/epp/epp.htm

   I have no plans to implement the charge pump though, as I consider it a fairly
dangerous idea.  There's no way to control the port state before TurboCNC gets
control of the ports, and the way the charge pump is implemented doesn't protect
from any failure modes that aren't already addressed by dint of using step and
direction protocols.

   Please put category 0 (all power off to machine) e-stops on your machines,
it's the safest method and in some areas legally required as well.

-Dave Kowalczyk
http://www.dakeng.com

--- In turbocnc@yahoogroups.com, "andersondavid84" <andersondavid84@...> wrote:
>
> I have no problem in setting both my computers to EPP. My problem is
> that EPP is crucial for home switches to work.
>
> The G540 Initial Setup manual says:
> "Your parallel port must be set to EPP mode in BIOS for the parallel
> port to work correctly with the G540. If it is not in EPP mode some
> functions of the G540 will not work."
>
> In reply to my question "What functions are not available if EPP is not
> enabled?"  Mr. Freimanis replied:  "If EPP is not enabled the computer
> can get no feedback from the G540. This means your computer is only
> sending signals and will not receive them from the G540. This will not
> allow you to use software E-Stops or home switches."
>
> I inaccurately said soft limits instead of home switches. Software
> E-Stop and home switches are part of TurboCNC. Because the G540 is an
> integrated package, it handles an E-Stop from within the control
> software (ESC in TurboCNC) through a hand shake over the parallel port
> so that the enable line on the controller  is disabled. The manual
> states: "While disabled, the motors freewheel (zero torque) and the
> output terminals shut off." The way TurboCNC handles a software
> emergency stop appears to be: quit sending commands to the motors and
> ask for confirmation before proceeding. Probably it's  method is
> adequate.
>
> The matter of home switches is more important to me. It still doesn't
> come through why home switches will not work without the EPP enabled.
> That is why I asked if anyone had used TurboCNC with the G540 package.
> Almost surely it could be made to work with program modifications. Don't
> want to do that.
>
>
> --- In turbocnc@yahoogroups.com, "das_innere_ich" <tommy.ramberg@>
> wrote:
> >
> > Setting the parallel port up as EPP is quite simple. If you check out
> the initial setup manual on geckos homepage, it says how to do so right
> there.
> >
> > I believe you are talking about the watchdog. TurboCNC does not have a
> watchdog feature, so you will have to switch that off in the G540. I
> just checked the initial setup manual, and it states that there is a
> switch under the cover of the G540. You will have to open it up and
> disable the watchdog.
> >
> > Soft limits? TCNC does not have that. Don't know if mach does either.
> TCNC checks the parallel port inputs naturally. Should not be any
> problem.
> >
> > --- In turbocnc@yahoogroups.com, "andersondavid84" andersondavid84@
> wrote:
> > >
> > > Has anyone setup TurboCNC to work with the G540 controller? The G540
> requires turning on EPP (enhanced parallel port or bidirectional
> parallel port) in the computer's BIOS. That allows the G540 to talk to
> the computer for software emergency stop and soft limits. Does TurboCNC
> naturally accept input from its controller hardware? If not, is there a
> hot-fix or other method to make this work? Thank you.
> > >
> >
>

Andrew, et al:

   There's no version of TCNC that requires identical pitches (all the way back
to v1.0) on axes.  I'm pretty sure most of the software is similarly flexible -
the math for coordinated motion pretty much requires it as a side effect of
being able to move at any angle or speed.

   I'll probably pull the v5 beta off the site soon though - it was a nice
experiment but the response from the "fans" was pretty unanimous to stay with
DOS for the time being.

-Dave Kowalczyk
http://www.dakeng.com

--- In turbocnc@yahoogroups.com, "Andrew Mathison" <andrewdavid.mathison@...>
wrote:
>
>   Hi,
>   is all software affected in this manner, that the X & Y must be the same
pitch? I have a feeling that EMC2 can be set up with different values (only read
the documentation some months ago, an EMC2 user would be far better to ask!)
>
>   Also the software for an SMC stepper card can have each axis with a
different thread.....(but that software ONLY works with SMC cards from
Germany).....I can fully believe that many softwares cannot handle that
though......
>
>   No criticism, but why would one have different threads on the X & Y axis??
That comes as a bit unlogical/impractical to me.......but I am a newbie
too.......On my first (and only finished!) machine I have used the same thread
on all 3 axis......that appealed to me at the time! I will continue to do that
on all future machines too....
>
>   Best Regards
>
>   Andy
>
>
> [Non-text portions of this message have been removed]
>

Folks:

   Yeah, I'm still around, had some health issues ths past year and of course
work is omnipresent.  Apologies for dropping off the radar a bit there!

   I've been using TurboCNC a lot for production work the past few years, which
aside from being just plain good fun has helped identify some of the sticky
wickets in the software.  Will post some status stuff later on...

-Dave Kowalczyk
http://www.dakeng.com

--- In turbocnc@yahoogroups.com, Slavko Kocjancic <eslavko@...> wrote:
>
> About 2-3 months ago I have contact with Dave. It say's that christmas
> should be born time for V4.2
>
> Slavko.
>
>
> Art Eckstein pravi:
> > Last time I talked with Dave, he indicated lurking quite often, but
> > not posting.  I know he has been up to his eyeballs with work the
> > past few months!  Hopefully, he will be able to get the next version
> > out by this Christmas???
> >
> >
> > Country Bubba
> >
> >
> > At 09:32 AM 10/18/2009, you wrote:
> >
> >> is dave k still around (in this group)
> >>
> >>
> >
> >
>

Mark:

   I found a bug a month or two back that may be part of the issue - it has to do
with setup for the step timing at move onset.

   Ed and I have noticed some "creep" showing up on long turning runs (1000+
parts) and initially I chased a lot of things (heat, lube, speeds, chatter, etc)
- the problem is just a really simple matter of misplaced addition.

   This is in Motion.pas, line 1242-ish:

====================

   {Prime the pump}
   {assign steptimes and stepintervals for each axis}
   for n := 1 to AxNum do
     begin
       if Steps[n] <> 0 then
         begin
           WinStatus.UpdateAxis(n, TRUE);
           StepInterval[n] := (1 / StartV[n]);
           tInterval[n] := (1 / TargetV[n]);
           eInterval[n] := (1 / EndV[n]);
           {Some safety margin before move begins}
           StepTime[n] := MarginTime + Clock + StepTime[n] * TicksPerSec;
           inc(Done);                    {Load done variable}
           EndSteps[n] := 0;
           Exact[n] := FALSE;
           if (CNCMachine[n].AxDriver = 0) then
             StepAX(n, Sign[n]);         {Preload direction bits for step/dir
axes}
         end;
     end;

   SetPorts;                             {Set direction bits}
   pDelay_Short(PulseWidth);             {Wait for dir bits to settle}
   pDelay(ReverseDelay);

====================

   See the bug?  The steptime is calculated some 500uS into the future, but based
on an old clock read that happened before the screen updates and the addition of
a "reverseDelay" that may be a second or two long.  When I got rid of this the
moves were right on, but I didn't test threading specifically.  Delete or
comment out these two lines:

   pDelay(ReverseDelay);
   WinStatus.UpdateAxis(n, TRUE);

   or put a large value in for "MarginTime".  The real fix involves hoisting the
reverse delay in on a more robust level.

-Dave Kowalczyk
http://www.dakeng.com

--- In turbocnc@yahoogroups.com, "tjwal" <John.Walker@...> wrote:
>
> Mark
> I am CNC wanna be so the G code is greek to me.
>
> the only other thought I have in regards to debugging the problem is to run
the thread cut for a different distance and see if the change in z is constant
or whether it is dependent on the length of the thread. That way you can tell
whether z is drifting or whether it is a step change.
>
> JohnW
>

Good Idea. I'll try it.

Mark
I am CNC wanna be so the G code is greek to me.

the only other thought I have in regards to debugging the problem is to run the
thread cut for a different distance and see if the change in z is constant or
whether it is dependent on the length of the thread. That way you can tell
whether z is drifting or whether it is a step change.

JohnW

--- In turbocnc@yahoogroups.com, "rotarysmp" <mark.wrathall@...> wrote:
>
> Thanks for the answer, but that is not what is happening.
>
> What you mean is the A parameter in the G76 word.
>
> As I said below, I started with A60. TurboCNC infeeds along an angle of 1/2A
to simulate the inclined compound you speak of.
>
> This is not what is happening on my lathe. I tested it with a Dial gauge and
no "A" in the line (Which means radial infeed) and each time TurboCNC returns to
the start (Z8) it has shifted by 0.01mm. It thinks it is at Z8, but is at:
> Z7.99 after the first pass, then
> Z7.98 after the second
> Z7.97 after the third
>
> (although it is displaying Z8 after returning each time).
>
> In G76 you don't see the displayed location in Z as it just says "in motion" 
which is why I ran a program to run multiple G33's
>
> ;Starting point is Z 8
> N100 #1 = 1       ; Initialise Counter
> N110 ASK #2       ; how many passes
> N120 G33 Z-14 K1.5; Threading pass
> N130 G04 P1       ; Dwell
> N140 G0 Z8        ; Return
> N150 G04 P1       ; Dwell so I can read the location on the DTI
> N160 #1 = #1+1    ; Increment counter
> N170 If #1 EG #2 M97 O190 ;Exit if finished
> N180 M97 O120     ;Repeat
> N190 M02          : Exit.
>

Thanks for the answer, but that is not what is happening.

What you mean is the A parameter in the G76 word.

As I said below, I started with A60. TurboCNC infeeds along an angle of 1/2A to
simulate the inclined compound you speak of.

This is not what is happening on my lathe. I tested it with a Dial gauge and no
"A" in the line (Which means radial infeed) and each time TurboCNC returns to
the start (Z8) it has shifted by 0.01mm. It thinks it is at Z8, but is at:
Z7.99 after the first pass, then
Z7.98 after the second
Z7.97 after the third

(although it is displaying Z8 after returning each time).

In G76 you don't see the displayed location in Z as it just says "in motion" 
which is why I ran a program to run multiple G33's

;Starting point is Z 8
N100 #1 = 1       ; Initialise Counter
N110 ASK #2       ; how many passes
N120 G33 Z-14 K1.5; Threading pass
N130 G04 P1       ; Dwell
N140 G0 Z8        ; Return
N150 G04 P1       ; Dwell so I can read the location on the DTI
N160 #1 = #1+1    ; Increment counter
N170 If #1 EG #2 M97 O190 ;Exit if finished
N180 M97 O120     ;Repeat
N190 M02          : Exit.

First let me say that I am not running a CNC'd lathe.

When manually cutting a thread the recommended way is to set the compound at
about 30 degrees and use it to set the depth of cut.  The cut will always be on
the trailing flank of the thread.  This works better than a plunge cut that goes
straight in and cuts on both flanks of the thread at the same time.

I don't know how TurboCNC cuts threads but it could be trying to emulate the
manual method.  In this case there should be a constant ratio between the radial
infeed and the change in z

Using a 30 degree compound angle
x (radial infeed) =compound infeed*sin(60)
z (axial feed)= compound infeed* cos(60)

therefore x/z=tan(60)

Check this ratio against what you are measuring as a change in z and what your
radial infeed is.

If this is what TurboCNC is doing then rather than z drifting it should be a
step change between each pass.

JohnW

--- In turbocnc@yahoogroups.com, "rotarysmp" <mark.wrathall@...> wrote:
>
> I have a 40X1.5mm thread to turn on my CNC'd minilathe.
>
> Even though I replaced the wimpy chinese DC motor with a 1.5HP three phase and
VFD, the machine is not rigid so I need to cut it in a lot of passes with fine
infeed.
>
> G76 X37.402 Z-14 K1.299 D0.2 K1.5 A60
>
> was the code for it. Initially I ran D.2 A60, but spun the piece at about 2/3
depth. I am now trying to rescue it by playing around cutting air and changing
the starting point till I get it running down the center of the thread valley.
>
> I then ran
>
> G76 X37.402 Z-14 K1.299 D0.05  K1.5 A60
> (Lighter cuts)
>
> And in the 20 or so passes cutting air as it slowly worked its way back in, I
noticed that it seemed to be drifting in negative z, more than the A60 should
have caused.
>
> I stopped it and returned to the start and noted that the Z Zero was now about
mm closer to the chuck (Negative Z).
>
> This time I tried:
>
> G76 X37.402 Z-14 K1.299 D0.05  K1.5
> (No A therefore radial infeed)
>
> This confirmed that machine slowly drifted in Negative Z.
>
> I put a clock on the starting point and confirmed it seemed to be drifting
0.1mm per pass.
>
> (Now I know why the machine spun the work at 2/3 depth, it wasn't taking a
constant area cut, it was taking a chunk out of the thread each time.
>
> I pulled down the drive side, and noted that the Pulley on the stepper (I'm
running 2:1 reduction) was a little loose, but could only wiggle on it's flat,
not turn (should have caused more backlash, but not lost motion in -Z.
>
> Took the chance to replace the PK268-02A Unipolar Vexta which was running in
Bipolar half winding mode at 2A, for a KL23H276-30-8A running in bipolar
Parallel at 3.5.
>
> Put it all back together, and ran some tests. Both rapids an G01 do not loose
motion.
>
> G33 and G76 both loose the approx 0.1mm per pass.
>
> I had backlash compensation set at 0.131mm, so I figured TurboCNC might be
applying an extra backlash reversal in there somewhere. I deleted the backlash
comp from the .ini and restarted Turbocnc.
>
> Still no joy. Still no lost motion on Rapids or feedrate moves, but about
0.1mm lost per threading pass, either G33 or G76.
>
> Does anyone out there have a lathe they could throw a clock on and do 5 to 10
threading passes and see if they are also loosing motion in negative Z each
pass, please?
>
> I also have backlash comp on X, so I'll delete that and try again, to see if
it is applying the wrong axis compensation during threading moves.
>
> Regards,
> Mark
> Rotary SMP
>

I have a 40X1.5mm thread to turn on my CNC'd minilathe.

Even though I replaced the wimpy chinese DC motor with a 1.5HP three phase and
VFD, the machine is not rigid so I need to cut it in a lot of passes with fine
infeed.

G76 X37.402 Z-14 K1.299 D0.2 K1.5 A60

was the code for it. Initially I ran D.2 A60, but spun the piece at about 2/3
depth. I am now trying to rescue it by playing around cutting air and changing
the starting point till I get it running down the center of the thread valley.

I then ran

G76 X37.402 Z-14 K1.299 D0.05  K1.5 A60
(Lighter cuts)

And in the 20 or so passes cutting air as it slowly worked its way back in, I
noticed that it seemed to be drifting in negative z, more than the A60 should
have caused.

I stopped it and returned to the start and noted that the Z Zero was now about
mm closer to the chuck (Negative Z).

This time I tried:

G76 X37.402 Z-14 K1.299 D0.05  K1.5
(No A therefore radial infeed)

This confirmed that machine slowly drifted in Negative Z.

I put a clock on the starting point and confirmed it seemed to be drifting 0.1mm
per pass.

(Now I know why the machine spun the work at 2/3 depth, it wasn't taking a
constant area cut, it was taking a chunk out of the thread each time.

I pulled down the drive side, and noted that the Pulley on the stepper (I'm
running 2:1 reduction) was a little loose, but could only wiggle on it's flat,
not turn (should have caused more backlash, but not lost motion in -Z.

Took the chance to replace the PK268-02A Unipolar Vexta which was running in
Bipolar half winding mode at 2A, for a KL23H276-30-8A running in bipolar
Parallel at 3.5.

Put it all back together, and ran some tests. Both rapids an G01 do not loose
motion.

G33 and G76 both loose the approx 0.1mm per pass.

I had backlash compensation set at 0.131mm, so I figured TurboCNC might be
applying an extra backlash reversal in there somewhere. I deleted the backlash
comp from the .ini and restarted Turbocnc.

Still no joy. Still no lost motion on Rapids or feedrate moves, but about 0.1mm
lost per threading pass, either G33 or G76.

Does anyone out there have a lathe they could throw a clock on and do 5 to 10
threading passes and see if they are also loosing motion in negative Z each
pass, please?

I also have backlash comp on X, so I'll delete that and try again, to see if it
is applying the wrong axis compensation during threading moves.

Regards,
Mark
Rotary SMP

I can see that if TCNC switches the parallel port back to SPP when you start the
program (just noticed this part in the TCNC manual. I had no idea it did this),
there will be a problem. The problem as Mariss has explained on cnczone, is that
the G540 can't work with an open collector PP. Maybe a buffer between the pp and
the G540 would work?

--- In turbocnc@yahoogroups.com, "andersondavid84" <andersondavid84@...> wrote:
>
> I have no problem in setting both my computers to EPP. My problem is
> that EPP is crucial for home switches to work.
>
> The G540 Initial Setup manual says:
> "Your parallel port must be set to EPP mode in BIOS for the parallel
> port to work correctly with the G540. If it is not in EPP mode some
> functions of the G540 will not work."
>
> In reply to my question "What functions are not available if EPP is not
> enabled?"  Mr. Freimanis replied:  "If EPP is not enabled the computer
> can get no feedback from the G540. This means your computer is only
> sending signals and will not receive them from the G540. This will not
> allow you to use software E-Stops or home switches."
>
> I inaccurately said soft limits instead of home switches. Software
> E-Stop and home switches are part of TurboCNC. Because the G540 is an
> integrated package, it handles an E-Stop from within the control
> software (ESC in TurboCNC) through a hand shake over the parallel port
> so that the enable line on the controller  is disabled. The manual
> states: "While disabled, the motors freewheel (zero torque) and the
> output terminals shut off." The way TurboCNC handles a software
> emergency stop appears to be: quit sending commands to the motors and
> ask for confirmation before proceeding. Probably it's  method is
> adequate.
>
> The matter of home switches is more important to me. It still doesn't
> come through why home switches will not work without the EPP enabled.
> That is why I asked if anyone had used TurboCNC with the G540 package.
> Almost surely it could be made to work with program modifications. Don't
> want to do that.

I have no problem in setting both my computers to EPP. My problem is
that EPP is crucial for home switches to work.

The G540 Initial Setup manual says:
"Your parallel port must be set to EPP mode in BIOS for the parallel
port to work correctly with the G540. If it is not in EPP mode some
functions of the G540 will not work."

In reply to my question "What functions are not available if EPP is not
enabled?"  Mr. Freimanis replied:  "If EPP is not enabled the computer
can get no feedback from the G540. This means your computer is only
sending signals and will not receive them from the G540. This will not
allow you to use software E-Stops or home switches."

I inaccurately said soft limits instead of home switches. Software
E-Stop and home switches are part of TurboCNC. Because the G540 is an
integrated package, it handles an E-Stop from within the control
software (ESC in TurboCNC) through a hand shake over the parallel port
so that the enable line on the controller  is disabled. The manual
states: "While disabled, the motors freewheel (zero torque) and the
output terminals shut off." The way TurboCNC handles a software
emergency stop appears to be: quit sending commands to the motors and
ask for confirmation before proceeding. Probably it's  method is
adequate.

The matter of home switches is more important to me. It still doesn't
come through why home switches will not work without the EPP enabled.
That is why I asked if anyone had used TurboCNC with the G540 package.
Almost surely it could be made to work with program modifications. Don't
want to do that.


--- In turbocnc@yahoogroups.com, "das_innere_ich" <tommy.ramberg@...>
wrote:
>
> Setting the parallel port up as EPP is quite simple. If you check out
the initial setup manual on geckos homepage, it says how to do so right
there.
>
> I believe you are talking about the watchdog. TurboCNC does not have a
watchdog feature, so you will have to switch that off in the G540. I
just checked the initial setup manual, and it states that there is a
switch under the cover of the G540. You will have to open it up and
disable the watchdog.
>
> Soft limits? TCNC does not have that. Don't know if mach does either.
TCNC checks the parallel port inputs naturally. Should not be any
problem.
>
> --- In turbocnc@yahoogroups.com, "andersondavid84" andersondavid84@
wrote:
> >
> > Has anyone setup TurboCNC to work with the G540 controller? The G540
requires turning on EPP (enhanced parallel port or bidirectional
parallel port) in the computer's BIOS. That allows the G540 to talk to
the computer for software emergency stop and soft limits. Does TurboCNC
naturally accept input from its controller hardware? If not, is there a
hot-fix or other method to make this work? Thank you.
> >
>

Setting the parallel port up as EPP is quite simple. If you check out the
initial setup manual on geckos homepage, it says how to do so right there.

I believe you are talking about the watchdog. TurboCNC does not have a watchdog
feature, so you will have to switch that off in the G540. I just checked the
initial setup manual, and it states that there is a switch under the cover of
the G540. You will have to open it up and disable the watchdog.

Soft limits? TCNC does not have that. Don't know if mach does either. TCNC
checks the parallel port inputs naturally. Should not be any problem.

--- In turbocnc@yahoogroups.com, "andersondavid84" <andersondavid84@...> wrote:
>
> Has anyone setup TurboCNC to work with the G540 controller? The G540 requires
turning on EPP (enhanced parallel port or bidirectional parallel port) in the
computer's BIOS. That allows the G540 to talk to the computer for software
emergency stop and soft limits. Does TurboCNC naturally accept input from its
controller hardware? If not, is there a hot-fix or other method to make this
work? Thank you.
>

Has anyone setup TurboCNC to work with the G540 controller? The G540 requires
turning on EPP (enhanced parallel port or bidirectional parallel port) in the
computer's BIOS. That allows the G540 to talk to the computer for software
emergency stop and soft limits. Does TurboCNC naturally accept input from its
controller hardware? If not, is there a hot-fix or other method to make this
work? Thank you.

Hi,
   is all software affected in this manner, that the X & Y must be the same
pitch? I have a feeling that EMC2 can be set up with different values (only read
the documentation some months ago, an EMC2 user would be far better to ask!)

   Also the software for an SMC stepper card can have each axis with a different
thread.....(but that software ONLY works with SMC cards from Germany).....I can
fully believe that many softwares cannot handle that though......

   No criticism, but why would one have different threads on the X & Y axis??
That comes as a bit unlogical/impractical to me.......but I am a newbie
too.......On my first (and only finished!) machine I have used the same thread
on all 3 axis......that appealed to me at the time! I will continue to do that
on all future machines too....

   Best Regards

   Andy


[Non-text portions of this message have been removed]

I have had the same problem in the past the only way I could fix it is to have
the x axis and y axis the same. The mfg of the software  I was using suggested
it had to do with the timeing involved with the combined movement with both
axis. The z axis is a seperate movement so it didn't matter.

               Do you happen to have radius set up as for lathe?

--- On Sat, 11/21/09, barclaygeo <barclay@...> wrote:

From: barclaygeo <barclay@...>
Subject: [turbocnc] Ver 5 Problem with Axis of Different Pitch
To: turbocnc@yahoogroups.com
Date: Saturday, November 21, 2009, 11:04 AM







 









       my z & y axis's are 14 pitch and my x is 13 pitch.  I calculated them as
.0000357143 & .000384615 respectively.  I'm using gecko 201's & 10 micro steps
directly connected to the motor 1:1.  My x-axis is moving .5 inch when I tell it
to move 1 inch.  I don't know how to fix it, any suggestions.  Don't know if it
is a bug or something I'm doing wrong.

























[Non-text portions of this message have been removed]

barclaygeo,

I am not going to run your numbers but if the X is only moving 1/2 of what
is expected try doubling the number in set-up.
I seldom use built in step size wizards. Pencil, calculator and doing it
enough times so that the numbers come out the same (and half way make
sense)
I don't suspect a bug, just that for me it is often difficult to figure out
what the questions mean.

jeffD

*********** REPLY SEPARATOR  ***********

On 11/21/2009 at 4:04 PM barclaygeo wrote:

>my z & y axis's are 14 pitch and my x is 13 pitch.  I calculated them as
>.0000357143 & .000384615 respectively.  I'm using gecko 201's & 10 micro
>steps directly connected to the motor 1:1.  My x-axis is moving .5 inch
>when I tell it to move 1 inch.  I don't know how to fix it, any
>suggestions.  Don't know if it is a bug or something I'm doing wrong.
>

-
Demand Designs
Analog/Digital Modelling & Goldsmithing

http://www.gmavt.net/~jdemand
jdemand@...
-

my z & y axis's are 14 pitch and my x is 13 pitch.  I calculated them as
.0000357143 & .000384615 respectively.  I'm using gecko 201's & 10 micro steps
directly connected to the motor 1:1.  My x-axis is moving .5 inch when I tell it
to move 1 inch.  I don't know how to fix it, any suggestions.  Don't know if it
is a bug or something I'm doing wrong.

Hey guys, for those who want to build MPG. I put a test video and pdf file on
how to make it at my CNC projects page.
http://www.cad2gcode.com/cncprojects/id18.html
Cheers
Bob A