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 BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
