[Crispy2009]

Hi Guys,

I have build my second machine and in general I'm very satisfied with the outcome.

In the beginning I used Mach3 (in both of them), now I'm Running a Second Hard drive with Linux and EMC2. And though I don't get much more speed, is a lot more stable (Mach hanged up on me a number of times)

The PC running my Table is a P IV with 1 GB of RAM and what I'm looking for is ....of course....SPEED ;-)

The question I have is This....

Even though my Motors can do 3000 mm/min easily without loosing steps, when running GCODE (specially 3D) i can get it to go faster than 400-550 mm/min. Would you guess this is a PC Hardware limitation ...... what would you recommend????

Thanks

Gustavo
Quilcam.com.ar
Buenos Aires
Argentina

[andy55]

look at the latency numbers here
http://wiki.linuxcnc.org/cgi-bin/emc...l?Latency-Test
run the test on your own machine, and see if you get similar numbers, and set your base thread period accordingly.

a parallel port driven step/dir type control will always have a severe limitation between the smallest step size ('resolution') and the rapid feed speed. If you need more than a ratio of 10 - 20 000 ( the number of pulses a parallel port can typically push out per second) you should look at other hardware. A mesa pci-card (~200usd/eur) can output step/dir signals in the MHz range.

[Crispy2009]

Hi Andy,

Thanks for your reply.

My Setup is As Follows

200 Steps per Turn Steppers
1/2 Micro Steps (setup in controller)
5 mm per Turn ball screws

So I need to produce 80 pulses per mm.
To get 2000 mm/min ( 33.33 mm/sec) I would need to get 2,666.67 pulses per sec.
To get 3000 mm/min ( 50 mm/sec) I would need to get 4,000 pulses per sec.

Am I right so far???

So in order to move 2 axis at 2000mm/min I need to produce 5200+ pulses per sec., and for 3000mm/min I would need 8,000.
I'm well under the 10-20 K rate that you mention, but still not getting it.

Again, joggin around I get 4800+ mm/min. The Issue is when I run the G-CODE

The Latency Test gives me 6400+ Max Latency after 20 min. I'll let it run overnight today and see if I can get more detailed info.

Any other thought???

Thanks

Gustavo.

[andy55]

Again, joggin around I get 4800+ mm/min. The Issue is when I run the G-CODE

Please try something like this:
G0X0Y0
G0X200
This should move your machine to X=200 at your rapid feed rate
then try
G0X0Y0
G1X200F4000
This should move your machine to X=200 with a G1 move with feedrate 4000mm/min

The story is different if you have CAM-generated G-code with for example 1000-lines of very tiny G1 moves of length 0.01mm or something.

If the results of this kind of simple test are strange/wrong, you will need to post your INI file and your HAL file to pastebin or your own website so that someone can help you further.

[Crispy2009]

Hi Andy,

I went and run the G-CODE and yes it runs smooth and fast at the configured max speed. I tried both 3000 and 4000 mm/min with no problem.

As you mentioned what I'm looking at is Software generated G-CODE, and I'm going for 3D carving designs...as found in ArtCam, Rhino or 3D Models imported from 3D Studio into Mastercam, etc.

There I see lots of small moves and thats what I want to speed up...
I understand that the acceleration/deceleration will require torque from the motors and that the machine construction needs to be strong in order to reduce vibration, and CPU needs to keep up with the completed moves, and so on.

But before getting to 3000 mm/min, I'd love to get to 1000...and so far I haven't succeeded.

Any thoughts will be appreciated.

Gustavo

[samco]

Take a look at G64Px.xxx where x.xxx is the path tolerance. It combines short line segments that don't deviate out side of that. Also - acceleration helps a ton. set it as high as you can without stalling. (with some headroom)

sam

[andy55]

Any thoughts will be appreciated.

As sam already mentioned try running the code in blend mode, i.e. G64P0.01 for example (that would set a blend tolerance of 0.01mm). There is some info here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?GcodeInfo
(there's probably more about this in the EMC2 user manual)

The other approach to this problem is to try to identify or filter out from the 1000s of tiny G1 moves some larger moves such as long straight G1's, arcs G2 and G3, or some of the new fancy G-codes which are in EMC2 such as biarcs or splines. This could be done by your CAM software or at a post-processing stage.

[Crispy2009]

Thanks for the Replies. I'll make a few runs today and let you know of the outcome.

Thanks again

Gustavo

[mbushroe]

So what you are saying is that we really need a gcode optimizer, that will take thousands of tiny g1 moves and combine the linear ones, and convert the lots of small straight moves in arcs and spirals into g2 or g3 code so that you can take full advantage of acceleration and greatly decrease gcode file access?

Has anyone ever tried such a thing?

Mike

[samco]

that is essentially what G64Px.xxx does. It combines small segments into longer segments if they fall within the x.xxx tolerance.

sam

[andy55]

So what you are saying is that we really need a gcode optimizer, that will take thousands of tiny g1 moves and combine the linear ones, and convert the lots of small straight moves in arcs and spirals into g2 or g3 code so that you can take full advantage of acceleration and greatly decrease gcode file access?
Has anyone ever tried such a thing?
Mike

All the commercial CAM programs I have seen (Mastercam, Surfcam, etc) have filters that combine collinear points into longer lines and detect arcs in the principal planes (XY, XZ, YZ).

there is a simple filter in opencamlib which detects points that lie on the same line, to within tolerance:
lineclfilter.cpp - opencamlib - Project Hosting on Google Code

an arc filter is on the to-do list. your patches are welcome.

Anders

[mbushroe]

samco,
I had assumed from andy's previous post that G64Px.xx combined consecutive linear moves that were within tolerance from the original pile of short moves, but I did not think it also combined straight segments into arcs. But I did not think that it could add acceleration terms to a combined sequence of linear moves to get smother, faster movement where allowed.


andy, great to hear that something like what I was thinking of is already being developed. If I wasn't already behind on building my restrap to build my Mendel to help me build next year's underwater robot, I would love to jump in and try a few patches. The basic concept reminds me of the peep-hole optimizer we wrote as a homework assignment many years ago in compiler design class. The basic concept was that a small 'stack' of lines of code are stored, and a regular expression string matching is done from a file containing a list of patterns of several commands that can be combined into fewer steps. It would take something a little smarter to watch for non-fixed rate moves that can not only be combined but sped up when it can be made smooth and not loose step count.

Mike