Hi
Does anyone know how much is block processing rate per second for DC3IO or GPIO4D?
and how much is block processing rate per second for Centroid software?(please tell me an example of block processing rate for Centroid software for what computer with what specification)
Thank you
**RESOLVED** Throughput rate question
Moderator: cnckeith
-
CNCguy
- Posts: 28
- Joined: Tue Mar 23, 2010 8:54 pm
- Acorn CNC Controller: Yes
- Allin1DC CNC Controller: No
- Oak CNC controller: No
- CNC Control System Serial Number: none
- DC3IOB: No
- CNC11: No
- CPU10 or CPU7: No
- Location: Pennsylvania
Re: Block Processing Rate
There are several concepts that are mixed in with "block processing rate" , but the short answer is somewhere between 400 and 1000 position updates /second for the Centroid/Ajax motion control card which is what really counts..
The good news is that the majority of users never have to worry about this question.
So much for the oversimplified answer, now for some background detail:
What is the definition of "block processing rate"?
The old traditional NC (which predated CNC Computerized Numerical Control)definition was based on "block's" of G-code per second, notice that this is not really the same as my definition of position updates/second.
The number of G-code blocks per second that can be processed by Ajax Centroid is firstly dependent on #1 your PC's processor speed and #2 The ethernet data rate (effective rate not theoretical maximum) from the PC to the MPU11 and #3 The position updates/second of the motion control card. In most cases any up to date PC motherboard and processor will keep ahead of the motion control card. and in the case of Mach3/Ajax/MPU11 systems, the processing rate of Mach3 also enters in.
Hey , Ajax/Mach3 experts, please give us your input here.
I will continue to talk about Ajax/Centroid/MPU11 from here on...
Ajax/Centroid software has two major modes of block processing:
#1 With Original Centroid accel/decel if parameter #220 set to 0, each Gcode block is sent down to the MPU11 for execution,
so it is possible to choke the system with extremely small vectors, combined with high feedrates. For example if you for some reason had some CAD/CAM generated data that was all .001" moves and assuming an overall throughput of 1000 g-code blocks/second, then you would be limited to 1"/second which equals 60"/minute! Since there is some buffering present , you wouldn't have a problem with short bursts of .001" vectors, but you would be limited eventually for long stretches of short vectors. Again , since most user's don't have long stretches of .001"g-codes they don't have anything to worry about.
#2 Ajax/Centroid's new accel/decel AD2 with parameter #220 set to 1, Gcode blocks are preprocessed and everything is reduced to 400 position updates/second, so the number of small G-code lines (blocks/second) no longer limits feedrate, however the bad news is that a new parameter STEP is now active and this can still limit the feedrates , if STEP is set to .001" or less and your PC's processor is not up to the task. STEP is not to be confused with accuracy or tolerance, STEP merely controls the distance between accel/decel/smoothing processing, endpoints are preserved. (AD2 expert how about some more input here...) The good news is that for STEP=.005 most users will never experience any limitation. The new method also works in favor of accuracy because the slower you go, the more accurate the constant 400 position updates/second (24000updates/minute) becomes.
100 in/min accuracy = .004"
10 in/min = .0004" (probably, well below the accuracy of any common milling machine)
1in/min =.00004" (definitely , well below the accuracy of any common milling machine)
Hope this helps.
By the way the DC3IO (centroid DC drives) and GPIO4D (for 3rd party (brushless) drives) , don't really affect block processing rate directly, the motion control processor and the PC processor and software are the limiting factors.
The good news is that the majority of users never have to worry about this question.
So much for the oversimplified answer, now for some background detail:
What is the definition of "block processing rate"?
The old traditional NC (which predated CNC Computerized Numerical Control)definition was based on "block's" of G-code per second, notice that this is not really the same as my definition of position updates/second.
The number of G-code blocks per second that can be processed by Ajax Centroid is firstly dependent on #1 your PC's processor speed and #2 The ethernet data rate (effective rate not theoretical maximum) from the PC to the MPU11 and #3 The position updates/second of the motion control card. In most cases any up to date PC motherboard and processor will keep ahead of the motion control card. and in the case of Mach3/Ajax/MPU11 systems, the processing rate of Mach3 also enters in.
Hey , Ajax/Mach3 experts, please give us your input here.
I will continue to talk about Ajax/Centroid/MPU11 from here on...
Ajax/Centroid software has two major modes of block processing:
#1 With Original Centroid accel/decel if parameter #220 set to 0, each Gcode block is sent down to the MPU11 for execution,
so it is possible to choke the system with extremely small vectors, combined with high feedrates. For example if you for some reason had some CAD/CAM generated data that was all .001" moves and assuming an overall throughput of 1000 g-code blocks/second, then you would be limited to 1"/second which equals 60"/minute! Since there is some buffering present , you wouldn't have a problem with short bursts of .001" vectors, but you would be limited eventually for long stretches of short vectors. Again , since most user's don't have long stretches of .001"g-codes they don't have anything to worry about.
#2 Ajax/Centroid's new accel/decel AD2 with parameter #220 set to 1, Gcode blocks are preprocessed and everything is reduced to 400 position updates/second, so the number of small G-code lines (blocks/second) no longer limits feedrate, however the bad news is that a new parameter STEP is now active and this can still limit the feedrates , if STEP is set to .001" or less and your PC's processor is not up to the task. STEP is not to be confused with accuracy or tolerance, STEP merely controls the distance between accel/decel/smoothing processing, endpoints are preserved. (AD2 expert how about some more input here...) The good news is that for STEP=.005 most users will never experience any limitation. The new method also works in favor of accuracy because the slower you go, the more accurate the constant 400 position updates/second (24000updates/minute) becomes.
100 in/min accuracy = .004"
10 in/min = .0004" (probably, well below the accuracy of any common milling machine)
1in/min =.00004" (definitely , well below the accuracy of any common milling machine)
Hope this helps.
By the way the DC3IO (centroid DC drives) and GPIO4D (for 3rd party (brushless) drives) , don't really affect block processing rate directly, the motion control processor and the PC processor and software are the limiting factors.