# EMC Info (Long)

P

#### PhilC

Hello All, The following is a copy of an email describing the development of NIST's EMC (Enhanced Machine Controller). It is a long message, but may be interesting to some people on this list. Some of the issues the author discusses at the end of his email are, I think, pertinent to the lPLC. Regards, Phil Covington vHMI ---------------------------------------------------------------------------- ---------------- From: Matt Shaver <[email protected]> Date: Mon May 17, 1999 3:36pm Subject: Re: NIST EMC Software & Intro Hi, I've been using the EMC software for a few years now. I have a little machine shop that has been a part time venture since 1987 and my full time occupation since the summer of 1995. In the spring of 1996, shortly after I bought out my business partner and was in considerable debt, the control on my Bridgeport V2E3 went bad. I didn't want to spend $20K on more proprietary technology that I'd have to scrap at some point down the road when vendor support dried up. I looked at a number of replacement servo based controls such as Proto-Trak, Centroid, Anilam, Bauch & Lomb's MillPower, Milltronics, Lighthouse Software, and probably some more I have forgotten. I even drove up to Centroid's factory in State College, PA to see their wares first hand. I have to say that if I were going to buy an "out of the box" control it would be a Centroid as I believe they offer the best value. Still, even using the old motors, I was looking at$12K for the Centroid and it was still proprietary (although I have to admit they were very nice folks). Anyway, in June of 1996, I was trying to get together a proposal to develop a 3d scanner for a company that made orthotics (corrective shoe inserts). The purpose was to digitize the shape of the bottom of the patient's feet, rather than using impressions in plaster casts. I was researching it on the Internet and found that NIST had done a project on this very subject. Well, to make a long story short the scanner project never panned out for me (they went with another consultant who was going to do it by gray scale interpretation of the Z axis from 2D black and white scans). However, I stumbled across the EMC project while browsing the NIST web site. I called NIST and inquired about getting a copy of the software. I think they were a little skeptical of me at first since their other collaborators on the EMC project were Boeing and General Motors. I persevered and finally got in touch with Fred Proctor and Will Shackleford who did whatever was required to get me signed up as a bonafide researcher. I gutted the Bridgeport's electronics cabinets leaving only the power switch, a few transformers, the lube pump, pneumatic controls and the e-stop circuitry. I installed new servo amps and an Opto22 rack to drive the spindle relays, coolant pumps, etc. In addition, I added a shelf inside one of the cabinets... (At this point in my typing I thought "They're never going to really understand without pictures". So I stopped and made this web page): http://users.erols.com/mshaver/v2e3.htm As I was saying, I made the changes to my mill that you see on the above web page. Meanwhile Fred and Will at NIST were changing the software around to suit my machine. The previous implementation of the EMC at General Motors (a K & T mill with tool changer at the Pontiac Powertrain Division) used two PCs networked together with Ethernet. One PC ran a real time OS (LynxOS) which communicated with the motion control card and digital I/O hardware while the other PC ran a Visual Basic GUI under Windows 3.11. I had expressed my desire for a system that would run on a single PC under Windows 95. Fred said he could do it using Windows NT so that is what he did. Another change was to move the digital I/O from a dedicated I/O card to bits on a parallel printer port. Both these changes were done with cost reduction in mind (my mind anyway!). In August of 1996, I had finished the hardware changes and Fred and Will had finished their software work. We assembled all the pieces, and after a few days of fiddling and fussing, it worked! This is of course a huge understatement, or non-statement, of what was involved but it's the best I can do since lots happened, none of which I remember accurately. During the period from September 1996 through November 1996, we did lots of testing and software revisions, which I downloaded from NIST's ftp server and installed, on the mill to fix this and that minor problem. On November 26, 1996, Fred and Will brought some of the folks from NIST up to my house to have a look at our handiwork. I ran a demo program for everyone that engraved the NIST logo on a piece of 1/16" aluminum sheet. A picture taken that day can be seen at: http://www.isd.cme.nist.gov/projects/emc/emcsoft.html The guy in the plaid shirt staring intently at the vise is me. I think you can just make out the Visual Basic GUI on the monitor. Around the beginning of 1997, Fred and I had a number of discussions regarding where to go from there. One of the problems I had with the setup we had at this point was that it used a PMAC motion control card from Delta-Tau. This is a great board, literally a cnc on a card. It has a dedicated DSP per axis and high-speed dual ported RAM for communication with the host computer. It is totally configurable, both with jumpers and in software. It comes with a comprehensive manual as thick as a phone book and excellent technical support is available. It costs $4000. In the time between the failure of the original control and finishing the installation of the PMAC/NT based control, I had changed by business methods around some. I had to keep on producing parts so I subcontracted all my cnc milling jobs out to a friend of mine. This was actually the best thing I ever did business wise, but that is a subject for another forum. The result was that I could use my mill as a guinea pig for EMC experiments without any pressure to produce work with it. Although once it was running with the PMAC under NT I did do several paying jobs with it and it worked better than it ever did with the original control. At this point, my own thinking had progressed beyond fixing the Bridgeport mill to building more machines. With new imported cnc knee mills in the MSC catalog selling for$20K or so the only way for domestic builders to compete is to get the cost of a complete retrofitted machine down to $15K or less. Any higher than this and potential clients are going to say "I'll just buy new and get a warranty". Let's look at the costs:$6000 Good, tight, worthwhile Bridgeport $1000 Ballscrews (Ground), Paint, Miscellaneous Mechanical Parts$500 X & Y Brackets $1500 Z Bracket & Quill Drive$3000 3 new size 42 servo motors with encoders $2000 Servo Amps (The set shown on the web page above cost$1900) --------- $14000 TOTAL This doesn't include a PC, motion control card, software, or any of the "glue" like the Opto22 rack, relays, enclosures, etc... In addition, if you sell your machine through a salesman (like I have twice) you're going to have to pay a commission, in my case 10%. You might say, "Those costs look a little high to me, I could get the machine cheaper, use rolled screws, surplus motors, make the brackets, yadda, yadda, yadda." but if the motion control card costs$4K you're finished. To be completely fair to Delta-Tau, their card is priced right for what you get and if you were retrofitting a large machine tool that cost six figures the PMAC price would be insignificant in the grand scheme of things. Other potential applications for the PMAC are projects that require fast time-to-market in which case you can purchase a complete, tested, reliable solution that works right away. Also, the PMAC is capable of controlling motion at much higher velocities and to greater resolution than is required in machine tools. Applications such as controlling linear motion stages that are part of the photolithography processes used in the manufacture of ICs for example. In cases like those the host computer may not have enough computing power that it can devote to motion control while still running other tasks like a user interface, file system, etc. I believe that some versions of the PMAC can run stand alone with only a power supply and a terminal. In summary the PMAC is like the Cadillac of motion control cards, but if you're like me you only have enough money to buy a Chevrolet (actually, if you're like me, you don't even have that much money). Really, the best way to go is to buy old nc or cnc machines with dead controls and retrofit those because you can often reuse the motors, amps, etc. In addition, non-running cnc machines are generally regarded as nearly worthless. They typically sell for less than an equivalent sized manual machine. Still, you need to be able to sell cheap to compete against the new import machines and yet make a profit. Just as an aside, you can buy a new import linear way 40 taper vertical machining center for around $30K! If you bargain hard, you may get some tooling (cheap) thrown in and a few months of interest only financing. I think I got off topic here somehow... Like I was saying, after the original NT/PMAC based version of the EMC was stable I expressed a desire for the cheapest possible implementation. I had started reading rec.crafts.metalworking around this time and I thought advanced hobbyists would be interested in building servo-powered systems if there was software available to control them. Anyway, around March of 1997 Fred said he was interested in porting the EMC to Linux and using a simpler (cheaper) interface card. His reasons were that the PMAC card did a lot of the motion control work internally. If the EMC was going to fulfill its original purpose as a platform for developing new, advanced machine tool control methods then all the motion control algorithms should be implemented in software to allow experimenters to tinker with them easily. This meant that the only hardware functions that would be required are DACs to output the control voltage to the servo amps and quadrature encoder readers to feedback position information to the control. Digital I/O was already implemented on a printer port, although the home and limit switches as well as the servo amp enable signals are tied into the motion control card. That would suit applications where the I/O could be mapped into twelve output bits and five input bits per port with a max of three ports on a PC. Fred had already identified the components used in the current implementation; Linux, Real Time Extensions for Linux from New Mexico Tech, and an interface board from Servo To Go. This board is available in several different versions but the full blown 8 axis version costs$888 (< 25% of the cost of a PMAC). More information on RTLinux can be found at: http://www.rtlinux.org Basically RTLinux adds hard real-time deterministic control capabilities to the standard Linux kernal with time resolution down to 100uS. Standard Windows NT is capable of about 10mS resolution, but I/O requests from your control program could be deferred by the OS for several seconds. Additional software products from Venturcom and Radisys that work with NT can reduce the resolution and fix the real-time task priority problem, but are not free (neither is Windows NT or VisualStudio for that matter). The hardware changes to the mill required to use the Servo To Go card instead of the PMAC were minimal. I continued to use the PMAC throughout the summer of 1997 during which time I made parts for an architectural model and a few other things. By October of 1997, the software had been ported to Linux, which was a major undertaking for Fred and Will. It involved not only the port itself but also writing the motion control functions that had been previously handled by the PMAC. There was also the device driver or "wrapper" for the Servo To Go card and numerous other smaller issues to resolve. On October 30th we started installing the Linux based system and there followed a several month long period of testing and software (and a couple of hardware!) revisions. One interesting feature of the Linux implementation was the user interface that was written in Java. Theoretically you could put the GUI applet on a web page and control the machine from anywhere. Unfortunately, in practice, the Java GUI turned out to be a problem because after running the EMC for a period of time (say 10 minutes to an hour) X Windows would freeze and the PC would have to be rebooted. In November 1997 I exchanged e-mail with Jon Elson regarding NFPA and EIA standards applicable to machine tools and I told Jon about the EMC project. He started using the EMC software and has done a lot of troubleshooting and testing. Since he started at the beginning of the Linux code conversion, he has seen the majority of the Linux related development. He also probably has more "time behind the wheel" of anyone operating an EMC controlled machine. At the end of April 1998, I had an offer to buy the Bridgeport mill from a company in York, PA. Their requirements were simple in that they wanted to automate the drilling of a long series of holes in small copper tubes. I wasn't out soliciting offers, but I had shown the machine to a machinery salesman friend of mine. He called a few days later and asked, "You want to sell that mill of yours?" I have to say that at this point the technology was not "ready for prime time". I was however, in nearly desperate need of money and with an offer on the table, I decided to sell the machine with the confidence that I could resolve any outstanding issues that came up. And come up they did, rather like dandelions in the spring. It took about a month and several trips up to York by Fred and I to resolve the outstanding issues. The java interface was replaced with a console program called keystick that Fred wrote using the ncurses terminal control function library. Considerable time was also spent in tracking down and finally defeating the mysterious and intermittent "not a number" problem which caused axis runaways to occur. We still go up there from time to time to install the latest version of code, and to get user feedback. In retrospect, I probably should have waited until the software was more stable before I sold the machine. However, the pressure to fix the problems did speed the development process! Before I sold the mill, I wasn't using it enough to shake out all the bugs. The truth is, software projects need green testers (translation: guinea pigs) because people close to the development tend to overlook problems because they are too close to the process. In this case, the customer got the capabilities they needed for about half of the monetary cost of their nearest alternative solution. They also had to suffer through some troubles they might not have otherwise experienced. Another aspect of this sale was that the client didn't have any journeyman machinists among their staff. I did provide a fair amount of training in general machining subjects such as fixturing, setup techniques, etc. I doubt other machine tool vendors would have done this sort of thing as they rely on the client already being familiar with machine work. I also wrote enough cnc programs to get them started into production and spent some time teaching them a little programming. Today, they are satisfied with their machine and I'll continue to support them into the foreseeable future. They have hired a machinist to run the machine and have expanded its use to other (milling) operations. I believe there was some sort of short write-up in the December 1998 issue of Design News about their getting this milling machine. During the summer of 1998, I retrofitted an old Wells-Index vertical knee mill for a shop in Millersville, MD. The owner of the shop had bought the machine from a local dealer and had let it sit unused for nearly a year while finishing an addition to their building. When they finally got around to testing out the machine the control died after one day and they never made a single chip! About another year had passed before I saw the machine and got the retrofit job. I was fortuate that I was able to reuse the servomotors, encoders, amps, and a great deal of the relays and associated electrical gear that came with the machine. The job consisted mainly of removing the old paper tape based CPM computer (!) and putting in a PC with the Servo To Go card in it and an Opto22 board to drive the existing relays from the PC's parallel port. The software used was the same as for the Bridgeport. Since this was a job shop, this machine would be used for a variety of applications. Several bugs were discovered while running jobs on this machine. During the process of this implementation Fred came up with a native X Windows user interface called xemc. The main reasons for this were that the operators had difficulty reading the screen using keystick since that was limited to one (small) font. Also, the operation of the control had to be simplified as much as possible since the operators had little computer experience and were not interested in doing a lot of typing. These requirements were satisfied by both the xemc user interface and by the adoption of the K Desktop Environment for X Windows that provides nearly Windows 95 like ease of operation. This conversion took months (into 1999) to bring to completion (not full time of course) and was fraught with many mechanical, electrical, and software problems too numerous to mention and too painful for me to recall. The great bulk of the work on this job was operator training as they felt that there should be a cookbook style set of instructions which would cover any set of circumstances. System reliability got a huge boost during this period since any anomaly in operation was immediately detected by the operators and converted into a show-stopping event. Nevertheless, the job was done and the EMC software acquired a lot of polish in the process. This brings me up to present here in May 1999. (Finally! You must be saying "I though he'd never finish!") At this time the EMC software has been used in several applications and is free enough of bugs to use on a daily basis for actual work. Recently a module to drive stepper motors has been developed and tested although no one has actually used it to run a mill. Also, the java interface problems have been fixed but it hasn't been used in the field. What the project needs to progress further is more users and developers. I have become a big fan of the open source software movement owing mainly to my exposure to Linux and the Internet. The EMC project will be a complete success (IMHO), when major machine tool builders use the software (as is, right from NIST) to control their machines. This won't happen until it's a proven system. That won't happen until there is a large, satisfied user base, and that won't occur unless the risk (translation: cost) is low enough to compel the adventurers to try it. This is what has happened with Linux. At first, only a few technically oriented people tried it because it was free and interesting. These people tested and improved it and plowed their improvements back into the code base until it was a proven system. Today, you can buy a system with Linux preinstalled from quite a few companies (I think Compaq offers this now). It worked for Linux, it can work for the EMC. For more on the philosophy of these ideas you can visit: http://www.opensource.org Be sure to read the essay _The Cathedral and the Bazaar_ by Eric Raymond at: http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ Here is a list of some things that could be worked on: 1. Documentation - The existing documentation lives not only in the doc directory of the distributed software, but also in other electronic documents, e-mails, scraps of paper, and people's brains. This needs to be collected, collated, edited and expanded into a HOWTO, user guide or some other comprehensive reference. I should probably work on this. I owe some time to this project and I'm think I know with where most of the pieces are. 2. Build a stepper machine to see if it works - I'm sure it will and I've got one started now in the form of an old Bridgeport BOSS4. I have gutted it and hope to power the original stepper motors with the Camtronic's 5-amp stepper driver board. 3. Start using and working on the java interface, or write a new GUI using one of the newer, more attractive toolkits like TCL/TK or GTK. 4. Locate or develop a public domain or GPL'ed CAD/CAM system. I really won't be happy until there is a complete end-to-end open source manufacturing system that can exchange data with other popular systems. 5. Add the ability to program the digital I/O with ladder logic like a PLC. The digital I/O is an area that needs customization for almost every machine, especially if you are planning to automate a tool changer. 6. Develop some "open source" hardware - Lots of broken electronics get scrapped because the cost of the time required to figure out how it works enough to troubleshoot the problem exceeds the replacement cost. Often support from the manufacturer is not available, or is priced to encourage buying replacement hardware. With regard to the Servo To Go board it has proven to be a good solution so far, but it may be possible to cut the cost of the capabilities it provides by "cooperative production". I'm not a socialist or communist, I'm just looking to cut the cost of the hardware needed to build cnc machines by reducing the portion of their price that represents intellectual property royalties. 7. Add additional capabilities like rigid tapping, adaptive feed rate control, lathe support, handwheel support (and other pendant functions), probing (both for setup automation and digitizing), leadscrew error compensation tables, etc. I hope that other programmers can write some of this code, rather than starting from scratch with their own cnc projects. Someone (probably Fred) needs to coordinate the satellite development activities and ensure that changes are integrated into the main code distribution. Thanks for reading this far and I hope this provides some food for thought to folks looking to build cnc machines. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Phil
Thanks for finding and posting this. I am a big emc fan and have been following it for a couple of years. I have a Lagun mill with a Bendix
control that I have been campaigning to convert for a year or so as there is one guy in the world who can fix the thing and the control was at end of life years ago and dies quite frequently. In answer to the obvious question, yes it was part of the inspiration for lplc and more or less proves that Linux automation can be done. My last request for a Servos to Go card was turned down but, I'll bet the next time it dies I will prevail. We have since purchased a Hurco mill and the Lagun doesn't get used much. The Hurco is a nice enough machine but it is proprietary to the extreme. I have started digging through the emc code at least twice but it would take a lot of time (for me) to get up to speed so I shelved it until I get support for a project. I have
mentioned emc here and on the automation list as an example of free software that should not be ignored by OMAC but they will have nothing
to do with a non-Microsoft solution. I started coding for lplc using Fred Proctor's method for sharing memory between user and kernel space.
I haven't had much luck selling it but perhaps now with some perspective if I asked really nice I could get our CS types to look at what's
already working :^) It's completely free, paid for by our uncle sam. I wish it were in C rather than C++ but you can't have everything :^)

Regards

cww

PhilC wrote:
>
> Hello All,
>
> The following is a copy of an email describing the development of NIST's EMC
> (Enhanced Machine Controller). It is a long message, but may be interesting
> to some people on this list. Some of the issues the author discusses at the
> end of his email are, I think, pertinent to the lPLC.
>
> Regards,
>
> Phil Covington
> vHMI
>
Big snip for Ken :^)

P

#### PhilC

Hi Curt,

I have a Bridgeport that is CNC controlled running EMC. It took quite some time to get EMC up and running, but I am glad that I took the time - I think that it is the best solution out of all the other software/OS combinations that I looked at. I got a hold of an old GE NC controller and used the servo amps out of it and the servo motors with the 4 axis Servos-to-Go card.
I also tried the stepper module with EMC, but there are a few problems that have to be worked out yet. I am very happy with EMC.

Matt Shaver, Jon Elson, and Dan Falck on the CAD_CAM list are really helpful in getting EMC up and running. For anyone interested there is a CAD_CAM mailing list over at www.egroups.com (do a search on DRO) and many of the subscribers there use EMC.

EMC info can now be found at: http://www.linuxcnc.org/

There is definitely some great ideas in the EMC source code that could be helpful to the Linux PLC.

Regards,
Phil

T

#### Todd Lyons

Curt Wuollet wrote:

> following it for a couple of years. I have a >Lagun mill with a Bendix control that I have >been campaigning to convert for a year or so as
> there is one guy in the world who can fix the >thing and the control was at end of life years >ago and dies quite frequently. In answer to

Which Bendix control? (searching my memory banks). I used to work on one. I think it was an SS control. 22 slot rack, resolver feedback, up to 4 axes. Came on a Natco Carlton Horizontal Boring Mill (3HB series). Nixie tubes for readouts. Control was circa 1980. Just
curious.

Blue skies... Todd
--
Most traditional Pee-Cee user groups, I've noticed, function mainly as commiseration societies for people who've bought lousy hardware, are struggling and wasting time trying to deal with it, and want to exchange
coping-strategy tips with others in the same boat. -- Rick Moen

C

#### Curt Wuollet

Hi Todd

This one's a Dynapath with crt readout. No idea how old it is just that it's ripe for retirement. I should be able to use the servo gear for emc
though. If it works well I'm sure we would have the mechanicals rebuilt.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mark Bayern

I have a customer who just last week declared his CRT-Dynapath dead.

Now he has asked for an inexpensive CNC control. This machine has only run one part for the last 5 years. We'd normally use a Siemens 810 or 820
for a retrofit, but he wants cheaper and less complex. (IMO the 810/820 stuff is not complex, oh well...)

We are now trying to decide if we should put in a PMAC with an LCD display, or maybe try the EMC. We've been using PMACs since 1991 with great success, but maybe the time is right for the EMC.

Pros for the PMAC:
known hardware
known reliability
no HD
no PC so we dont' get the "I can program a PC, so I'll try to modify it"
stuff.

Cons:
price

Pros for the EMC
price

Cons:
unknown by installers
reliability unknown
contains a wintel PC

Anyone have any insights to help us make this decision?

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Ken E.

The PMAC is the best in motion control. It is absolutely flexible in every operation. We use it at my company and are integrating a PC Controller with their new UMAC product line. IT is pretty slick. Hopefully we'll be running linux PLC on it someday !!! Right now we are stuck with Windoze and steeplechase (steeplechase is nice, windoze
sucks)

~Ken
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

R

#### Ray Henry

Hi Curt

Actually the EMC has come quite a ways since Matt's post. The software resides in a SourceForge respository and several folk are starting to work on it. There was a bit of talk recently about porting the language that the EMC uses to the puffin stuff so that the EMC could use directly use the lplc. Most of the I/O work is being done in Tcl/Tk with axis limits and
estop handled in the realtime component.

The only inexpensive available production encoder reader servo driver is the STG-2, but John Elson and others are nearly finished with an EPP
system that will read four axes and allows for some I/O at the same time.

This is a bit off topic in the details but I'd be happy to send links and such to anyone that cares.

Regards
Ray Henry <[email protected]>
Michigan's U.P.

> From: Curt Wuollet <[email protected]>
> Organization: Wide Open Technologies
> To: [email protected]
>
> Hi Phil
>
> Thanks for finding and posting this. I am a big emc fan and have been
> following it for a couple of years. I have a Lagun mill with a Bendix
> control that I have been campaigning to convert for a year or so as
> there is one guy in the world who can fix the thing and the control
> was at end of life years ago and dies quite frequently. In answer to
> the obvious question, yes it was part of the inspiration for lplc and
> more or less proves that Linux automation can be done. My last request
> for a Servos to Go card was turned down but, I'll bet the next time it
> dies I will prevail.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mark Bayern

I've been a fan of the PMAC since 1991 -- you don't have to convince me. We have installed 8 PMAC controlled material handling robot systems in the last 12 months in plants in PA and MN. (We are located in Texas.)

We are wondering if the time is right to try another solution for this very simple, local job that doesn't have a big budget.

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Mark

Last time I checked, the version that works is running under RTLinux/Linux. Linux can be setup to discourage putzing. Not that many non computer types would have any idea how to screw things up. At least you wouldn't have people loading screen savers and games and such. The bad part about doing any retrofit is that each and every machine is different. If you decide to do it, I'd be real interested :^)

Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

What would be real interesting would be if Steeplechase would port to RTLinux/Linux. I've mentioned it to them, they are real MS droids
they basically told me to fsck off.

Regards
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Ray

Please send me the new info, I think it's appropriate for the list especially if we can get some cross interest. Kinda pushed for time right now but I'd like to look first chance I get.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

G

#### greg goodman

> Cons:
> unknown by installers
> reliability unknown
> contains a wintel PC

in what way does Linux running on an Intel constitute a "wintel PC"?

B

#### Bob Hiller

Attention Phil Covington, I am trying to put a vb front end on a EMC project and have not had much luck. Would it be possible to get a sample of what you are using? Thanks, Bob Hiller