- ballendo Safe z is tucked away in the settings page, bottom right hand corner. (this one haunted me for 30 mins last night) I ve finally made the move to machMessage 1 of 46 , Aug 1, 2004View Sourceballendo
Safe z is tucked away in the settings page, bottom right hand corner.
(this one haunted me for 30 mins last night)
I've finally made the move to mach 2 in a semi production state, though
I'm still having some issues that don't manifest themselves
with Mach 1, with identical motor tuning params, Mach 2 will still lose
track (or over accellerate) from time to time....I've got to get these
issues worked out, as I have a retrofit to do in about 2 weeks and need
to get a handle on this.
>It's probably the same bug I experienced today...
>At least in RC5, there is something wrong in the Z code...
>Not only does it sometimes go "speedy", but it also tries to go to 5
>inches and then back when the home button of the offsets page is
>pressed. (Is your roputer z axis 5 inches? Bercause I could find this
>value NOWHERE in the setup.
>Using RC5, I've just had perhaps the most frustrating day of my CNC
>In RC5 Problems exist in
>Homing/ referencing/ units/ Toolpath/ offsets/ DRO persistence/
>Jogging/ inconsistency of operation between screens(all the same
>1024.set)/ motor tuning-but this is probably just a case of need ing
>to reset the motor tuning after cahnging from th enew pusle engine to
>the old one?
>Perhaps there is still a problem with locking the dro's to setup
>Also a few things which "were" fixed are BACK?!?
>I'm D/L'g RC6 right now with high hopes... It was a VERY non-
>productive day. (For making parts)
- No. Gecko s are the de facto std. for Mach2 performance though. At least it seems that way, based on the archived message base. Except for the recent issueMessage 46 of 46 , Aug 8, 2004View SourceNo.
Gecko's are the "de facto" std. for Mach2 performance though. At
least it seems that way, based on the archived message base. Except
for the recent issue with the G201's, folks using Gecko's with Mach2
seem to have no problems, ONCE they've got them set up correctly.
--- In firstname.lastname@example.org, <rutexus@r...> wrote:
> I don't want to add any confusion to this discussion, but I want to
ask if you are using Gecko drives.
> Tom Eldredge
> Rutex USA
> ----- Original Message -----
> From: ballendo
> To: email@example.com
> Sent: Friday, August 06, 2004 1:46 AM
> Subject: [mach1mach2cnc] Re: As the sun goes down... de de deedee
de de deedee (a new sort of cnc "Zone")
> Can somebody using a slow (~500mhz) computer, preferably with
> PLEASE try these(previously posted) files, and tell me your
> SOMETHING is broken. Now if it's my drives, then how do you
> for accurate movement when the ONLY thing changed is the helix
> by changing the z departure value...?
> Seems to me that logically if one "lead" WORKS and one .001
> is erratic, and one .001 from THAT fails completely; then WHAT is
> different as far as the drive is concerned???
> Could you put a scope on YOUR Z axis step AND dir output and run
> these files again (just the three mentioned above; described
> as "fails", "erratic", and "works" in the previous post,near the
> of th elist, as I dialed into the "problem". So I thought...)
> Do you find it at all interesting that the Bzzt of steps is AT
> transition from one move to the next?(which is also 0,0,0 in this
> case.) And the additional step or two "seems to be at the
> changes??? How does the DRIVE know anything about quadrants? (dir
> change. That's its only clue.) As for plane origins, it has NO
> So what about a DRIVE would cause a sputter of steps in Z at a
> change in XY??? More importantly, what is changed for the DRIVE
> the lead goes up by only one thousandth--which will only be 2
> steps per complete circle!!!
> A certain number of steps works, ONE more is erratic, and TWO
> fails to move the Z AT ALL...
> So let's again say that these ARE slow drives. The XML I'm
> has the step length set at 15 (but most testing was at 12, and
> pre change at 6.
> I've lost 6 days on this so far. I keep thinking I'll come here
> see an "I found it B!" But alas, Not tonight either...
> Ballendo (Feeling tired, frustrated, and defeated)
> BTW, today I tried larger helical moves, and had more relatedly
> interesting results. Not sure at this point if its worth
> in a separate post.
> BUT, CV from Arc-to-Arc IS broken in BOTH Enh and 4.0 modes in
> There's a pause at the intersection between each helical circle--
> right where the BZZT happens...
> --- In firstname.lastname@example.org, Art <fenerty@a...> wrote:
> > B:
> > > The way I can make or break a file is to change the ratio of
> > > diameter to the z departure, as suspected...
> > Good, maybe I can repeat it...
> > > (THERE IS ABSOLUTELY NO WAY TO SEE THIS PROBLEM UNLESS YOU
> > > MACHINE HOOKED UP AND RUNNING.)
> > I've been testing all these on arunning machine. The Z
> exactly as
> > it should on mine...
> > > ****************************************
> > > (250mod11-fails)
> > > g90
> > > (xy hole position here)
> > > g01z0f5 (move to material surface, set F/R)
> > > G02x-.062y0i-.031j0(half circle move to edge of hole)
> > > g02x-.062y0i.062j0f5z-.042
> > > g02x-.062y0i.062j0z-.084
> > > g02x-.062y0i.062j0z-.126
> > > g02x-.062y0i.062j00z-.168
> > > g02x-.062y0i.062j0z-.210
> > > g02x-.062y0i.062j0z-.210
> > > g02x-.0620y0i.062j0z-.210 (ensure complete cutting, flat
> > > g02x0y0i.031j0z.1 (helical move out of hole,away from hole
> > > M30
> > > (end of file )
> > > :::::::::::::::::::::::::::::::
> > > Fails in all helixes--except last, as noted above
> > Nope. Runs fine here. All movement, X,Y and Z move at correct
> rate and
> > correct distance.
> > All my tests were run in CV mode enhanced pulse train at 25Khz.
> Can't find
> > any trouble at all. I'll tell you though,
> > that I cannot see a situation where the pulses can come too
> too late
> > without the TPD showing it on update.
> > It is a separate entity of its own for that exact reason. It
> > what is planned or even what your doing, it is simply drawing
> > of
> > how many pulses have gone out. It sounds to me like somehting
> is going
> > on here, if the display is drawing a helix, it simply is not
> possible for
> > the
> > steps not to be following the output or you would see sporatic
> results on
> > the update screen. On the other hand, this is CNC and the
> impossible is
> > sometimes possible.
> > The user who claimed no Z movement while the DRo was moving
> > undoubtably having some sort of tuning trouble on his axis,
> saidm it
> > jams at times while moving, so it probably is more related to
> > (This happens alot on Z's only for obvious reasons. Your XML
> > interesting to see if its repeatable then....
> > Later,
> > Art
> Yahoo! Groups Sponsor
> Yahoo! Groups Links
> a.. To visit your group on the web, go to:
> b.. To unsubscribe from this group, send an email to:
> c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> [Non-text portions of this message have been removed]