Re: [Emc-users] Emc-gcode throughput
Kirk Wallace wrote: On Thu, 2010-03-04 at 20:52 -0600, Jon Elson wrote: ... snip more resources than a 3-axis program, but the super-hard stuff they usually make these parts out of are not machined at high feed rates. A ... snip This one's pretty quick: http://www.youtube.com/watch?v=0LCaRqQ8Qf8 That workpiece is almost certainly aluminum. That is a whole different ballpark than Inconel and other turbine blade materials. I *THINK* the original request had to do with turbine blade machining. Jon -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
On Fri, 2010-03-05 at 12:17 -0600, Jon Elson wrote: Kirk Wallace wrote: On Thu, 2010-03-04 at 20:52 -0600, Jon Elson wrote: ... snip more resources than a 3-axis program, but the super-hard stuff they usually make these parts out of are not machined at high feed rates. A ... snip This one's pretty quick: http://www.youtube.com/watch?v=0LCaRqQ8Qf8 That workpiece is almost certainly aluminum. That is a whole different ballpark than Inconel and other turbine blade materials. I *THINK* the original request had to do with turbine blade machining. Jon Touche' -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
I have a general question about the throughput of EMC2 and what determines it. I friend is using nurb modeling to describe the shapes that he has to mill in soft material. So far he has had disappointing results using EMC2 in that the processing of the large gcode files with many short vectors and the resulting cutting speed is too low. For most cutting moves the programmed speed of the axes is not reached in these applications. Jogging speeds on the machine is fine. Where does the problem lie? In playing with parameters such as base_thread, we found that these have some influence on the troughput and cutting speed. The processing power and latency of the PC also comes into play. It seems that careful tuning and balancing of some parameters is required. The problem is to know which ones will improve the situation best. The steppers are currently driven via the parallel ports. A MESA 5i20 card is planned to replace this. Has anybody been working on the limited throughput situation? Rudy __ Information from ESET Smart Security, version of virus signature database 4913 (20100303) __ The message was checked by ESET Smart Security. http://www.eset.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
Rudy du Preez pravi: I have a general question about the throughput of EMC2 and what determines it. I friend is using nurb modeling to describe the shapes that he has to mill in soft material. So far he has had disappointing results using EMC2 in that the processing of the large gcode files with many short vectors and the resulting cutting speed is too low. For most cutting moves the programmed speed of the axes is not reached in these applications. Jogging speeds on the machine is fine. Where does the problem lie? In playing with parameters such as base_thread, we found that these have some influence on the troughput and cutting speed. The processing power and latency of the PC also comes into play. It seems that careful tuning and balancing of some parameters is required. The problem is to know which ones will improve the situation best. The steppers are currently driven via the parallel ports. A MESA 5i20 card is planned to replace this. Has anybody been working on the limited throughput situation? Rudy Did you use G64? If not then machine wil accelerate/decelerate in each segment! If you have fast jog that doesn't be equal to fast cut speed. If you have bad acceleration for example to accelerate to max speed when move 5mm then all segments shorter than 10mm can't use max speed of machine. If you use G64 then machine will try to keep speed up but in that case it's not possible to trace exact path. If I corectly understand the EMC have one line lok ahead buffer. - Somewhere in doc's is statment that if emc is paused will decelerate at least in next line of gcode. So for me that's mean that if consequent lines is shorter tnan 5mm (in this example) then machine won't got max speed. Slavko -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
2010/3/4 Rudy du Preez r...@asmsa.co.za I have a general question about the throughput of EMC2 and what determines it. I friend is using nurb modeling to describe the shapes that he has to mill in soft material. So far he has had disappointing results using EMC2 in that the processing of the large gcode files with many short vectors and the resulting cutting speed is too low. For most cutting moves the programmed speed of the axes is not reached in these applications. Jogging speeds on the machine is fine. Where does the problem lie? In playing with parameters such as base_thread, we found that these have some influence on the troughput and cutting speed. The processing power and latency of the PC also comes into play. It seems that careful tuning and balancing of some parameters is required. The problem is to know which ones will improve the situation best. The steppers are currently driven via the parallel ports. A MESA 5i20 card is planned to replace this. Has anybody been working on the limited throughput situation? Rudy What program is used to generate the G-code? Is G61 set? I do nurbs models all the time, 99% of my work is surfacing. No speed problem. Regards, Sven -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
I wrote a message about this some time ago, but its contents are still essentially accurate: http://mid.gmane.org/20081022160842.ga6...@unpythonic.net When converting complex curves like nurbs into gcode, the relevant behavior of the motion planner is this: | Make sure moves are long enough | - | Principally because of the rule that the machine will never move at | such a speed that it cannot come to a complete stop at the end of the | current movement, there is a minimum movement length that will allow | the machine to keep up a requested feed rate with a given acceleration | setting. | | The acceleration and deceleration phase each use half the inifile | MAX_ACCELERATION. In a blend that is an exact reversal, this causes the | total axis acceleration to equal the inifile MAX_ACCELERATION. In other | cases, the actual machine acceleration is somewhat less than the inifile | acceleration | | To keep up feed rate, the move must be longer than the distance it takes | to accelerate from 0 to the desired feed rate and then stop again. | Using A as 1/2 the inifile MAX_ACCELERATION and F as the feed rate | *in units per second*, the acceleration time is | ta = F/A | and the acceleration distance is | da = (1/2) * F * ta | the deceleration time and distance are the same, making the critical | distance | d = da + dd = 2*da = F^2 / A. | | For example, for a feed rate of 1 inch per second and an acceleration of | 10 inch/sec^2, the critical distance is 1^2 / 10 = .1 inch. For a feed | rate of .5 inch per second, the critical distance is .5^2 / 10 = .025 | inch. If your curves lie in a plane, consider approximating them with arcs instead of with straight segments. This can give a better approximation with a smaller number of segments, making the typical segment longer. http://emergent.unpy.net/01171767993 - a blog entry of mine on biarcs http://emergent.unpy.net/files/papers/V1Nos1to4_22.pdf - the paper I got the math from (fig1 and associated formulae) I chose r=1 to give more-equal arcs, rather than following their method for choosing optimal r Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
On Thursday 04 March 2010, Rudy du Preez wrote: I have a general question about the throughput of EMC2 and what determines it. I friend is using nurb modeling to describe the shapes that he has to mill in soft material. So far he has had disappointing results using EMC2 in that the processing of the large gcode files with many short vectors and the resulting cutting speed is too low. For most cutting moves the programmed speed of the axes is not reached in these applications. Jogging speeds on the machine is fine. Where does the problem lie? In playing with parameters such as base_thread, we found that these have some influence on the troughput and cutting speed. The processing power and latency of the PC also comes into play. It seems that careful tuning and balancing of some parameters is required. The problem is to know which ones will improve the situation best. The steppers are currently driven via the parallel ports. A MESA 5i20 card is planned to replace this. Has anybody been working on the limited throughput situation? Rudy I don't know if there is a one true way to attack this. I run steppers too, and found quite some time back that if I were willing to give up on acceleration and use a gentler accel setting, the top speed achievable was considerably higher. However corner blending considerations will then slow it down because of the gentler accelerations being used. Without some very strong, low inertia servo's, my method seems to be the best for my work, where I often cut one-sie's, and may spend a day cutting air before actually making the part, but once the mill starts throwing chips, the part is generally usable. YMMV of course. If, OTOH, your cutting speed is limited by available spindle power and rpms, as mine is, one might want to up the accel's and give away top speed. You can, for the most part, reverse a nema 23 stepper that isn't moving a 20 tpi screw at more than a couple of inches/minute very quickly, but you cannot extend that violent an accel to more than that same couple of ipm without encountering a stall. And there goes that part, its usually wrecked. I've had it dancing on the table a few times, but not now, and its much more dependable this way. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Life is fraught with opportunities to keep your mouth shut. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
Slavko, Sven and Jeff Thanks a lot for the prompt response and the hints and information. We will use the info to investigate our problem and see if we can improve the performance. I will report back on the results. Rudy __ Information from ESET Smart Security, version of virus signature database 4914 (20100304) __ The message was checked by ESET Smart Security. http://www.eset.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
Rudy du Preez wrote: Has anybody been working on the limited throughput situation? Going to hardware step generation is definitely moving in the right direction. I did some tests a while back, on a 600 MHz Pentium III computer. I made a 2 diameter circle in 10,000 line segments. With the default smoothing, it took 250 seconds to execute. With the smoothing parameter set with G64 P0.0005 (meaning an error tolerance of 0.0005 is acceptable) this program runs in 17 seconds. At that rate, it is doing 10,000 blocks in 17 seconds or 588 G-code blocks a second. That is with a fairly slow computer by today's standards, too! I think I later got it down to 13 seconds, or 769 blocks/sec. These tests were done on a true servo system using my PWM controller board and servo amps. So, there was no BASE_THREAD task in the system, and no step pulses anywhere. I think if you need more than 1000 blocks/second, you need to examine how you are generating your G-code and see if it can be optimized. Assuming 0.001 vector segments, you could move at on inch/second while following any arbitrary curve that doesn't exceed your machine's acceleration limits. Jon -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
On Thu, 2010-03-04 at 12:41 -0600, Jon Elson wrote: Rudy du Preez wrote: Has anybody been working on the limited throughput situation? Going to hardware step generation is definitely moving in the right direction. I did some tests a while back, on a 600 MHz Pentium III computer. I ... snip Jon I looked at Jan's example of what he might be converting: http://www.starragheckert.com/sh/index.php?option=com_contenttask=viewid=89Itemid=197 (Short URL) http://alturl.com/87gd http://www.manturbo.com/en/ I wondered if block rate would be a problem with a five-axis multi-spindle machine doing complex shapes in a production setting. I suspect the current controller is hardware and software optimized for turbine blade milling, but that's a guess on my part. Stuart's machine seems to work well, but it's no Speedy Gonzales. http://www.youtube.com/watch?v=37Q5cDj1zL4 -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
Kirk Wallace wrote: I looked at Jan's example of what he might be converting: http://www.starragheckert.com/sh/index.php?option=com_contenttask=viewid=89Itemid=197 (Short URL) http://alturl.com/87gd http://www.manturbo.com/en/ I wondered if block rate would be a problem with a five-axis multi-spindle machine doing complex shapes in a production setting. It shouldn't make that much difference. Of course, a full 5-axis part program that is moving 5 axes in sontinuous motion will take a little more resources than a 3-axis program, but the super-hard stuff they usually make these parts out of are not machined at high feed rates. A LOT of people don't know about the G64 P option until they ask, then they are amazed! Jon -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc-gcode throughput
On Thu, 2010-03-04 at 20:52 -0600, Jon Elson wrote: ... snip more resources than a 3-axis program, but the super-hard stuff they usually make these parts out of are not machined at high feed rates. A ... snip This one's pretty quick: http://www.youtube.com/watch?v=0LCaRqQ8Qf8 -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
