Re: [Emc-users] EMC2_NCFILES_DIR
Maybe I'm not understanding your question but I believe your system is working correctly. If I recall correctly, in Puppy Linux, /mnt/home is a symbolic link to /initrd/mnt/dev_save. Hence as far as EMC2 is concerned, your variables are actually EMC2_CONFIG_PATH=/initrd/mnt/dev_save/ems/emc-config EMC2_NCFILES_DIR=/initrd/mnt/dev_save/ems/ncfiles You don't notice this when EMC2 starts up because it doesn't present you with a menu then. Just my two cents worth. Regards, Kent Hello Kent, Thanks for you mail I sorry for my English, I had not practics long time. The problem is not path /initrd/mnt/dev_save/emc or /mnt/home/emc I set to EMC2_CONFIG_PATH=/mnt/home/emc/emc-config, and it does work. Does not matter if really path is /initrd/mnt/dev_save/emc/emc-config. The problem is in open file function. I set EMC2_NCFILES_DIR=/initrd/mnt/dev_save/emc/ncfiles (or /mnt/home/emc/ncfiles) I start EMC script, select Stepper_mm standart configuration (based on AXIS) and press button Open file button. System opens Open file dialog with default locaton in /initrd/mnt/dev_save/emc/emc-config/stepper. That is not correct because I set EMC2_NCFILES_DIR=/initrd/mnt/dev_save/emc/ncfiles. Here is screenshot http://cnczone.ru/img/folder.png I checked Ubuntu, and in Ubuntu EMC2_NCFILES_DIR does work correct. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2_NCFILES_DIR
The only real use of EMC2_NCFILES_DIR is to give a value to $emc::NCFILES_DIR, used in pickconfig.tcl to set the inifile variable [DISPLAY]PROGRAM_PREFIX when copying configurations. As documented at http://linuxcnc.org/docs/html/config_ini_config.html#sub:[DISPLAY]-section it is the inifile value that is used by the GUIs to select the initial directory of their 'open part program' dialog. Jeff -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2_NCFILES_DIR
Евгений Александрович, Fix your e-mail server or stop requesting courtesy copies in Reply-To. Your mail server rejects mail from me, saying falsely 550 We do not accept mail from dynamic IPs (206.222.212.217). Please contact supp...@corp.mail.ru (in reply to RCPT TO command) Jeff -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2_NCFILES_DIR
Jeff thank you a lot! It does work now. The only real use of EMC2_NCFILES_DIR is to give a value to $emc::NCFILES_DIR, used in pickconfig.tcl to set the inifile variable [DISPLAY]PROGRAM_PREFIX when copying configurations. As documented at http://linuxcnc.org/docs/html/config_ini_config.html#sub:[DISPLAY]-section it is the inifile value that is used by the GUIs to select the initial directory of their 'open part program' dialog. Jeff Maybe I'm not understanding your question but I believe your system is working correctly. If I recall correctly, in Puppy Linux, /mnt/home is a symbolic link to /initrd/mnt/dev_save. Hence as far as EMC2 is concerned, your variables are actually EMC2_CONFIG_PATH=/initrd/mnt/dev_save/ems/emc-config EMC2_NCFILES_DIR=/initrd/mnt/dev_save/ems/ncfiles You don't notice this when EMC2 starts up because it doesn't present you with a menu then. Just my two cents worth. Regards, Kent Hello Kent, Thanks for you mail I sorry for my English, I had not practics long time. The problem is not path /initrd/mnt/dev_save/emc or /mnt/home/emc I set to EMC2_CONFIG_PATH=/mnt/home/emc/emc-config, and it does work. Does not matter if really path is /initrd/mnt/dev_save/emc/emc-config. The problem is in open file function. I set EMC2_NCFILES_DIR=/initrd/mnt/dev_save/emc/ncfiles (or /mnt/home/emc/ncfiles) I start EMC script, select Stepper_mm standart configuration (based on AXIS) and press button Open file button. System opens Open file dialog with default locaton in /initrd/mnt/dev_save/emc/emc-config/stepper. That is not correct because I set EMC2_NCFILES_DIR=/initrd/mnt/dev_save/emc/ncfiles. Here is screenshot http://cnczone.ru/img/folder.png I checked Ubuntu, and in Ubuntu EMC2_NCFILES_DIR does work correct. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Questions about the parallel port
Hello all, I wanted to say thanks again for all your input and help bringing me up to speed! I'm cranking away researching my Anilam 1100 retrofit, and I'm having troubles feeling secure about the parallel port as a robust enough device to control three or four axis of motion at modest 100ipm table speeds. I can see a PCI based I/O card doing it, but I'm feeling iffy about the parallel port. I know that EMC is super competent using either style device for it's main motion control I/O. The two axis Anilam 1100 machine I have now has a program/DRO resolution of 0.0001, and can machine up to 100ipm. I would like to retain these performance parameters after the retrofit at a minimum if possible. I think I read somewhere that EMC can control up to 8 axis (or more) of motion through the parallel port. What I'm concerned with is, how fast can it control motion compared to a PCI based I/O device. I read (I tried to anyway) a white paper on the specifications of the ISA parallel port standard. It really is not that fast of a device compared to the PCI bus standard. Well, it seemed that way to me. I'm looking to make this retrofit as reliable as possible, and get some decent performance out of it to. Is there a point in which the parallel port is not fast enough, or not a wide enough data pipe to do the job? Or is it fast enough for anything an automated machine tool would ever need? Parallel port? PCI I/O card as a port? Red pill? Blue pill? ;-) Sorry if this has been asked before: Are there any main stream commercial machine tool companies out there that use the PC's parallel port device for motion control? Companies like Haas, Mazak, Harding, Bridgeport, Hurco, Monarc, etc? Take care, David -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
David, If you are referring to FPGA type PCI bus boards like the Mesa products, you are not comparing apples to apples when discussing speed. In the case of the parallel port, the base thread which handles the I/O is run on the CPU. In the case of an FPGA board, the base thread is effectively run on the FPGA board. It handles counting of individual pulses from the encoder or generating the pwm or step outputs. The servo thread then just comes around periodically to read the current count, or set a velocity value for the pwms or step generation. For example, the Mesa 7i43 communicates over the parallel port, but as an FPGA device, it can handle much higher speed counters (encoders), pwms and step generators than the parallel port can by itself. HTH, Eric Hello all, I wanted to say thanks again for all your input and help bringing me up to speed! I'm cranking away researching my Anilam 1100 retrofit, and I'm having troubles feeling secure about the parallel port as a robust enough device to control three or four axis of motion at modest 100ipm table speeds. I can see a PCI based I/O card doing it, but I'm feeling iffy about the parallel port. I know that EMC is super competent using either style device for it's main motion control I/O. The two axis Anilam 1100 machine I have now has a program/DRO resolution of 0.0001, and can machine up to 100ipm. I would like to retain these performance parameters after the retrofit at a minimum if possible. I think I read somewhere that EMC can control up to 8 axis (or more) of motion through the parallel port. What I'm concerned with is, how fast can it control motion compared to a PCI based I/O device. I read (I tried to anyway) a white paper on the specifications of the ISA parallel port standard. It really is not that fast of a device compared to the PCI bus standard. Well, it seemed that way to me. I'm looking to make this retrofit as reliable as possible, and get some decent performance out of it to. Is there a point in which the parallel port is not fast enough, or not a wide enough data pipe to do the job? Or is it fast enough for anything an automated machine tool would ever need? Parallel port? PCI I/O card as a port? Red pill? Blue pill? ;-) Sorry if this has been asked before: Are there any main stream commercial machine tool companies out there that use the PC's parallel port device for motion control? Companies like Haas, Mazak, Harding, Bridgeport, Hurco, Monarc, etc? -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
On Thu, 17 Sep 2009, Eric H. Johnson wrote: Date: Thu, 17 Sep 2009 15:43:48 -0400 From: Eric H. Johnson ejohn...@camalytics.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: 'Enhanced Machine Controller (EMC)' emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Questions about the parallel port David, If you are referring to FPGA type PCI bus boards like the Mesa products, you are not comparing apples to apples when discussing speed. In the case of the parallel port, the base thread which handles the I/O is run on the CPU. In the case of an FPGA board, the base thread is effectively run on the FPGA board. It handles counting of individual pulses from the encoder or generating the pwm or step outputs. The servo thread then just comes around periodically to read the current count, or set a velocity value for the pwms or step generation. For example, the Mesa 7i43 communicates over the parallel port, but as an FPGA device, it can handle much higher speed counters (encoders), pwms and step generators than the parallel port can by itself. HTH, Eric This is also true of the Pico systems parallel port interfaced products. With smart I/O, the parallel port update rate (from 1 KHz to perhaps 4 KHz) is fine for servo or step generation when all the high speed logic is done locally in the external FPGA or processor. Where the parallel port device becomes a limiting factor, even with a smart external device, is when very high sample rates are required (say 5 KHz and ), or lots of axis or lots of fast realtime I/O is required. Then a PCI or some other faster interface is needed. Unless you have a lot of I/O or linear motors, the PCI interfaced cards are not a requirment. Peter Wallace (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
Peter C. Wallace wrote: On Thu, 17 Sep 2009, Eric H. Johnson wrote: Date: Thu, 17 Sep 2009 15:43:48 -0400 From: Eric H. Johnson ejohn...@camalytics.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: 'Enhanced Machine Controller (EMC)' emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Questions about the parallel port David, If you are referring to FPGA type PCI bus boards like the Mesa products, you are not comparing apples to apples when discussing speed. In the case of the parallel port, the base thread which handles the I/O is run on the CPU. In the case of an FPGA board, the base thread is effectively run on the FPGA board. It handles counting of individual pulses from the encoder or generating the pwm or step outputs. The servo thread then just comes around periodically to read the current count, or set a velocity value for the pwms or step generation. For example, the Mesa 7i43 communicates over the parallel port, but as an FPGA device, it can handle much higher speed counters (encoders), pwms and step generators than the parallel port can by itself. HTH, Eric This is also true of the Pico systems parallel port interfaced products. With smart I/O, the parallel port update rate (from 1 KHz to perhaps 4 KHz) is fine for servo or step generation when all the high speed logic is done locally in the external FPGA or processor. Where the parallel port device becomes a limiting factor, even with a smart external device, is when very high sample rates are required (say 5 KHz and ), or lots of axis or lots of fast realtime I/O is required. Then a PCI or some other faster interface is needed. Unless you have a lot of I/O or linear motors, the PCI interfaced cards are not a requirment. Peter Wallace Well, it just goes to show how naive I am about all of this stuff. I only barely understand what the two of you just said. I think what you are suggesting is that some of the work needed to control an axis is somehow off-loaded to the smarter FPGA device, be it a faster parallel port, or PCI bus I/O device. This of course, effectively freeing up the CPU on the computer. I'm just guessing here. I was under the impression that the PC running EMC did most of the heavy lifting. Are there any good books out there that a reasonably intelligent lay person could read to come up to speed on this stuff? I just feel that if I don't understand even the basics, I'm not going to be able to make informed decisions. This is how I imagine things in my simple world, and why I thought the parallel port was not up to the task. I'll just use encoder feed back for my example: My motors have a 1,000 count encoder on the back. The program from the Anilam 1100 has a 0.0001 resolution for position. This is also the resolution for the on screen DRO. The timing belt gearing is 1.5:1. Combine that with a 0.200 lead ball screw, and you get 7,500 pulses output, on say the rising edge of channel A of the encoder, per inch of table travel. To get the 0.0001 resolution for position, I imagine (I'm just guessing here) that they are triggering, and combining, from both the rising and falling edges of channels A and B. That would give you 30,000 pulses per 1 of table travel. Divide this output by three, and you have your 0.0001 resolution, or 10,000 pulses per inch. This means that at a modest 100ipm of table travel speed, the position pulse stream is 16,666.67 pulses per second. I just had trouble imagining a parallel port dealing with something like this. Even if the table encoder position output stream was fed to a counter, how can the system know where it's at without looking (through the parallel port) at the output of the counter value at least 16K+ times a second? Now, I know that I don't need those kinds of speed for actual machining. It's just nice to be able to get the table to move that quick on a rapid move without loosing it's position. I might have to just call up Pico, or Mesa and let them decide for me what I need. David -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
2009/9/17 David Braley davbra...@comcast.net: This means that at a modest 100ipm of table travel speed, the position pulse stream is 16,666.67 pulses per second. I just had trouble imagining a parallel port dealing with something like this. If the system servo thread is running at 15,000 nS (perfectly normal) then the parallel port can run at 66,000 pulses per second, so you will actually have about enough overhead with your 16k. -- atp -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
On Thu, Sep 17, 2009 at 03:42:41PM -0600, David Braley wrote: This means that at a modest 100ipm of table travel speed, the position pulse stream is 16,666.67 pulses per second. I just had trouble imagining a parallel port dealing with something like this. Even if the table encoder position output stream was fed to a counter, how can the system know where it's at without looking (through the parallel port) at the output of the counter value at least 16K+ times a second? The smart hardware, whether it be on the other side of an EPP (parallel port) bus or a PCI bus does only the things that need to be done fast. Generally for servos this is counting the quadrature from the encoders, and generating PWM to make an analog output for servo amps. Every millisecond, EMC reads the encoder count so far (NOT the raw encoder signals which care changing way too fast) and commands velocities for the axes that are valid for the next millisecond. Your calculations are certainly valid if you want to read the raw encoder signals with the parallel port directly. You can quickly see why you have a nasty resolution - top speed tradeoff when you do that. The smart hardware eliminates this tradeoff. This page gives a general idea of the hardware that works with EMC2: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2HardwareDesign Now, I know that I don't need those kinds of speed for actual machining. It's just nice to be able to get the table to move that quick on a rapid move without loosing it's position. You bet. My HNC lathe has an encoder resolution of 1/204800 inch (about 0.1 micron) and rapids at 250 inch (about 6m)/minute. No tradeoffs here! -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
On Thu, 17 Sep 2009, David Braley wrote: Date: Thu, 17 Sep 2009 15:42:41 -0600 From: David Braley davbra...@comcast.net Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Questions about the parallel port Peter C. Wallace wrote: On Thu, 17 Sep 2009, Eric H. Johnson wrote: Date: Thu, 17 Sep 2009 15:43:48 -0400 From: Eric H. Johnson ejohn...@camalytics.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: 'Enhanced Machine Controller (EMC)' emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Questions about the parallel port David, If you are referring to FPGA type PCI bus boards like the Mesa products, you are not comparing apples to apples when discussing speed. In the case of the parallel port, the base thread which handles the I/O is run on the CPU. In the case of an FPGA board, the base thread is effectively run on the FPGA board. It handles counting of individual pulses from the encoder or generating the pwm or step outputs. The servo thread then just comes around periodically to read the current count, or set a velocity value for the pwms or step generation. For example, the Mesa 7i43 communicates over the parallel port, but as an FPGA device, it can handle much higher speed counters (encoders), pwms and step generators than the parallel port can by itself. HTH, Eric This is also true of the Pico systems parallel port interfaced products. With smart I/O, the parallel port update rate (from 1 KHz to perhaps 4 KHz) is fine for servo or step generation when all the high speed logic is done locally in the external FPGA or processor. Where the parallel port device becomes a limiting factor, even with a smart external device, is when very high sample rates are required (say 5 KHz and ), or lots of axis or lots of fast realtime I/O is required. Then a PCI or some other faster interface is needed. Unless you have a lot of I/O or linear motors, the PCI interfaced cards are not a requirment. Peter Wallace Well, it just goes to show how naive I am about all of this stuff. I only barely understand what the two of you just said. I think what you are suggesting is that some of the work needed to control an axis is somehow off-loaded to the smarter FPGA device, be it a faster parallel port, or PCI bus I/O device. This of course, effectively freeing up the CPU on the computer. I'm just guessing here. Yep thats it. I was under the impression that the PC running EMC did most of the heavy lifting. Are there any good books out there that a reasonably intelligent lay person could read to come up to speed on this stuff? I just feel that if I don't understand even the basics, I'm not going to be able to make informed decisions. EMC can do everything in software with simple I/O like a parallel port, it is just limited in speed. With just a parallel port, speed depends on finding a CPU with good latency. Smart hardware relaxes the requirement for really good CPU latency, and allows count rates, step rates, and PWM rates/resolutions that are not possible with EMC and a bare parallel port. For a step motor driven mill, a parallel port (on a good PC with low latency) may well be good enough. This is how I imagine things in my simple world, and why I thought the parallel port was not up to the task. I'll just use encoder feed back for my example: Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
For a quick (hobby) comparison - I have a 2'X4' homemade router table. Using a low cost controller card (HobbyCNC) through the parallel port, I can drive three axis powered by 200oz-in stepper motors. This setup can drive the steppers to over 400ipm, but my mechanical limitations (binding, poor building, crud,etc) keeps me at ~90-100 ipm on the X and Y. Add microstepping (1/4) and I run at 60 IPM. I use 8 or 9 wires from the cable. With this setup I do NOT control Spindle (on/off switch) Spindle speed Homing Limits Position feedback. If I added all those, I would quickly eat up the available cabling. For me, the set up is fine - its a hobby machine (my wife wonders if I will make anything with it). It sounds like the Anilam control had a few bells and whistles that are easily handled by EMC. But from all I read on the numerous emails and forums, for the little extra cost up front, it sounds like you would be better off going with an FPGA card and letting your machine run closer to its mechanical limits and not those of the computer (anilam or EMC thru the parallel port). my 2 cents. Brian -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
On Thursday 17 September 2009, David Braley wrote: Hello all, I wanted to say thanks again for all your input and help bringing me up to speed! I'm cranking away researching my Anilam 1100 retrofit, and I'm having troubles feeling secure about the parallel port as a robust enough device to control three or four axis of motion at modest 100ipm table speeds. I can see a PCI based I/O card doing it, but I'm feeling iffy about the parallel port. I know that EMC is super competent using either style device for it's main motion control I/O. I am personally doing 4 axis's, spindle speed and direction, and a contact probe, through the parport of a Mach Speed mobo, with a amd XP-1400 athlon actually running at 1600mhz on it, using an 8 microstepping xylotex motor driver, at speeds up to about 40ipm for the z, and the low 30's for x/y. That is all my motors can do w/o stalling at the voltages available (28.5 volts) with xylotex drivers. With something like or better than the 80 volt Gecko drivers, I may be able to hit 60 ipm, but more would require the 20 tpi screws in my xy table to be replaced with something more realistic, which would require a whole new spindle in order to have power enough to cut at those speeds. The micromills spindle setup is at best, rather puny. FWIW, I do have a 2nd, 2 port parport card in the machine, intending to convert a lathe at some point, if and when I get one big enough to convert, the 7x12 is too close to a toy. The two axis Anilam 1100 machine I have now has a program/DRO resolution of 0.0001, and can machine up to 100ipm. I would like to retain these performance parameters after the retrofit at a minimum if possible. I think I read somewhere that EMC can control up to 8 axis (or more) of motion through the parallel port. What I'm concerned with is, how fast can it control motion compared to a PCI based I/O device. I read (I tried to anyway) a white paper on the specifications of the ISA parallel port standard. It really is not that fast of a device compared to the PCI bus standard. Well, it seemed that way to me. I'm looking to make this retrofit as reliable as possible, and get some decent performance out of it to. Is there a point in which the parallel port is not fast enough, or not a wide enough data pipe to do the job? Or is it fast enough for anything an automated machine tool would ever need? Parallel port? PCI I/O card as a port? Red pill? Blue pill? ;-) Sorry if this has been asked before: Generally, it has been noted here on this list that the ISA ports are slow, but it seems the superio based ports such as are on the newer motherboards could be faster. But even with steppers like I'm using, the speed limit would appear to be much more a function of the voltage available to drive the motors long before the port speed would seem to be a problem. In any event, a cheap 2 port pci card can be installed if one would like to test the theory. I believe I have 20 USD in mine. Are there any main stream commercial machine tool companies out there that use the PC's parallel port device for motion control? Companies like Haas, Mazak, Harding, Bridgeport, Hurco, Monarc, etc? Take care, David -- Cheers David, 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) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Old programmers never die, they just hit account block limit. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
David Braley wrote: Well, it just goes to show how naive I am about all of this stuff. I only barely understand what the two of you just said. I think what you are suggesting is that some of the work needed to control an axis is somehow off-loaded to the smarter FPGA device, be it a faster parallel port, or PCI bus I/O device. This of course, effectively freeing up the CPU on the computer. I'm just guessing here. Yes, exactly. An FPGA can be set up to count out time in, say, 25 ns units, and put out step pulses every so many ticks of that clock. That can give about 1000 times finer grain timing. I was under the impression that the PC running EMC did most of the heavy lifting. It CAN, but there are major benefits to letting more suitable hardware take over the demanding timing tasks. This means that at a modest 100ipm of table travel speed, the position pulse stream is 16,666.67 pulses per second. I just had trouble imagining a parallel port dealing with something like this. Even if the table encoder position output stream was fed to a counter, how can the system know where it's at without looking (through the parallel port) at the output of the counter value at least 16K+ times a second? Well, if the base thread is running at 32 KHz, you can put out step pulses at 16 KHz. But, at 99 IPM, step pulses would be jumping between 16 KHz (every other tick of BASE_THREAD) and the next lower step (every third tick) or 10.6 KHz. That is an enormous jump in step rate, leading to loss of stepper sync, of just ragged operation. That's the advantage of making hardware do easily what software struggles to do badly. Jon -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Questions about the parallel port
Thanks for the great replies everyone! It sounds to me like it doesn't really matter that much what type of port I use. As long as there is some extra intelligence built into the hardware to help do some of the lifting. It did occur to me, that when I get the machine working with EMC2, I could probably sell on ebay the parts off the old Anilam system I wont be using anymore, for more than I pay to update the machine to EMC2! HA! The thought is pretty funny when you think about it. It's too bad this place isn't a real forum. It would be really cool and helpful to others (like me for instance) if I could do a complete build thread from start to finish of retrofitting the Anilam 1100 Sharp over to an EMC2 controlled machine. Lots of photos and diagrams. The kind of thread with step by step coolness. I will document everything I learn and do anyway. If this place ever does evolve into an online forum, I could put it all up then I guess. I'm sure there are a bunch of these old Anilam controlled machines lying dead, or slowly dying in the corners of shops out there. It would be really neat to bring this iron back to life. And like I said earlier, my experience with this project will give me the push to retrofit the other, even older machine I have, a tape controlled, stepper driven Bridgeport Series II, to a servo machine. Now that project will be from scratch. The entire older control system will be scrapped. (To the voice of Homer Simpson) H... Servos.. Take care, David -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
