Messages

861

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: December 02, 2009, 03:17:13 PM »

While I have your attention, Ray, let me repeat my appreciation for the great manual you have produced. Only used it a couple times, but even then it has saved me a lot of time and hassle.

Thanks!  If you like that, just wait until you see what's coming in v4....   :-)

Regards,
Ray L.

862

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: December 02, 2009, 12:28:57 PM »

This sounds eerily familiar


If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.

Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.

Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.

I've had issues with the A stalling in a similar fashion, rates were WELL below anything that would cause the axis to stall.  Interestingly enough I found that reducing the rates themselves in the program did nothing to stop the stalling behavior, but when I backed down the FRO even just a tiny bit, it would no longer stall. 

The problem, as I understand it, affects "secondary" axes, and helical moves.  If you have one or more axes in motion at a reasonable speed, then do a helical move that brings in a "secondary" axis, Z in my case, the CV code does not correctly account for the acceleration capability of the secondary axis, resulting in the primary axes entering the helical move too fast, thus requiring the secondary axis to accelerate essentially instantaneously.  Apparently, it's not that the correction is not being done correctly, but rather that it's not being done at all!  The code simply wasn't there.  The same problem apparently existed until fairly recently on linear moves as well.  Brian fixed that a while ago, but never got around to making the changes to the helical move code.  He know exactly what to do, and how, so he should have a fix very soon.  I'm actually surprised this hasn't been a much bigger problem for more people.  I suspect once the new code is out, a number of problems will vanish, and many of us may be able to kick up our velocity and acceleration settings closer to the limits.

Regards,
Ray L.

863

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: December 02, 2009, 10:10:57 AM »

This sounds eerily familiar


If someone is working on this problem, they should also consider that this behavior is present on, or is triggered by the A axis.

Under certain conditions, if the A axis and the X axis (for example) start moving together, MACH ignores acceleration and just slams the X axis from zero to feedrate. I don't recall off hand the circumstances, but I posted some details on this quite some time ago.

Sounds like this may be a symptom of the same bug, so I thought it worth mentioning.

Simpson,

Yes, Brian mentioned that when I spoke to him yesterday.  I believe that problem will also be fixed when he's done.

Regards,
Ray L.

864

General Mach Discussion / Re: Rolling my own GCode

« on: December 01, 2009, 09:25:58 PM »

I only have 2D software and a buddy asked me to make a very large and shallow "dish", used for guitar building.  No problem I wrote some VB code to generate the GCode, but, I don't know what to supply it for header info.  I load it into Mach, and it stops after each line, then cuts for a bit, then stops. When it cuts it jerks. 

Its a large file, I have attached just the first portion. 

You cannot use "M" in the line numbers.  Use "N" instead, or just leave out the numbers entirely.

Regards,
Ray L.

865

General Mach Discussion / Re: CNC4PC C11G Analog Output Spindle Control

« on: December 01, 2009, 07:56:55 PM »

Hmm, Having trouble with this.  I just hooked up the 10V to the C11G because I measured the draw at @ 14mA so figured it would not hurt anything.  It sort-of works, but it takes a long time for the speed to stabilize, and it seems to be super non-linear.  Also, it seems to have different speeds depending on if you are increasing S or decreasing it.  IN other words if you type in 50, then 100, then 150, etc you get different results than if you go backward from say 500 to 450, to 400 etc.

I have it set so that 8V is the maximum and this does not seem to saturate the F-V converter. 

Suggestions?

Thanks,
Dustin

I had a C11 that I used for spindle control for a while.  I also had a difficult time getting it to work as I wanted.  I never did figure out any kind of system to get it setup properly, but I did eventually get it working reasonably well.  It was a combination of settings of step pulsewidth and steps/unit.  Unfrotunately, I don't remember what the settings were.

Regards,
Ray L.

866

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: December 01, 2009, 02:36:46 PM »

It's NOT a CV bug!

    I just did an interesting test - I wrote a simple test program that does:

    Short, 2-axis linear move to initial position at 100 IPM
    Short, 3-axis linear move to second position at 5 IPM
    Repeat the above two moves in reverse, ending up back at the start position

    This is run in a loop, and works perfectly every time.

    I then replaced the two 3-axis linear moves with a helical move between the same two points, at the same feedrate

    This faults the Z servo every time.

    I then set the Z acceleration as low as Mach would allow (~0.2), and put an oscilloscope on the Z axis STEP line.  Running the first test, I see a nice acceleration over the first ~0.5 second of the Z move.  Running the second test, the step rate goes instantly from 0 to 10kHz - NO acceleration ramp at all!  But it does appear to do a proper deceleration at the end of the move!

    Note that the behavior is exactly the same, whether I run in CV or ExactStop mode, so it's NOT a CV problem.

Regards,
Ray L.

867

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: November 30, 2009, 07:52:17 PM »

Well , now, then.
Seems to me a while back I put a post in this forum about not driving the Knee for the Z axis. Maybe , just maybe , this is one of the reasons, along with a few more. 

Ed

Ed,

Look at the bright side - Using the knee as the Z axis has highlighted a bug in Mach, that will now get fixed.  So, using the knee is a good thing!  There are several people piping up who have had this same problem, so I'm far from the only one getting bit.

What's funny about this is, what I'm making right now is my quill drive.  If I'd finished this one project without running into this bug, I NEVER would've seen it, as my quill drive will be at least fast as my X/Y axes!

Regards,
Ray L.

868

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: November 30, 2009, 05:44:00 PM »

Hi,

I have seen the same problem when machining parts with retainer "tabs"
The X & Y accellerations are very different to the Z, as the Z is a driven knee.

If I am feeding x and y at say 300mm per min, the knee tries to do the same if the tabs ramp at 45degs. (Max Z is 250mm/min)
So I have to limit the angle of the tabs so that the Z axis does not "overspeed".

I don't see this as a Mach fault as when the Z moves Mach would need to limit the X & Y feeds to match the maximum acc / vel of the knee.
So I either speed up the knee or fit a Z on the quill....or buy a VMC

ATB
Deker

It *is* a Mach fault.  What it is *supposed* to do is always respect the settings (both acceleration and velocity) of *all* axes, and keep the move within the limits of all axes at all times.  That means if X and Y are fast and Z is slow, then X and Y are slowed down so Z does not exceed it's capabilities.  Obviously this is far easier to achieve if all axes have the same capabilities, but that's not the way the real world works.  The operator should not have to worry about keeping within the capabilities of individual axes on complex moves. 

In your example, the correct thing for Mach3 to do is to run X and Y at 300 mm/min, until they get close to the tab.  X and Y should then decelerate so that when they reach the start of the tab, they are down to a speed that allows the Z axis to be moved without it needing to accelerate faster than it's maximum acceleration, or having to exceed it's maximum velocity.  Once past the tab, and the Z axis is again stopped, X and Y should then accelerate back up to 300 mm/min.

Regards,
Ray L.

869

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: November 30, 2009, 04:04:36 PM »

Brian,
    Could you please give us some details about what this bug is and in what verison it appears. I do alot of 3D machining and I have recently been chasing what appears what shows up as lost steps on Z. I've been assuming it was hardware related but maybe not. - Thanks - Tery

Tery,

My understanding is this problem has been in there for a long time, but will only be a serious problem on machines with widely different accelerations on the various axes.  In my case, X and Y accelerations are 25X the Z axis acceleration.  This is why *most* people have no problem, but guys with goofy machines like mine will see it.  It is not respecting the acceleration setting for the "slow" axis.

Regards,
Ray L.

870

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: November 30, 2009, 04:02:18 PM »

Well, the plot thickens.....   I *thought* exact stop mode would get me going, but it's not 100% reliable, so I'm still dead in the water.  I re-wired my controller so the Z axis is on a completely separate power suppply, breakout board, etc., to make sure there is no interference when all three axes are running.  This made no difference. 

I'm quite convinced at this point it is a Mach3 bug.  I can do slow helical interpolations between two points, and get it to fault a LOT.  I can do linear interpolations between the same two points all day long with no problems.  In fact, I can even do rapids between the same two points, with the Z axis acceleration set to 3X the normal value, and it never faults.  So, Mach3 seems to be violating the Z axis acceleration limit when doing circular interpolations.

Back to waiting for Brian to come up with a fix....

Regards,
Ray L.