Messages

1

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 06, 2012, 11:44:36 AM »

Thank you all for the helpful suggestions. Here's more information:

Turning off the toolpath display made little or no difference. (Too bad -- I was hoping that would solve it).

The Task Manager shows the activity in both CPUs. While Mach3 is running, the graphs show small spikes in both CPUs down in the single digits. System Idle is 99% on the average (no other background processes are eating CPU time). Mach3.exe is the only additional process that shows up when Mach3 is launched, and it shows 7 threads running. Total memory used by Mach3.exe is only about 63M. There is plenty of available memory.

I think this shows that it's not a CPU problem or the need for an external graphics card.

What is it in Mach3 that schedules and calls the LookAhead calculations? It's not calling for the lookahead calculations fast enough even though there is plenty of CPU time available. Even on a simple program, when I start running it you can watch the queue depth counter counting up by about 5 per second. It doesn't matter how large I make the LookAhead, the queue depth never gets too high on any program I run. It doesn't matter if the g-code uses g93 or g94.

Any more suggestions?

2

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 05, 2012, 08:25:18 AM »

Thanks for the reply. I'm out of town today and will try the on/off button for the toolpath display tomorrow.

I don't have a video card -- it's an on-chip video (i.e. on the Intel G620).

3

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 04, 2012, 08:09:08 PM »

That's a good idea (turning off the toolpath display). On the "Configure Toolpath Dialog" I've unchecked all the boxes. That didn't do it (it's still updating the toolpath on the Program Run screen). Is there something I'm missing? I looked through the manuals and could not find how to totally disable the toolpath display during runs. How do I keep it from updating during runs? (Forgive me, I admit I'm new to Mach3).

Likewise, is there a way to turn off the updating of the GCode display? That would probably help too.

The examples I'm running are about 700 lines of g-code. (A real run would be much longer).

Your help is much appreciated.

4

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 04, 2012, 06:58:07 PM »

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).

5

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 04, 2012, 05:37:19 PM »

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?

6

General Mach Discussion / Re: Queue depth going to zero -- causes start/stop motion

« on: May 04, 2012, 01:45:07 PM »

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.

7

General Mach Discussion / Queue depth going to zero -- causes start/stop motion

« on: May 03, 2012, 07:31:33 PM »

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

8

General Mach Discussion / Re: Question on behavior of rotary axis and rollover

« on: May 03, 2012, 06:46:26 PM »

Thanks for the reply. That clarifies it.

Bill

9

General Mach Discussion / Re: Parallel port for PCI bus that works with Mach3 - just passing along info

« on: May 02, 2012, 08:47:01 PM »

I just got a SYBA PCI-Express 1-Port Parallel/Printer Card  (http://www.newegg.com/Product/Product.aspx?Item=N82E16815124083) and it's working great with a Gecko G540. I was worried about all the EPP/ECP problems that others have had with PCI cards, but no problem. I used the standard xml file from Gecko as a starting point. Be sure to set the port address correctly (it's not the default address for on-board parallel ports).

FYI -- I'm using a GIGABYTE GA-H61MA-D3V motherboard with a Intel Pentium G620 Sandy Bridge 2.6GHz processor. So far it seems to be a reasonably fast computer for very few dollars.

10

General Mach Discussion / Question on behavior of rotary axis and rollover

« on: May 02, 2012, 05:27:06 PM »

I'm new to Mach3, so forgive the beginner question. I searched the forums, but was unable to find a description on the proper behavior of a rotary axis with the "Rot 360 rollover" and "Ang Short Rot on G0" boxes checked. Heres a simple g-code file:

g93 g1 x0.0 z0.0 c0 f20
g93 g1 x1.0 z0.1 c90 f20
g93 g1 x0.5 z0.2 c380 f20
g93 g1 x0.0 z0.0 c10 f20
g93 g1 x0.0 z0.0 c0 f20

The rotation goes to 90 degrees, then continues in a positive direction to 380 degrees. But then it goes backward a full turn plus. From the description in the Install-Config guide, I would have expected that after going to 380 degrees it would consider that the same as +20 degrees (that's what modulo 360 would mean) and only go backward 10 degrees. What am I missing here?

In truth, it behaves exactly the same way when the "Rot 360 rollover" box is not checked except for the DRO display. I conclude from this that the "Rot 360 rollover" box does nothing more than effect the appearance of the DRO. Is this correct?

In a second example:

g93 g1 x0.0 z0.0 c0 f20
g93 g1 x1.0 z0.1 c90 f20
g93 g1 x0.5 z0.2 c380 f20
g0 x0 z0 c0

The last line of g-code does in fact take the short route to zero as expected. However, I'm mystified about the behavior when the code is run a second time -- the C-axis unwraps a full turn on the first line of g-code. The Diagnostics tab does not show any offsets after the program has run, yet there must be some "hidden" offset somewhere that causes the C-axis to do a full negative rotation the next time the program is run. Can anyone explain why this is happening? Is there a way to clear whatever "hidden offset" is causing this to happen?

My application is a computerized ornamental lathe (hence the XZ coordinates) with a stepper driving the spindle for very precise control of the spindle rotation (wired to the C-axis driver).