[Emc-users] X11 file problem/HELP
Hi Let me describe my problem. I have old computer COMPACT that I took to two last EMC2 show and at the first time Ray Henry change /etc/X11/Xorg.conf to UBUNTU work. I remember it was video driver, and need to change to generic driver VESSA or something like that. Now I build new computer, and move all boards to the new box including old hard drive. The reason to moving old hard drive is that EMC2 on it has tune up already and I do not want to loose it for now. When I start computer it ends with massage- failed to start X server-graphical interface. And it shows ( = = ) using config file : /var/log/Xorg.0.log and /etc/X11/Xorg.conf After several OK, it takes me to aramemc2d1-desktop tty1 [EMAIL PROTECTED]:$ _ So I think I need go back and change VESSA driver back to what was originally with UBUNTU. I think I am looking for help to how to change the driver on X11. I am not sure that problem in X11 but, not sure. Please help with my mysteries problem. Thanks aram - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] X11 file problem/HELP
Hi Aram The reason we had to change the xorg.conf file was that the installer program did not find a proper one. I do seem to remember using vesa as the definition for that box. This (vesa) is a very common driver for on-board video displays. I don't recommend moving a hard drive to a new box unless you've already installed on that box's own hard drive and the swapped one is just for extra stuff. There are way many other things different between motherboards and the boot hardware checker is not always able to find all the things it needs for the new. If it were mine, I'd put the hd back, find a usb stick and move the files I want to keep to that and install Ubuntu in the new computer from a CDROM. My second choice would be to start a live session on the new box from a CDROM and look in /etc/X11/xorg.conf and see what it is using for a display driver. If you have the old hd in place during this live session you could mount it and edit its xorg.conf to match the one found in the live session. You would be changing the file in something like /media/hda(1)/etc/X11/xorg.conf. Make a backup in the same directory with a name that is easy to remember and change back because you may well be working in a text mode editor like vim. My latest install of the 8.04 beta also failed to find the right display driver. I was getting some really strange display issues with the Axis gui. We sorted it out with folk on IRC and I'm as happy as a Rayh --- [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Cc: Enhanced Machine Controller emc-users@lists.sourceforge.net Subject: [Emc-users] X11 file problem/HELP Date: Tue, 22 Apr 2008 00:00:53 -0600 (MDT) Hi Let me describe my problem. I have old computer COMPACT that I took to two last EMC2 show and at the first time Ray Henry change /etc/X11/Xorg.conf to UBUNTU work. I remember it was video driver, and need to change to generic driver VESSA or something like that. Now I build new computer, and move all boards to the new box including old hard drive. The reason to moving old hard drive is that EMC2 on it has tune up already and I do not want to loose it for now. When I start computer it ends with massage- failed to start X server-graphical interface. And it shows ( = = ) using config file : /var/log/Xorg.0.log and /etc/X11/Xorg.conf After several OK, it takes me to aramemc2d1-desktop tty1 [EMAIL PROTECTED]:$ _ So I think I need go back and change VESSA driver back to what was originally with UBUNTU. I think I am looking for help to how to change the driver on X11. I am not sure that problem in X11 but, not sure. Please help with my mysteries problem. Thanks aram - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
To the best of my knowledge, there has been no attempt to optimize the performance of the interpreter. If there is strong feeling that this might be a problem, I suspect that it could be improved significantly. My general experience with products that have never been optimized is that a factor of two is generally easy. A factor of five or ten isn't unusual. Ken - Original Message - From: Jon Elson [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Monday, April 21, 2008 11:52 PM Subject: Re: [Emc-users] VFD Interference At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2 diameter circle. Each chord is roughly 0.0006 long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] X11 file problem/HELP
Hi Thanks Ray, I want to say that when I install new UBUNTU on other hard drive on the new box, computer start and UBUNTY was working perfect. So I think I will move HD back to old box, copy EMC2 PID and tune up parameters from old HD and put it on other HD with other seting UBUNTU on new box. It is easy to me, I think. aram Hi Aram The reason we had to change the xorg.conf file was that the installer program did not find a proper one. I do seem to remember using vesa as the definition for that box. This (vesa) is a very common driver for on-board video displays. I don't recommend moving a hard drive to a new box unless you've already installed on that box's own hard drive and the swapped one is just for extra stuff. There are way many other things different between motherboards and the boot hardware checker is not always able to find all the things it needs for the new. If it were mine, I'd put the hd back, find a usb stick and move the files I want to keep to that and install Ubuntu in the new computer from a CDROM. My second choice would be to start a live session on the new box from a CDROM and look in /etc/X11/xorg.conf and see what it is using for a display driver. If you have the old hd in place during this live session you could mount it and edit its xorg.conf to match the one found in the live session. You would be changing the file in something like /media/hda(1)/etc/X11/xorg.conf. Make a backup in the same directory with a name that is easy to remember and change back because you may well be working in a text mode editor like vim. My latest install of the 8.04 beta also failed to find the right display driver. I was getting some really strange display issues with the Axis gui. We sorted it out with folk on IRC and I'm as happy as a Rayh --- [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Cc: Enhanced Machine Controller emc-users@lists.sourceforge.net Subject: [Emc-users] X11 file problem/HELP Date: Tue, 22 Apr 2008 00:00:53 -0600 (MDT) Hi Let me describe my problem. I have old computer COMPACT that I took to two last EMC2 show and at the first time Ray Henry change /etc/X11/Xorg.conf to UBUNTU work. I remember it was video driver, and need to change to generic driver VESSA or something like that. Now I build new computer, and move all boards to the new box including old hard drive. The reason to moving old hard drive is that EMC2 on it has tune up already and I do not want to loose it for now. When I start computer it ends with massage- failed to start X server-graphical interface. And it shows  ( = = ) using config file : Â/var/log/Xorg.0.log and Â/etc/X11/Xorg.conf After several OK, it takes me to aramemc2d1-desktop tty1 [EMAIL PROTECTED]:$ _ So I think I need go back and change VESSA driver back to what was originally with UBUNTU. I think I am looking for help to how to change the driver on X11. I am not sure that problem in X11 but, not sure. Please help with my mysteries problem. Thanks aram - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
At 07:35 AM 4/22/2008, you wrote: To the best of my knowledge, there has been no attempt to optimize the performance of the interpreter. If there is strong feeling that this might be a problem, I suspect that it could be improved significantly. My general experience with products that have never been optimized is that a factor of two is generally easy. A factor of five or ten isn't unusual. Ken I thought EMC interpreted the entire G code program as it was loaded and not in real time when it is running. Which explained why the modal codes display is only correct at the end of the program run. If not why does it take so long to load a program? If only for the graphics can it be disabled and the plot created as the program is run? __ Andre' B. Clear Lake, Wi. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] block processing rate
Kenneth Lerman wrote: To the best of my knowledge, there has been no attempt to optimize the performance of the interpreter. If there is strong feeling that this might be a problem, I suspect that it could be improved significantly. My general experience with products that have never been optimized is that a factor of two is generally easy. A factor of five or ten isn't unusual. I don't know if this is a problem. If a factor of five can be obtained with just a modern CPU, that would be over 100 blocks a second. I think that would compare quite favorably with commercial controls. I wish the guy that called me had left his number, so I could call him back with the results. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
Jon Elson wrote: At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2 diameter circle. Each chord is roughly 0.0006 long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. First a quick look at other bottlenecks: There is no way the interpreter is only doing 39 lines per second. I would expect the interpreter to be able to handle tens of thousands of lines per second on a fast PC. I can't think of a meaningful test of interpreter speed at the moment, but for all practical purposes it is fast enough that we don't really care much. The next bottleneck is passing commands to the motion controller (realtime code). EMC's motion controller has basically two parts that both run once per servo cycle. One is the command handler (mostly in command.c) and the other is the control code (control.c and lots of files linked to it). Each time it runs the command handler takes precisely one command from the user space code and either executes it or queues it (depending on the type of command). That means it with the default servo rate of 1KHz you can at best send 1000 commands per second to the motion controller. In practice the limit will be a bit lower, since the user space code sleeps once it sees that the motion controller hasn't accepted a previous command. The controller will accept the command after 1mS, but if the Linux (non-real-time) doesn't wake up the interpreter for 3mS, the max throughput drops to 333 commands per second. Once the command handler gets a motion command it goes into a buffer that holds 200 moves. When you start a program, the interpreter and command handler quickly get 200 moves ahead of the motion (unless you have tiny moves like your test program). The 200 move buffer is what lets us run the interpreter in user space. It's also the reason that the active g-code display doesn't track the program. Neither of those things explains your results. You said the times were the same with feeds of 30 and 60 ipm, but that does NOT mean the timing is not acceleration related. Did you try with two different accel values? Your segments are 0.0006 long, and you are requesting 60 ipm or 1 inch per second. The only way you will reach the requested speed is if your move is a trapezoid - with accel, cruise, and decel phases. The only way you get a cruise phase is if the move is long enough to let you reach cruise speed. First lets look at the case where you are in exact stop mode. Every move will have to accel and decel. If a move is 0.0006 long, the decel part only gets 0.0003 inches. The distance covered during the accel or decel phase depends on the target speed and the acceleration. The math looks like this: Speed at start of ramp: V0 Speed at end of ramp: V1 Average speed during ramp: Vavg = (V0+V1)/2 Time to reach final speed: T = abs(V1-V0) / A (A is accel in in/sec^2) Distance traveled during ramp: D = Vavg * T Substitute for TD = Vavg * abs(V1-V0) / A Substitute for Vavg D = (V0+V1)/2 * abs(V1-V0)/A SimplifyD = (V0+V1)*abs(V1-V0)/(2*A) Solve for A A = (V0+V1)*abs(V1-V0)/(2*D) We are interested in the case where you are going from some speed V0 to a complete stop. So V1 is 0, and the you can simplify some more: Decel rate for full stopA = (V0*V0)/(2*D) If you are making moves that are only 0.0006 long, you have 0.0003 to accelerate and 0.0003 to decelerate. So, V0 = 1.0 ips and D = 0.0003. If we plug those into the last equation we get A = 1666.7 inches per second squared. That is a LOT of acceleration - over 4G. Most machines have accel limits well under 1G. That means most machines will not be able to reach the requested 60 ipm during a 0.0006 long move. So, exactly how fast _can_ the machine go during a 0.0006 move? That depends on the acceleration that the machine can deliver. Let's say the machine can do 50 ips^2. (That is still pretty good - it means you can go from stopped to a 120 ipm rapid in 1/25th of a second.) The best we can do is accelerate full blast for the first half of the move, then decel at the limit for the second half. To calculate the maximum speed
[Emc-users] touchscreen cycle start
Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 5 axis cinci
Stuart, Nice job on the Cinci. Since the head is moving in and out, I assume it is a Hydrotel? I have a 20v120 (where the table moves in Y instead of the head) that I retrofitted from the Big Blue control 3 years ago. It runs at least 12 hours a day 6 to 7 days a week in my shop. They are very good and reliable machines. A little slow, but the power is incredible. There is nothing like 650+ ft/lbs of spindle torque on a mill. I don't know how much axis thrust they have, but an operator snapped off a 2 inch diameter cutter in mine like it was a pencil. Don't let anyone knock your tool changer. I have worked with these machines for around 12 years. The ones with automatic tool changers are slow and puke hydraulic fluid, so the operators usually change them by hand. Now let's see some chips flying. Don't forget the raingear, these things are messy. Drip pans and vinyl welding shields around them are a life saver. Glenn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Stevenson Sent: Friday, April 18, 2008 9:59 AM To: EMC2-Users-List Subject: [Emc-users] 5 axis cinci Gentlemen, Here is a video of my cinci. Notice the dual arm tool changer. It is very generic and can do many things. :) :) that's me. http://www.youtube.com/watch?v=mxxdq6y8z8M thanks Stuart - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Very low PRM system.
Hi I have 3 questions. First if to make motor work on very low feed 0.001 per minute need only high resolution encoder than may be needed belt reduction to the encoder shaft only, to get more pulses and not to whole motor shaft. Is this correct? Second, what is reasonable low feed with direct drive to motors that have 8192x4 puls per revolution? Third, how much those encoder, with 2 250 000 lines, may cost ? Thanks Aram [EMAIL PROTECTED] wrote: Hi I want to build system to tool grinder and that means that my system should behave stable on very low RPM. Minimum PRM 0.0001 per minute. I want to use direct drive with ball screw 5 rev per inch or 1 rev for 5 mm in case of metric system. My motors have 8192 pulse per .. it takes 4x8192 per revolution. It is AG industrial from servo dynamics. Any fundamentals ideas? Should I use higher resolution encoder? If you really need .0001 Rev/Minute, that is 32768 counts * .0001 = 3.3 encoder counts/MINUTE, or 18 seconds between each encoder count. You can't get smooth motion like that. Of course, .0001 RPM x 5 TPI on the screw is a movement rate of .2 IPM. Do you truly need it this slow? To get smooth motion, you really want an encoder count rate of maybe 15 counts/second, or even better, 60. So, for 15 cts/sec at .0001 RPM, you need 15 * 60 * 1 = 9 000 000 counts/rev, or 2 250 000 pulses/rev. This will be a pretty expensive encoder. (Multiply by 4 for 60 counts/sec.) Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] touchscreen cycle start
On Tue, Apr 22, 2008 at 01:02:20PM -0500, Stuart Stevenson wrote: Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart Sure, but down this path lies madness. What about spindle on? Resume? Z negative jog? I think if you can't trust your touchscreen to not give you unwanted button presses (whether or not a mischievous insect can be blamed) you should remove it. Chris - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] touchscreen cycle start
Stuart You might consider turning off the hydraulics and servos when not in use. That is the trick I do, mainly so I don't have to listen to it howl. I also have a touchscreen on my Cinci. (It is not running EMC, but similar problems can arise.) Think about any button that might interfere with operation. I have had a drop of coolant land on the spindle off button in the middle of a cut. Luckily for me, the motor and transmission are so heavy in these beasts that I got it back on before it broke the cutter. I always make sure the pendant is turned away from the work. At first I considered turning off my touchscreen. But, in 3 years of running, I have only had a couple of problems caused by it. And it really makes running the machine easier. There is another solution though. Don't let the flies and moths in the shop, or at least give them proper training ;) Glenn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Stevenson Sent: Tuesday, April 22, 2008 11:02 AM To: EMC2-Users-List Subject: [Emc-users] touchscreen cycle start Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] touchscreen cycle start
-- Message: 7 Date: Tue, 22 Apr 2008 13:13:46 -0500 From: Chris Radek [EMAIL PROTECTED] Subject: Re: [Emc-users] touchscreen cycle start To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, Apr 22, 2008 at 01:02:20PM -0500, Stuart Stevenson wrote: Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart Sure, but down this path lies madness. What about spindle on? Resume? Z negative jog? I think if you can't trust your touchscreen to not give you unwanted button presses (whether or not a mischievous insect can be blamed) you should remove it. Sadly, I agree. At any rate I was not impuning the insect. The motives of the insect would not be questioned? :) Chris -- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100.touchscreen cycle start Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users End of Emc-users Digest, Vol 24, Issue 42 * - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Very low PRM system.
At 01:09 PM 4/22/2008, you wrote: Hi I have 3 questions. First if to make motor work on very low feed 0.001 per minute need only high resolution encoder than may be needed belt reduction to the encoder shaft only, to get more pulses and not to whole motor shaft. Is this correct? Second, what is reasonable low feed with direct drive to motors that have 8192x4 puls per revolution? Third, how much those encoder, with 2 250 000 lines, may cost ? Thanks Aram If you have a good analog velocity mode system you can get smooth motion at slow speeds without a high line count encoder. But then a good analog tach is not cheap if you are buying new but somthing to keep in mind if you find some suplus stuff. __ Andre' B. Clear Lake, Wi. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Very low PRM system.
Hi Aram, I did find a high res encoder at 1250K counts/rev. I'm not really certain that is ppr or in quadrature. Price is in the $1000 range. http://www.opticalencoder.com/pdf/CP-850-950-HHC.pdf Dave On Apr 22, 2008, at 11:09 AM, [EMAIL PROTECTED] wrote: Hi I have 3 questions. First if to make motor work on very low feed – 0.001 per minute need only high resolution encoder than may be needed belt reduction to the encoder shaft only, to get more pulses and not to whole motor shaft. Is this correct? Second, what is reasonable low feed with direct drive to motors that have 8192x4 puls per revolution? Third, how much those encoder, with 2 250 000 lines, may cost ? Thanks Aram [EMAIL PROTECTED] wrote: Hi I want to build system to tool grinder and that means that my system should behave stable on very low RPM. Minimum PRM 0.0001 per minute. I want to use direct drive with ball screw 5 rev per inch or 1 rev for 5 mm in case of metric system. My motors have 8192 pulse per ….. it takes 4x8192 per revolution. It is AG industrial from servo dynamics. Any fundamentals ideas? Should I use higher resolution encoder? If you really need .0001 Rev/Minute, that is 32768 counts * .0001 = 3.3 encoder counts/MINUTE, or 18 seconds between each encoder count. You can't get smooth motion like that. Of course, .0001 RPM x 5 TPI on the screw is a movement rate of .2 IPM. Do you truly need it this slow? To get smooth motion, you really want an encoder count rate of maybe 15 counts/second, or even better, 60. So, for 15 cts/sec at .0001 RPM, you need 15 * 60 * 1 = 9 000 000 counts/rev, or 2 250 000 pulses/rev. This will be a pretty expensive encoder. (Multiply by 4 for 60 counts/sec.) Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http:// java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- --- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http:// java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
I made this program http://pastebin.ca/993663 (same thing I think as Jon made) I ran it on the live cd (hardy is all I have handy at the moment) on a dual core 2.2ghz. (not the greatest latency - around 20us. Anyway.. With the default stepper_inch.ini - acceleration set to 20In/s/s the program takes 1min40sec. (side not - the velocity on the axis screen reads 0) I upped the traj and axis acceleration (x and y) to 100In/s/s and the program took 1min40sec.. :) as much as I could tell with a second hand on the clock. So that calculates out to about 3.77ipm. Now - If I add G64P.0005 - the program and leave the acceleration to 20In/s/s it cruises along at 30ipm.. :) cool. Takes about 13 seconds. sam John Kasunich wrote: Jon Elson wrote: At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2 diameter circle. Each chord is roughly 0.0006 long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. First a quick look at other bottlenecks: There is no way the interpreter is only doing 39 lines per second. I would expect the interpreter to be able to handle tens of thousands of lines per second on a fast PC. I can't think of a meaningful test of interpreter speed at the moment, but for all practical purposes it is fast enough that we don't really care much. The next bottleneck is passing commands to the motion controller (realtime code). EMC's motion controller has basically two parts that both run once per servo cycle. One is the command handler (mostly in command.c) and the other is the control code (control.c and lots of files linked to it). Each time it runs the command handler takes precisely one command from the user space code and either executes it or queues it (depending on the type of command). That means it with the default servo rate of 1KHz you can at best send 1000 commands per second to the motion controller. In practice the limit will be a bit lower, since the user space code sleeps once it sees that the motion controller hasn't accepted a previous command. The controller will accept the command after 1mS, but if the Linux (non-real-time) doesn't wake up the interpreter for 3mS, the max throughput drops to 333 commands per second. Once the command handler gets a motion command it goes into a buffer that holds 200 moves. When you start a program, the interpreter and command handler quickly get 200 moves ahead of the motion (unless you have tiny moves like your test program). The 200 move buffer is what lets us run the interpreter in user space. It's also the reason that the active g-code display doesn't track the program. Neither of those things explains your results. You said the times were the same with feeds of 30 and 60 ipm, but that does NOT mean the timing is not acceleration related. Did you try with two different accel values? Your segments are 0.0006 long, and you are requesting 60 ipm or 1 inch per second. The only way you will reach the requested speed is if your move is a trapezoid - with accel, cruise, and decel phases. The only way you get a cruise phase is if the move is long enough to let you reach cruise speed. First lets look at the case where you are in exact stop mode. Every move will have to accel and decel. If a move is 0.0006 long, the decel part only gets 0.0003 inches. The distance covered during the accel or decel phase depends on the target speed and the acceleration. The math looks like this: Speed at start of ramp: V0 Speed at end of ramp: V1 Average speed during ramp: Vavg = (V0+V1)/2 Time to reach final speed: T = abs(V1-V0) / A (A is accel in in/sec^2) Distance traveled during ramp: D = Vavg * T Substitute for TD = Vavg * abs(V1-V0) / A Substitute for Vavg D = (V0+V1)/2 * abs(V1-V0)/A SimplifyD = (V0+V1)*abs(V1-V0)/(2*A) Solve for A A = (V0+V1)*abs(V1-V0)/(2*D) We are interested in the case where you are going from some speed V0 to a complete stop. So V1 is 0, and the you can simplify some more: Decel rate for full stopA = (V0*V0)/(2*D) If you are making moves that are only 0.0006 long, you have 0.0003 to accelerate and 0.0003 to decelerate.
Re: [Emc-users] VFD Interference
I believe Axis runs the entire program at load time. The interpreter does read and interpret ahead, but I don't know how far or what the limits are. Ken - Original Message - From: Andre' Blanchard [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Tuesday, April 22, 2008 9:29 AM Subject: Re: [Emc-users] VFD Interference At 07:35 AM 4/22/2008, you wrote: To the best of my knowledge, there has been no attempt to optimize the performance of the interpreter. If there is strong feeling that this might be a problem, I suspect that it could be improved significantly. My general experience with products that have never been optimized is that a factor of two is generally easy. A factor of five or ten isn't unusual. Ken I thought EMC interpreted the entire G code program as it was loaded and not in real time when it is running. Which explained why the modal codes display is only correct at the end of the program run. If not why does it take so long to load a program? If only for the graphics can it be disabled and the plot created as the program is run? __ Andre' B. Clear Lake, Wi. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Very low PRM system.
Hello, I use to read the list to get more insight on different aspects related to EMC. Right now we are facing some problems related to PID tuning. And when I have read this If you have a good analog velocity mode system you can get smooth motion at slow speeds without a high line count encoder. I've remembered that apparently (eye is the tester, still no measures) our tuned PID is giving us smooth motion at relative high velocities (order of 100mm/s), but visible oscillations (0.1mm approx ) at low velocities (order of 1mm/s). I wonder if this effect can be related to a low resolution encoder, our encoders are able to give 10mm/4096 pulse spacial resolution. Also, we are controlling using torque (intensity), although the drive can be configured to accept velocity as command. The motor has a resolver internally, but the driver exports only quadrature signals ABZ -A-B-Z, that I plug directly to my motenc-100 card. Can this imply that I can get a more smooth motion using driver configuration to accept velocity?. Any comments are welcome. Thanks Javier - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] touchscreen cycle start
Just an idea but why don't you guys stretch some stretch film over your screens, put about a 1/8 or 1/4 inch gap between the film and the screen. On a a resistive touch screen this should work fine. You could make a bezel to make it look nice. Just a though. Andy Glenn Stewart wrote: Stuart You might consider turning off the hydraulics and servos when not in use. That is the trick I do, mainly so I don't have to listen to it howl. I also have a touchscreen on my Cinci. (It is not running EMC, but similar problems can arise.) Think about any button that might interfere with operation. I have had a drop of coolant land on the spindle off button in the middle of a cut. Luckily for me, the motor and transmission are so heavy in these beasts that I got it back on before it broke the cutter. I always make sure the pendant is turned away from the work. At first I considered turning off my touchscreen. But, in 3 years of running, I have only had a couple of problems caused by it. And it really makes running the machine easier. There is another solution though. Don't let the flies and moths in the shop, or at least give them proper training ;) Glenn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Stevenson Sent: Tuesday, April 22, 2008 11:02 AM To: EMC2-Users-List Subject: [Emc-users] touchscreen cycle start Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] touchscreen cycle start
I would suggest adding a touchscreen disable button that would disable other buttons until enabled. For the paranoid among us that could be a mechanical switch. Ken - Original Message - From: Stuart Stevenson [EMAIL PROTECTED] To: EMC2-Users-List Emc-users@lists.sourceforge.net Sent: Tuesday, April 22, 2008 2:02 PM Subject: [Emc-users] touchscreen cycle start Gentlemen, I would like to disable the cycle start button on the 'axis' display. I have a touch screen. It may start with the slightest touch at an inopportune time. Maybe a moth or other insect could start the machine. Is this something I could easily do? thanks Stuart - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Very low PRM system.
On Tue, 22 Apr 2008, jros wrote: Date: Tue, 22 Apr 2008 22:06:01 +0200 From: jros [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Cc: Casas Olcoz, Alberto [EMAIL PROTECTED], Alberto Casas [EMAIL PROTECTED] Subject: Re: [Emc-users] Very low PRM system. Hello, I use to read the list to get more insight on different aspects related to EMC. Right now we are facing some problems related to PID tuning. And when I have read this If you have a good analog velocity mode system you can get smooth motion at slow speeds without a high line count encoder. I've remembered that apparently (eye is the tester, still no measures) our tuned PID is giving us smooth motion at relative high velocities (order of 100mm/s), but visible oscillations (0.1mm approx ) at low velocities (order of 1mm/s). I wonder if this effect can be related to a low resolution encoder, our encoders are able to give 10mm/4096 pulse spacial resolution. Also, we are controlling using torque (intensity), although the drive can be configured to accept velocity as command. The motor has a resolver internally, but the driver exports only quadrature signals ABZ -A-B-Z, that I plug directly to my motenc-100 card. Can this imply that I can get a more smooth motion using driver configuration to accept velocity?. Any comments are welcome. Thanks Javier .1 mm of error or noise works out to be about 41 encoder counts. This is not well tuned especially at slow speeds. A well tuned system should be capable of at least 10 times better whilst creeping along. Can you record the error with HALscope to get a better look at whats going on? Velocity mode may help, especially if the amplifier has a better velocity input than the encoder (meaning it has a tachometer etc), but then you may need to tune the amplifiers velocity loop as well. Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] block processing speed
John Kasunich wrote: Jon Elson wrote: At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2 diameter circle. Each chord is roughly 0.0006 long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. I don't think so. I am sure I had it in G64, and the 10,000 vectors describe one orbit around a 2 diameter circle, so the individual vectors are very nearly colinear. snip What about when blending is turned on? EMC2 has one-segment lookahead. It looks at the next move, and blends the two together if possible. The blending is fundamentally quite simple (although dealing with all the possible cases is not.) EMC2 calculates the accel, cruise (if any) and decel numbers for each move as if it was in exact stop mode. But then it starts the accel phase of the next move as soon as the decel phase of the current move begins, and adds them together. Move 1 is slowing down, move 2 is speeding up, and if the two are at a mild angle to each other they ramps cancel out leaving a very smooth movement. If the two moves represent a sharp turn, the overlap between their accel and decel periods tends to round off the corner. EMC2 has special code to detect that this would happen, and if the rounding is worse than the specified tolerance EMC2 slows it down some more. Since EMC2 calculates each segment as if it were doing exact stop, blending doesn't increase the maximum speed. It does increase the average speed, because the tool isn't constantly slowing down and speeding up. And it makes the movement _much_ smoother. In the case above, where the accel limit is 50, blending would result in an average speed of 14.7 inches per minute. Jon's program made a 2.00 diameter circle, with a circumference of 6.28, and it took 4 minutes 17 seconds. That works out to an average speed of 1.46 ipm. I worked the equations backwards and got an accel value of almost exactly 1.0 inches per second squared. Jon: Is the accel limit on your test config 1.0 inches per second squared? No, both default and max accel in the TRAJ section is 5.0 user units (Inches) and max_accel in the axis sections is also 5.0 I have posted the program to http://pico-systems.com/codes/contour.ngc just so we can all have a standard to work with. But, I think you have defined the problem quite clearly, and I did not know it worked this way. The blending has a horizon of ONLY one line! Looking at the first 17 blocks : N10 G01 F30 X0. Y1. N40 G01 F30 X0.0006 Y1. N70 G01 F30 X0.0013 Y1. N100 G01 F30 X0.0019 Y1. N130 G01 F30 X0.0025 Y1. N160 G01 F30 X0.0031 Y1. N190 G01 F30 X0.0038 Y1. N220 G01 F30 X0.0044 Y1. N250 G01 F30 X0.0050 Y1. N280 G01 F30 X0.0057 Y1. N310 G01 F30 X0.0063 Y1. N340 G01 F30 X0.0069 Y1. N370 G01 F30 X0.0075 Y1. N400 G01 F30 X0.0082 Y1. N430 G01 F30 X0.0088 Y1. N460 G01 F30 X0.0094 Y1. N490 G01 F30 X0.0101 Y0. we see that the first sixteen vectors are perfectly co-linear, due to roundoff! There is no need to decelerate at all here. And the next 12 are again colinear, and so on for some time. I have no idea how hard it is to do better with this lookahead, I expect it is not easy to handle all possible combinations of moves, with compensations being turned on/off, etc. But, for people doing contouring of surfaces, they often want to skim rapidly across surfaces at 60 IPM with several thousand vectors/inch, therefore, at least 1000 vectors/second is needed. This doesn't require large acceleration, as the vectors comprise a smooth curve. If there is a discontinuity, then the machine has to slow down, of course. Any suggestions are welcome. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] block processing rate
sam sokolik wrote: I made this program http://pastebin.ca/993663 (same thing I think as Jon made) I ran it on the live cd (hardy is all I have handy at the moment) on a dual core 2.2ghz. (not the greatest latency - around 20us. Anyway.. With the default stepper_inch.ini - acceleration set to 20In/s/s the program takes 1min40sec. (side not - the velocity on the axis screen reads 0) I upped the traj and axis acceleration (x and y) to 100In/s/s and the program took 1min40sec.. :) as much as I could tell with a second hand on the clock. So that calculates out to about 3.77ipm. Now - If I add G64P.0005 - the program and leave the acceleration to 20In/s/s it cruises along at 30ipm.. :) cool. Takes about 13 seconds. Yes, that does it! WOW! I left my accel at 5.0 In/sec^2, and got 17 seconds. I can actually hear it accelerating at the beginning of interpolating the circle and slowing down at the end. So, there is a HUGE difference between G64 and G64 P0.0005 ! So, that is 588 blocks a second! Thanks, Sam! Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] block processing speed
Jon Elson wrote: I have no idea how hard it is to do better with this lookahead, It's hard. :-( I expect it is not easy to handle all possible combinations of moves, with compensations being turned on/off, etc. But, for people doing contouring of surfaces, they often want to skim rapidly across surfaces at 60 IPM with several thousand vectors/inch, therefore, at least 1000 vectors/second is needed. This doesn't require large acceleration, as the vectors comprise a smooth curve. If there is a discontinuity, then the machine has to slow down, of course. That's the rub - if there is a discontinuity the machine has to slow down. But it doesn't know there is a discontinuity until it gets there. (Or in EMC's case, until it gets within one segment of there.) Multi-segment lookahead is _very_ non-trivial. We've discussed it at length several times over the years on IRC. There is only so much you can to in the realtime code - it needs to have roughly constant execution time, we can't be doing things that are order O(N) where N is all the lines in the program. You can in theory do all that lookahead in user space. But things like the user changing feedrate override on the fly, or probing moves, or several other issues, can completely mess up a nicely pre-planned path. There have been some intermediate steps - for example jepler wrote some code that detects collinear lines and merges them into a single line. It also detects and merges lines that are not collinear, but are close enough that if you merge them you remain within the tolerance that was specified by G64 Pwhatever. I'm not sure if that feature is in the 2.2 branch or only in CVS (to be released as part of 2.3.0). When you start considering arcs as well as lines it gets much hairier. Regards, John Kasunich - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] block processing speed
John Kasunich wrote: Jon Elson wrote: I have no idea how hard it is to do better with this lookahead, It's hard. :-( That's the rub - if there is a discontinuity the machine has to slow down. But it doesn't know there is a discontinuity until it gets there. (Or in EMC's case, until it gets within one segment of there.) Well, then, what is the difference between G64 and G64 P0.0005 ? In this particular program, it makes a 4 minute difference, or a factor of 15:1 ! it still didn't get up to the programmed feed rate, but it got a lot closer. I think I must have left the file with the 60 IPM feedrate in it, and it did 6.28 inches in 17 seconds, or 22 IPM. I can understand horrible performance in G61 mode, that would be expected. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
