Re: [Emc-users] Off Topic, Broaching
Just found a good video on rotary broaching. http://www.slatertools.com/video.htm __ Andre' B. Clear Lake, Wi. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Off Topic, Broaching
Kirk Wallace wrote: Has CNC changed the way keyways are made? I need to make some keyways for my mill conversion, and I have no tooling so far for doing it. Since I will may be buying tooling, I want to explore the options in order to make the best investment. I actually prefer not having keyways and going with set screws on countersinks. Anyone have thoughts on this? Thanks. You can cut keyways on a lathe using the carriage as the power source, the X axis to step the feed, and a hand-made shaper type tool as the cutter. You want to shave off a pretty thin slice each time as the Z axis usually isn't very strong. I have done this manually on occasion, and even made internal splines this way. If keyways were in it before, they probably had a reason. The only really good alternative is taper-lock hubs. The Bridgeport BOSS machines used them, for instance, on the axis drive pulleys, and they worked pretty well. You could actually make some taper hubs on your lathe, now that it is mostly working. It is essentially a collet. You have two pieces that are bored for the shaft on the ID, and tapered on the OD to match a taper cut on the ID of the sprocket. Then, there is a plate that allows small bolts to pull the pulley tight onto the collet pieces. You also need a scheme to push the pulley off the collet. Look in Grainger or McMaster-Carr's catalog (on line) and see if they have a good picture of these. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Off Topic, Broaching
On Monday 29 October 2007 23:10, Kirk Wallace wrote: Has CNC changed the way keyways are made? I talked with a guy a few weeks ago who has a CNC broaching machine from the description it sounded like more of a vertical shaper/slotter with an X-Y-rotary table and uses a single point tool to peck away at the work Brian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Rafael Skodlar wrote: This brings up another option, build an open source EMC controller PCI[e] card with slow, medium and high speed ports that could be used to control buses. Speeds would need to be determined based on what is required for machine world. If build with an FPGA, it would be very flexible and handle a lot of logic and speed and could be programmed for different needs: use with lathe, 3D routers and torch machines, or even run real time functions. This may be what Paul Corner has been ranting about for some time. Port EMC(your flavor here) to one of the ARM all-in-one CPUs, and keep the GUI on a PC. There are a bunch of details, the biggest being how to access the G-code and configuration files. It would probably require more memory than they currently fit into such chips as the AT91SAM7X series, I think 256 K it the max. There apparently is a substantial speed penalty for external memory. There would need to be some process on the PC supporting file serving to the ARM, but I suppose NFS would work. Without all the Linux OS overhead and virtual PC nightmares of the current PC architecture, the 70+ MIPS of the ARM processors might be sufficient. Once the file serving question is handled, the only serious remaining effort (I think) would be porting rtapi to one of the competing ARM RTOS options. A very interesting idea, but it could be fairly time consuming to deal with all the intricacies of such a big porting effort. It would sure make a NEAT package, and the board could be quite cheap. These ARM microcontrollers are in the $7 - 14 range, they need an additional $12 or so of parts to implement Ethernet, and maybe under $10 for extra memory. I would think that pat could be done for under $100. Add an FPGA to do step generation or PWM drive and a bunch of I/O connections, and you are up to maybe $200 for a commercial product. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Off Topic, Broaching
On Tuesday 30 October 2007 14:17:43 Jon Elson wrote: Kirk Wallace wrote: Has CNC changed the way keyways are made? I need to make some keyways for my mill conversion, and I have no tooling so far for doing it. Since I will may be buying tooling, I want to explore the options in order to make the best investment. I actually prefer not having keyways and going with set screws on countersinks. Anyone have thoughts on this? Thanks. You can cut keyways on a lathe using the carriage as the power source, the X axis to step the feed, and a hand-made shaper type tool as the cutter. You want to shave off a pretty thin slice each time as the Z axis usually isn't very strong. I have done this manually on occasion, and even made internal splines this way. If keyways were in it before, they probably had a reason. The only really good alternative is taper-lock hubs. The Bridgeport BOSS machines used them, for instance, on the axis drive pulleys, and they worked pretty well. You could actually make some taper hubs on your lathe, now that it is mostly working. It is essentially a collet. You have two pieces that are bored for the shaft on the ID, and tapered on the OD to match a taper cut on the ID of the sprocket. Then, there is a plate that allows small bolts to pull the pulley tight onto the collet pieces. You also need a scheme to push the pulley off the collet. Look in Grainger or McMaster-Carr's catalog (on line) and see if they have a good picture of these. Jon Basically, copy the Browning taper-lock hub idea, it works very well indeed for the higher horsepower stuff. Pix might be available on their web page. Its internal collet is keyed for the usual square stock key, but I've seen the idea used on go-karts 40 years ago where the individual drive sprockets on the axle weren't fitted with a key, so that the firing order of multiple engine setups could be set to alternate for 2, or at 120 degrees for 3 engines. Even w/o keys, they only slipped if the cart jock didn't tighten them in sequence enough times. These were 5.8 to 6.1 cid 2 stroke engines turning up to 17k rpm's, so the shock loads at the lower rpms were pretty high on the hubs, and equally high at the 8 to 10 teeth on the engine sprockets at the top end, stretching a #35 chain for each engine into junk in an evenings racing, at speeds in the neighborhood (both sides of it) of 125 mph. Booze dynamite burners, depending on the track gearing might have hit 150 occasionally. I burned some booze castor for a while, but my converted bilge pump engine was all run out at about 120. It was a deflector head design, they are all done at about 8k rpm's. The torque its rotary intake gave just couldn't make up for the rpm loss, but I had fun and went through way too much money doing it. -- Cheers. Gene There are 4 boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order -Ed Howdershelt (Author) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Jarl Stefansson wrote: I would like to point out that ARM processors aren't the only way to go embedded, there are very decent x86 embedded systems available with AMD (Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs. System based on these can be sourced for less than $100 in bulk and as an added benefit none of the code needs to be ported. Unless you are going to put a hard drive on there, you still have to problem of where the G-code files come from. Perhaps it's time to experiment with building a custom distro to run EMC2 or a subset of it on embedded systems booting from flash NAND/NOR. I guess there are special file systems that reduce unneccesary writes to the flash memory. or, you could put all the writable files on the system with the GUI. Do these systems still have parallel ports? I'm guessing these systems still have VGA ports, too, so you don't really need a separate system for the GUI. Instead of porting the code our time might be better spent optimising for x86 which would benefit all users. My main question is how hard would it be to run EMC in a distributed way so that the motion controller could run remotely from the pulse generator? Hmmm, well the MPG could still be connected to the system running the RT section of EMC, but I'm not sure that's what you are asking here. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Rufi wrote: hello guys, I like to point you to our dspMC motion controller www.vitalsystem.com/dspMC http://www.vitalsystem.com/dspMC. the board has a blackfin DSP from Analog Devices. the Blackfin dsp is supported by Gnu/Gcc comipler and a linux port is available at http://blackfin.uclinux.org. Only $895 Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Jarl Stefansson wrote: I would like to point out that ARM processors aren't the only way to go embedded, there are very decent x86 embedded systems available with AMD (Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs. If you're thinking of the small-footprint PC-like systems, you probably need to think again :) The systems I've seen (and I've looked at a lot of them) are all meant for throughput, not latency. They also have no non-PC I/O. By that I mean that they're usually missing even the parallel port (though some have an internal header for it). We're talking about the controller that actually generates step/dir or PWM signals, and the embedded PCs don't have the connections or the realtime response to do that. They're pretty fast little processors, and if you want to make a little streaming video box they're great, but for the level of realtime performance this project would need, I don't think they can do the job. Of course I'd love to be proven wrong, so if you know of a little embedded PC that actually has RT latencies 5-10 usec, please tell us about it :) System based on these can be sourced for less than $100 in bulk and as an added benefit none of the code needs to be ported. Perhaps it's time to experiment with building a custom distro to run EMC2 or a subset of it on embedded systems booting from flash NAND/NOR. This would be excellent. I have a small system that uses RTAI/HAL, and runs from an SSD hard drive. I managed to get the latencies near 1 microsecond most of the time, with outliers around 2 us. This was done by using ext2 on the disk, and preventing almost everything from loading. Additionally, since the PC has a core 2 duo in it, I create a CPU-hog process, which reduces latency from around 5-6 us to around 1us. (I don't know why it works, but this isn't the only system we've seen that on) I would love to have a small distro that just boots up and runs the app (EMC2 or some other RT app), and doesn't barf when you shut it down by removing power (without doing a shutdown). Instead of porting the code our time might be better spent optimising for x86 which would benefit all users. My main question is how hard would it be to run EMC in a distributed way so that the motion controller could run remotely from the pulse generator? I think the easier thing to do is put the motion controller and pulse generator on the same board, and let EMC2 run remotely the way it was designed - using NML or some other communication method at the CANON level. - Steve - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Off Topic, Broaching
On Mon, 29 Oct 2007, Kirk Wallace wrote: I actually prefer not having keyways and going with set screws on countersinks. Anyone have thoughts on this? Thanks. One trick I came up with is to use a shorter than normal set-screw, and put a cylindrical piece of brass or plastic that matches the internal diameter of the setscrew threads into the screw hole underneath the set-screw. The screw pushes on the cylindrical 'key' allowing use of shafts with key slots, and will still shear off the way a key would, but probably at a lower torque. You could use a fatter set-screw to get the key width up and mill flats on it if you were so inclined... -fenn - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
$300, using pluggable terminal strips ;) Heh, We told Digikey the Avnet price and they came down to ~10.00... For a parallel port replacement Ethernet, maybe a thing to consider is just a single point to point link to the (multi axis) endpoint and some very simple master slave protocol. The slave would get a packet, unpack to hardware registers, and echo a new packet or return data. I've been thinking of doing this with a low cost FPGA card like the 7I43. Just replace the USB interface with a LM3S8933 or something (Nice because it has a built in PHY and IEEE 1588 (no speed demon though)) - Steve - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Jon, it will be in the $600 range for the emc community. like I said, we will not be developing the software so this will allow us to offer the board at a lower price. regards, Abdul - Original Message From: Jon Elson [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 7:53:51 PM Subject: Re: [Emc-users] Ethernet I/O Rufi wrote: hello guys, I like to point you to our dspMC motion controller www.vitalsystem.com/dspMC http://www.vitalsystem.com/dspMC. the board has a blackfin DSP from Analog Devices. the Blackfin dsp is supported by Gnu/Gcc comipler and a linux port is available at http://blackfin.uclinux.org. Only $895 Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Fair enough, although I'm seeing machines that have both an RJ-45 and Wifi, which would address the problem. Javid - Original Message - From: Peter C. Wallace [EMAIL PROTECTED] To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 8:17 PM Subject: Re: [Emc-users] Ethernet I/O On Tue, 30 Oct 2007, Javid Butler wrote: Date: Tue, 30 Oct 2007 19:36:35 -0600 From: Javid Butler [EMAIL PROTECTED] 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] Ethernet I/O Jon wrote- Given all the required overhead to read and write multiple packets, it is already pretty close to chewing up a whole millisecond, and there's no way it could handle even 5 KHz servo update rate. So, I really don't think CAN is a good candidate. I agree. The thread started because of concern about the parport going away on newer machines, and how to replace it. I have not seen any computers with a CAN interface built in, which would defeat the whole purpose. We could consider USB, but that has problems as well and met with resistance upthread. Ethernet is relatively easy, affordable and available, and as Jon mentioned before is isolated. Not arguing for CAN, but Ethernet being built-in is not a great advantage unless there are 2 channels built in, since real time Ethernet (real time meaning fast enough to close a servo loop) will not get along with normal Ethernet traffic and a network connection is almost a necessity, requiring a add-in card in most cases. Not much different from the parallel port case, though faster. Peter Wallace - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Stephen Wille Padnos wrote: Jon Elson wrote: I think the flash is actually slower than external memory access. The datasheet for one of these chips (don't remember which one) said that it was limited to ~55 MHz operating from flash, but 175-200 MHz from RAM. I don't recall if that was internal SRAM or external ram though. It's definitely prudent to stick high-speed ISRs in RAM though. OK, I have read a LOT more about the unavailable NXP ARM7 chips with the 10/100 Ethernet built in, and haven't gotten up to speed on the Atmel version. There would need to be some process on the PC supporting file serving to the ARM, but I suppose NFS would work. Without all the Linux OS overhead and virtual PC nightmares of the current PC architecture, the 70+ MIPS of the ARM processors might be sufficient. You don't need to serve files. The place to put the break between PC and motion controller is probably CANON/NML, not G-code. This eliminates the need to send G-code files to the embedded box, and it also makes G-code additions/modifications happen on the PC only (most of the time anyway). Well, this is getting WAY deeper into this than I wanted it to get! I was hoping for a quick hack to basically extend my IEEE-1284 protocol through some kind of ethernet encapsulation, now we're getting into splitting EMC2 into several pieces running on different architectures. It would certainly be a great facility to have, but this way beyond the amount of time I have to devote to it. If I could do some of the hardware level stuff, like reworking an Atmel development board to just have what we need (like maybe some outboard RAM, Ethernet, parallel port that could be used for step generation or an interface to my controller boards, and the ADC and other features of the Atmel chip, I'd sure be interested in working on that. But, when I look at all the areas that might need work, such as hooking RTnet (or other RT-Ethernet driver/stack) to HAL, getting the same RT-ethernet driver ported to the Atmel chip, and now sawing EMC2 in half without killing it, just like the stage magician, I'm definitely getting overwhelmed. Once the file serving question is handled, the only serious remaining effort (I think) would be porting rtapi to one of the competing ARM RTOS options. I don't know that the embedded processor needs to run Linux. That may be an unnecessarily large burden, though it seems simpler because you're then just networking two Linux systems, which works quite nicely. I suspect, though I don't have any recent experience with it, that ucLinux is pretty RT already, or could be made so pretty easily. There are several Rtos packages for the ARM that are not anything near a Linux kernel. They are much closer to the old rt scheduler. A very interesting idea, but it could be fairly time consuming to deal with all the intricacies of such a big porting effort. It would sure make a NEAT package, and the board could be quite cheap. These ARM microcontrollers are in the $7 - 14 range, they need an additional $12 or so of parts to implement Ethernet, and maybe under $10 for extra memory. I would think that pat could be done for under $100. Add an FPGA to do step generation or PWM drive and a bunch of I/O connections, and you are up to maybe $200 for a commercial product. $300, using pluggable terminal strips ;) Yeah, I know! Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Peter C. Wallace wrote: $300, using pluggable terminal strips ;) Heh, We told Digikey the Avnet price and they came down to ~10.00... For a parallel port replacement Ethernet, maybe a thing to consider is just a single point to point link to the (multi axis) endpoint and some very simple master slave protocol. The slave would get a packet, unpack to hardware registers, and echo a new packet or return data. Yes, but it has to have a real time driver module, that's the problem. And, it would require two ethernet ports on the system, if you wanted to also be on the local network. I've been thinking of doing this with a low cost FPGA card like the 7I43. Just replace the USB interface with a LM3S8933 or something (Nice because it has a built in PHY and IEEE 1588 (no speed demon though)) For what I want to do with t, it has to be pretty fast. I'd want to leave the possibility it could run at a 10 KHz servo update rate, otherwise it is a step BACK from the parallel port. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Peter C. Wallace wrote: On Tue, 30 Oct 2007, Javid Butler wrote: Date: Tue, 30 Oct 2007 19:36:35 -0600 From: Javid Butler [EMAIL PROTECTED] 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] Ethernet I/O Jon wrote- Given all the required overhead to read and write multiple packets, it is already pretty close to chewing up a whole millisecond, and there's no way it could handle even 5 KHz servo update rate. So, I really don't think CAN is a good candidate. I agree. The thread started because of concern about the parport going away on newer machines, and how to replace it. I have not seen any computers with a CAN interface built in, which would defeat the whole purpose. We could consider USB, but that has problems as well and met with resistance upthread. Ethernet is relatively easy, affordable and available, and as Jon mentioned before is isolated. Not arguing for CAN, but Ethernet being built-in is not a great advantage unless there are 2 channels built in, since real time Ethernet (real time meaning fast enough to close a servo loop) will not get along with normal Ethernet traffic and a network connection is almost a necessity, requiring a add-in card in most cases. Not much different from the parallel port case, though faster. RTnet solves this problem by time division multiplexing the ethernet, but then you need some other machine to have the dual ethernet ports to work as a router. But, you only need one. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Ethernet I/O
Jon Elson wrote: Jarl Stefansson wrote: I would like to point out that ARM processors aren't the only way to go embedded, there are very decent x86 embedded systems available with AMD (Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs. As others have pointed out, miniITX and such do not solve the problem because there is no appropriate IO available in most of them. System based on these can be sourced for less than $100 in bulk and as an added benefit none of the code needs to be ported. Unless you are going to put a hard drive on there, you still have to problem of where the G-code files come from. NFS. You don't need it much, only to copy the files to slave system from the server and you can disconnect the network afterwards for security or latency reasons. There are other possibilities to go about this: http://www.emdebian.org, http://www.ltsp.org, or http://www.etherboot.org for example. Bootup takes only a few seconds so it would be possible to rebuild the whole OS and simply reboot the slave system. Other advantages are low initial and maintenance costs, one non-RT server could feed a number of diskless EMC systems on the shop floor, etc. Default OS with basic EMC functionality could still be stored in EMC system flash memory. Providing virtual appliances for bootup from the net and testing would also be easy with virtualization now being mainstream. Instead of generic EMC, a set of preconfigured appliances could be built to help new users. Perhaps it's time to experiment with building a custom distro to run EMC2 or a subset of it on embedded systems booting from flash NAND/NOR. I guess there are special file systems that reduce unneccesary writes to the flash memory. or, you could put all the writable files on the system with the GUI. Do these systems still have parallel ports? I'm guessing these systems still have VGA ports, too, so you don't really need a separate system for the GUI. Instead of porting the code our time might be better spent optimising for x86 which would benefit all users. My main question is how hard would it be to run EMC in a distributed way so that the motion controller could run remotely from the pulse generator? Hmmm, well the MPG could still be connected to the system running the RT section of EMC, but I'm not sure that's what you are asking here. Jon -- Rafael - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
