I'm running a lot of points closely spaced to get a very precise contour. The first dozen or so points run smooth, then the motion reverts to start/stop motion (i.e. appears to stop at every point rather than accelerate/decelerate smoothly through the points). The application is a computerized ornamental lathe where the C-axis is a stepper motor on the lathe spindle for very precise rotation control. A sample of the g-code is shown below:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.31761 z0.16371 c0.00 f60
g94 g1 x0.35899 z0.07267 c-0.00 f10
g93 g1 x0.35900 z0.07265 c-0.08 f40000 (Note this is inverse time mode)
g93 g1 x0.35900 z0.07265 c-0.17 f40000
g93 g1 x0.35900 z0.07265 c-0.25 f40000
g93 g1 x0.35900 z0.07260 c-0.33 f40000
g93 g1 x0.35905 z0.07260 c-0.42 f40000
g93 g1 x0.35905 z0.07255 c-0.50 f40000
g93 g1 x0.35905 z0.07250 c-0.58 f40000
g93 g1 x0.35910 z0.07250 c-0.66 f40000
g93 g1 x0.35910 z0.07245 c-0.75 f40000
g93 g1 x0.35915 z0.07235 c-0.83 f40000
g93 g1 x0.35915 z0.07230 c-0.91 f40000
g93 g1 x0.35920 z0.07225 c-1.00 f40000
g93 g1 x0.35925 z0.07215 c-1.08 f40000
g93 g1 x0.35925 z0.07205 c-1.16 f40000
g93 g1 x0.35930 z0.07200 c-1.25 f40000
g93 g1 x0.35935 z0.07190 c-1.33 f40000
g93 g1 x0.35940 z0.07180 c-1.41 f40000
g93 g1 x0.35945 z0.07170 c-1.50 f40000
g93 g1 x0.35950 z0.07155 c-1.58 f40000
   etc.

Some detective work: On the diagnostic screen, the Queue depth goes up to about 8 then drops rapidly to zero. At the point it drops to zero, the start/stop motion begins. The LookAhead is set to 20 lines. Changing it to 100 lines didn't make any noticeable change. The Queue depth never gets up over about 8. The g-code window no longer updates either (sticks at about line 20).

By increasing the angular spacing on the C-axis, I was able to Queue to fill up to about 23 (with LookAhead still set at 100) but is still runs down to zero after about 100 lines of g-code.

I need the very fine resolution to get a very smooth surface (I'm using an increment of 0.08 degrees now). A larger increment in C will show striations in the cut surface. The reason for using inverse time mode is so that the rotation of the C-axis is constant which has been found to give the cleanest cuts.

Kernel speed is 25KHz (and the Driver Test shows "System Excellent" all the way up to 100KHz). Increasing the Kernel speed had no effect.

The F40000 gives a 1/40,000 minute (or 1.5mSec) interval between g-code instructions. The C-axis is set up with 13,000 pulses per rotation, so this means only 3 pulses have to be generated in the 1.5mSec interval (this is about 9rpm). X and Z axis are 20,000 pulses per inch. Reducing the inverse time interval to F4000 makes no difference.

My guess is that the Look-Ahead calculations aren't able to keep up with the demand for the information. Is there any way to cause the LookAhead calculations to be done in batch mode prior to starting the run? Is there anything I can do to give the LookAhead calculations a bigger chunk of the processor or run it in a different thread?

I admit to being a newbie to Mach3. I've been using EMC2 up until now (which apparently does it's trajectory planning in batch when loading the g-code). I really like Mach3 now that I've used it some and would like to find a way to make it work for my application.

Hardware info:
Intel Pentium G620 Sandy Bridge 2.6GHz
Gigabyte GA-H61MA-D3V motherboard
4Gb RAM
PCI Express parallel port connected to Gecko G540

HAve you tried running it NOT in inverse time mode(G93)?

(;-) TP

Yes, I tried that and it's even worse.

By going to g94 (units per minute feed) with F20 (20 inches per minute) the movement was REALLY slow -- like 5 pulses per second on the steppers. The Queue depth did fill up, but the pulse rate to the steppers was all wrong. This is probably because of the way Mach3 interprets feed rate when there is motion on both a linear axis and a rotational axis (re: page 10-5 of "Mach3Mill_1.84.pdf). It's calculating a "correction diameter" which is apparently not valid for my situation.

So I need to use the "inverse time" mode (g93) because of my desire for a uniform C-axis rotation, plus the need to avoid the incorrect feed rate calculation in "units per minute" mode (G94)

Any other ideas would be welcome.

WHen you tried in G94 did you SET the C axis diameter so Mach3 knows how to calculate the feedrate? IF not then you were running in Deg per min not IPM for the rotary and the linear had no choice but to follow SLOWLY(;-).

(;-) TP

Don’t think feed calc is supported for the C axis. Inverse time mode is the alternative.
This was discussed a year or so ago
http://www.machsupport.com/forum/index.php/topic,19321.0.html
Al

Thanks for taking the time to look at this. It was a good suggestion to set the rotation diameter for the C axis in g94 mode. Unfortunately, that didn't change anything when running in g94 mode.

After a few more experiments, I conclude that g93 (inverse time mode) is not intrinsically the issue. Here's why -- consider the following code:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.31761 z0.16371 c0.00 f60.00
g94 g1 x0.35899 z0.07267 c-0.00 f2.00   (this is purposely set slow)
g93 g1 x0.35905 z0.07255 c-0.55 f650.00
g93 g1 x0.35925 z0.07215 c-1.11 f650.00
g93 g1 x0.35955 z0.07145 c-1.66 f650.00
g93 g1 x0.36000 z0.07050 c-2.22 f650.00
g93 g1 x0.36050 z0.06930 c-2.77 f650.00  (works just fine for about 340 lines)
    etc.

This first example works just fine for a while. The Queue depth goes up to 31 (LookAhead is set at 50) during the slow movement on line #4. There is nice smooth motion for a while, and the queue depth slowly erodes down to zero after about 340 lines of g-code. At this point I get the jerky (start/stop) movement.

Consider the 2nd example:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.31761 z0.16371 c0.00 f60.00
g94 g1 x0.35899 z0.07267 c-0.00 f2.00   (this is purposely set slow)
g93 g1 x0.35905 z0.07255 c-0.55 f2000.00   (same points as above, but about 3X faster)
g93 g1 x0.35925 z0.07215 c-1.11 f2000.00
g93 g1 x0.35955 z0.07145 c-1.66 f2000.00
g93 g1 x0.36000 z0.07050 c-2.22 f2000.00
g93 g1 x0.36050 z0.06930 c-2.77 f2000.00
    etc.

The first 4 lines are the same, then the speed is about 3X faster for subsequent point. As before, the queue depth goes up to 31 during the slow movement on line #4. Then it quickly drops to zero after about 50 lines of code (and jerky start/stop motion).

So I thought that the faster feed rate might be the problem, but not so. Consider the 3rd example:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.31761 z0.16371 c0.00 f62.97
g94 g1 x0.35899 z0.07267 c-0.00 f2.00   (this is purposely set slow)
g93 g1 x0.35900 z0.07265 c-0.06 f6500.00  (the points are 10X finer resolution, with 1/10th the time)
g93 g1 x0.35900 z0.07265 c-0.11 f6500.00  (which should result in the same over-all speed as the first example)
g93 g1 x0.35900 z0.07265 c-0.17 f6500.00
g93 g1 x0.35900 z0.07265 c-0.22 f6500.00
g93 g1 x0.35900 z0.07265 c-0.28 f6500.00
    etc.

Again, the first 4 lines are the same. Then I give it points with 10X finer resolution (at 1/10th the feed rate -- inverse time remember). So the over-all speed should be just the same as the first example, but with finer resolution. As before, the queue depth goes up to 31 during the slow movement on line #4. Then it quickly drops to zero after about 30 lines of code (and jerky start/stop motion).

I conclude from this that issue is that Mach3 can't keep up with the lookahead calculations that are required to plan the acceleration/deceleration for smooth operation and coordinated motion.

Any other things that I can try? It brings me back to my earlier question about the possibility of giving the LookAhead calculations a bigger chunk of the processor or run it in a different thread? Is there some way to shut down other non-critical real-time activities?

MACH3 has always struggled with micro segmented gcode of the nature you are using. Have you thought of changing teh Axis drives around and using A axis instead of C?  That wya you would at least try radius comp for the feedrate and not have to run G93.

What are the computer specs?? What kernal speed are you using??

WIth that small of segments you may want to try a lookahead of say 2000.

Mach3 is not realtime so that should not matter. BUT a slow computer CPU wise will make it struggle.

Just some thoughts, (;-)TP

Another thought would be to run task manager and watch the CPU load as mach3 runs the program.

MAYBE something in the background is interfering with mach3 when the loads go up on the CPU.

(;-) TP

Thanks for the prompt reply and the suggestions.

Increasing the lookahead to a larger number had no effect -- the queue depth never gets over about 30.

Nothing else is running on the computer -- just Mach3 (and no network connection either). It's a new computer, specs are:
Windows XP 32 bit (latest updates)
Intel Pentium G620 Sandy Bridge 2.6GHz (2 core)
Gigabyte GA-H61MA-D3V motherboard
4Gb RAM
PCI Express parallel port connected to Gecko G540

Kernel speed is 25Khz (and increasing that makes no difference). As mentioned earlier, the Driver Test shows "System Excellent" all the way up to 100KHz.

I'll try the A-axis idea (won't be tomorrow). I'll also check for other background processes with the task manager (good idea too).

Question -- does mach3 tend to adapt to the larger amount of RAM when it's available? Or is there some setting to make it use more RAM when available? (Might not be the issue, just asking).

How many lines of code? Try turning off the toolpath display.