![]() | |
| Home Page | Mark Forums Read | Today's Posts | My Replies | Classifieds | Reviews | Photo Gallery | Web Links | Share Files | Advertise With Us | Ad List |
| |||||||
| Haas Mills Discuss Haas machinery here! |
| This forum is sponsored by: |
![]() |
| | LinkBack | Thread Tools | Search this Thread | Display Modes |
|
#1
| |||
| |||
| Ethernet package is worth the money? We have decided on a Haas Tm-2. I want to know if the Ethernet package is worth the money? $2,995.00 We have some real computer guru's around here. (Not me!) So getting the RS232 to work should be no problem. We plan on having a "Mill PC" 10 feet away at most with a connection to our LAN. I plan to load our programs to the "Mill PC" from wherever and the use the RS232 to transfer from the "Mill PC" to the TM-2. Link to TM-2 options about half way down the page. Any and all help is welcome. |
|
#2
| ||||
| ||||
| Man they are making money on that option, aren't they! Today a typical PCI ethernet card is about $4-$10 |
|
#3
| |||
| |||
| 050711-1935 EST USA sundy58: It is an expensive option. You should really play with the option to see if it functionally meets your needs. From a general system perspective you need to analyze the number and size of files with which you will work. Will you be dealing with thousand or tens of thousands of files? Many of which might be nearly identical. or Will you work with maybe 10 files and never save these for future reference? Will you send files in both directions? With RS232 at 115.2 kbaud you can transfer about 500,000 bytes per minute to HAAS and maybe a little faster from HAAS to PC. May depend upon the year of manufacture. This should more than keep up with most drip feed applications, and for reasonable size files, like up to 5 megabyte, is not too long a wait. If you use low capacitance cable, 15 pfd per foot, you may be able to work with 15 to 20 ft of cable at 115.2 kbaud. With direct connection of the RS232 cable, meaning no isolation, you should put a single phase transfomer from the HAAS machine three phase input, any two lines, to 120 v output to supply computer, and accessories. It needs enough VA capability for whatever this load would require. Also a safety ground wire from the HAAS safety ground point to the safety ground wires of the computer equipment. Do not use any convienent wall outlet, this creates major ground loop problems. If you want electrical isolation of the RS232 link we have product, I232, that has optical isolation, can operate at 115.2 kbaud with good ground loop noise immunity, and do this to 4000 ft in many applications. We have put a 1000 v rms 60 hz signal ( +/-1414 v peak ) on the interconnect line with no effect on data transfer or equipment damage. See our web site www.beta-a2.com. For your distance it would be a little over $200. . |
|
#4
| |||
| |||
| sundy58, Here’s my take, all those Haas computer type options are too expensive. If you want the Ethernet to just transfer files for permanent keeping in the Haas memory, then to make it worthwhile you need the memory upgrade or the add-on hard drive option. I believe the standard memory size is 1 MB. So, ya, to transfer 1 MB worth of files using an Ethernet connection will fill the Hass memory it in the blink of an eye but, using RS-232 at 115.2K baud should take no more than about 1 to 1-1/2 minutes to transfer a megabyte of data. So in my opinion, having the Ethernet without the extra memory (which is big bucks to add-on) is kind if like speeding up as you approach a red stop light - no sense in hurrying to have to stop. Now the Haas comes with the RS-232, is capable of supporting 115.2K baud and also supports the Xmodem protocol for added data integrity during a transfer. Where this is really going to shine is if you have to dripfeed a large program that won’t fit in the memory you have. The transfer rate only needs to keep up with the Haas line processing – RS-232, even at one of the lower baud rates, is more than capable of this. I don’t even know if you can drip feed using Ethernet – you will have to ask your dealer – but, if you can, its overkill. One more comment, if you stick with just using RS-232 (and it may be your only option when you DNC), I highly recommend as cheap insurance the I232 system, that gar mentioned, it is plug-n-play, it opto-isolates both the TX/RX signal at both ends of the cable, eliminates electrical noise issues and will make long cable lengths a non-issue. To transfer at 115.2K Baud (or slower), even under the best of conditions, could be an iffy proposition in a machine shop environment even when using a short cable. The I232 system takes care of this problem. Just my 2 cents. . . plm |
|
#5
| |||
| |||
A. Fix program B. Go to mill PC C. Open file w/send - recieve program D. Get mill ready E. Send file. F. Wait... ACK! what a forkin PAIN! I think it is well worth it depending on what you do. We have "lots" of files. They also reside on a server. We don't just have a "mill PC" that would not work in for our backup system. If you only ever run one program on a dedicated machine, then no it's not for you. We have the e-net, hard-drive, usb system. On the VF3-SS (Westec machine) Pro's 1. Remote program fetch is nice. The mill can see the network and files on it (permissions apply of course) 2. I "think" you can drip from the HD, but I don't think you can (or would want to) drip from e-net. 3. It is very fast (duh). 4. Makes the machine buffer memory very clean. I have only 2 programs there, warm-up and the file running on the mill. 5. Drag and drop from my desktop to the mill HD ![]() 6. PC just for the mill is no longer required. 7. When I change the file at my PC, by the time I walk to the mill it is there, I don't have to go "download" the bloody file, hurry up and wait, etc. 8. You get a 20gig HD at the machine. 9. USB jump drives can be used for sneaker transferr if your lan goes down. 10. No forking around with a program just to transferr the files! Con's 1. Cost (duh) 2. Setup can be difficult (permissions with a complex network can be a pain) 3. Did I mention cost? If you have any direct questions about it I will try and fill you in. Best regards, Sean |
| Sponsored Links |
|
#6
| |||
| |||
| Good info Thanks guys. Thats just the feedback Iwas looking for. We are an electronics shop with very low volume. I can't think of a reason to not store the programs on a computer to serve to the machine as needed. Why would I want to go from the Haas back to PC? I'm extreme newbie at this. Great advice on the power for the PC Gar. Have fought ground loops before. They might explain why my hair is leaving me. The Haas ethernet comes with the 20G harddrive and several other pieces. NOT $3k worth IMHO but I am a chip sweeper. |
|
#7
| |||
| |||
| 050712-2038 EST USA sundy58: One reason to send a file back to the computer is to do a file comparison. This is even better than XMODEM for program verification because HAAS compresses your program when it is loaded into main memory. Thus, XMODEM when it verifies transfer is not working with the data that is in main memory. That HAAS compresses data you can see by comparing the amount of memory used in HAAS with the size of the file you sent. When you send the file back to the computer HAAS re-expands the program, By this method you actually check the data that is used by HAAS to run the program. Another reason is that you may make program changes on the HAAS and then want to save the actual file that was used. Still another is that you may compose a program on the HAAS and when done you want to save the program. Also you can use DPRINT to send information to the computer. (edit 0507813-0547) Even if you use file comparison for final verification of your data XMODEM can be valuable for detecting and thru resend correcting errors during communication. What file comparison does for you is detection of errors in HAAS processing after XMODEM has done its work or errors in HAAS main memory. (end edit) . Last edited by gar; 07-13-2005 at 06:56 AM. |
|
#8
| |||
| |||
| Excellent info. Thanks gar. So more memory in the machine would be a help. I will max out the memory when ordering. |
|
#9
| |||
| |||
| 050713-0555 RST USA sundy58: The amount of memory you buy is a function of expected need and cost. All of our newer machines have 1 meg of memory. This is sufficient for our needs. On our lathe we may have 100 to 150 programs resident at one time. Mills generally have longer programs than lathes. Stored on the computer we have many thousands of programs. Our two older mills have maximum baud rates of 38.4 kbaud and the newer machines have 115.2 capability. We always operate at maximum baud rate for the particular machine. If you do contouring with large files ( mold, carbon electrode, or model ) you may find DNC (drip feed) more practical than buying enough memory to load the entire program in memory. . |
|
#10
| |||
| |||
However, the control checks files "regardless" of where they come from. When I attempt to load a file into the machine buffer (run memory) if the file contains syntax type errors they will trigger an alarm. This is about all you are getting from the xmodem error checking. Confirmation that what you are sending is what the control is getting. There is no "quality" checking. You can still send a bad program via RS232 or e-net. As long as the program passes syntax checking it will load. Xmodem is a good thing as the type of connection in question can be somewhat "less than dependable". This can be compounded by using max speed via RS232. RS232 possibly brings the pain of : 1. The "mill PC" can be tempermental. Meaining some computer RS232 systems work far better than others. We needed to try 3 computers here with the late Fadal to get a PC talking to the mill @ 115K (long run on the wire however) 2. RS232 / modems are KNOWN to be more likely to pass a voltage spike. Personally, I think the 3K option is worth it to prevent this alone. IMHO, smoking something in a 100K machine over a <1K PC is not something I feel ok about. Granted you could just unplug the 232 everytime, but here we are with that pain in the neck thing again. That being said, indeed an e-net connection can indeed pass a "strike" to the mill. However, it is FAR more rare for this to occur. In defense of this, I would say that most commonly the server in any given shop that the mill would likely be connected to will be on a protected uninterupted power-supply. Further protecting connections to the expensive machine. Best regards, Sean |
| Sponsored Links |
|
#11
| |||
| |||
![]() Haas says max cable length of 6ft @115K. 6ft is close to the mill, generally speaking PC's in shop enviorments without enclosures are "on borrowed time". Now you are in for a PC' and a respectable enclosure, if the area around the mill don't "run clean". For me it's also not about just the transfer time. It's about the "overhead" for the transfer. It's the constant crap of setting up the file transfer on the PC, then go to the mill and do steps to get the file. Now I just: 1. Post file @ my desk. 2. Walk to mill. 3. Call file to run buffer 4. Cycle start. Screwing around with 232 ain't nothing like that. 1. The 20gig HD comes with the e-net. 2. Drip feed from e-net drive location is possible (checked our manual it's called "FNC") 3. Same as above for any files on the mills HD. 4. Of course you can call files form either location right from the mill. 5. Editing files at the mill across the e-net and on the HD is supported. 6. You can even M98 call subs as long as they reside in the same directory on server or HD. This is the misunderstanding I'm thinking. Granted our machine came with 16meg, the e-net, and the kitchen sink. However, if you wanted to save money, given the functionality of the e-net option and whats included just keep the memory standard. That saves 1500.00 dollars. Yet, you can still run any size file much easier, etc, etc. In a "one off" shop this is a no-brainer if you ask me. This option would get used LOTS. If said "one off" shop commonly deals with files greater than 500K then even more of a no-brainer. If the shop only sends files once a day, week, etc. Then no, it really will not get used to potential. Yes the option is WAY OVER-PRICED! We all know what an e-net card goes for. However, IMHO this is one option that does shine. Best regards, Sean |
|
#12
| |||
| |||
| MR_NC ---- “Yep, everything from any machine builder is gonna be painful. At least we are not talking Fanuc ” You sure have that right! ------ “Screwing around with 232 ain't nothing like that. 1. The 20gig HD comes with the e-net. 2. Drip feed from e-net drive location is possible (checked our manual it's called "FNC") 3. Same as above for any files on the mills HD. 4. Of course you can call files form either location right from the mill. 5. Editing files at the mill across the e-net and on the HD is supported. 6. You can even M98 call subs as long as they reside in the same directory on server or HD.” I have since looked into the Ethernet/HD/USB option a little more by asking my Haas dealer questions about the benefits and limitations. He basically said all the same things you stated above – I wish I had caught your post before wasting my time with Haas. But the one thing that is left out of your list (and Haas also does not push) is the level of comfort obtained with your data integrity using an Ethernet transfer. For me that is more important than the convenience and speed benefits. ------- ”This is the misunderstanding I'm thinking. Granted our machine came with 16meg, the e-net, and the kitchen sink. However, if you wanted to save money, given the functionality of the e-net option and whats included just keep the memory standard. That saves 1500.00 dollars. Yet, you can still run any size file much easier, etc, etc. In a "one off" shop this is a no-brainer if you ask me. This option would get used LOTS. If said "one off" shop commonly deals with files greater than 500K then even more of a no-brainer. If the shop only sends files once a day, week, etc. Then no, it really will not get used to potential. Yes the option is WAY OVER-PRICED! We all know what an e-net card goes for. However, IMHO this is one option that does shine.” I agree, if the Ethernet works as both you and Hass have indicated and comes with a hard drive, what’s the use in getting the 16M upgrade and getting it stuck to you at the same time. ----- I do agree that for a business environment, in most cases you would be quibbling over pennies when you stand to make dollars in the long haul. I would have probably got the Ethernet/HD if that was my situation. But for me, the Haas I purchased a couple of years ago was for hobby use in my garage. I don’t recall the HD coming with the Ethernet and there was no USB at the time – the package does sound like a better deal today and, since you can drip feed from the net or the drive, it appears Haas has covered the major bases . Anyway, I was already familiar with the typical size of the programs I was generating and felt that I could get by with the painful $500 purchase of the floppy and stick with the standard 1MB of memory - this has worked fine for my needs thus far. However, at the time of purchase, I did question Haas about DNC capabilities of the machine in anticipation of the need in the future. They told me that it is supported through an RS-232 port that comes standard with the machine. My next question was: Do you support a modem data transfer protocol (something like Xmodem, Zmodem, etc.) and not just raw ascii with only parity checking? His eyes where a little glazed after that question and said he would get back to me on that one. He called a couple of days later to pleasantly inform me that the Xmodem protocol is supported. Sooo. . . for me when the time comes for me to deal with a larger program that my floppy/1M memory can not handle, I decided that I will DNC using the RS-232 and the Xmodem protocol, and the speed is not an issue as long as it can keep up with the Haas line processing, which it can at much lower baud rates than 115.2K baud. Well the future is here for me and I am starting to do a lot of 3D machining. Some of these programs far exceed my 1M memory, so it was time for me to get the DNC going. I am doing what I had planned a couple of years ago with one addition; I have added some cheap insurance by way of a plug-n-play I232 system from Betatronics which opto-isolates the TX/RX line at both ends of the cable and make cable lengths and electrical noise on an asynchronous protocol a non-issue when running at 115.2K Baud. Through much testing and usage, I have yet to see a block resend because of a packet error. From my previous post, it might have sounded as if I am an RS-232 proponent – I’m not, at least for not sending sensitive data. I’ve stated elsewhere that the bit-error rate for RS-232 is just a little bit better than a couple of tin cans connected by a string. A poor bit-error-rate on whatever type of data transfer method that is being used is not the problem. The problem is not being able to detect and correct/recover from such errors. If the error can be detected and recovered from, without incurring an unacceptable performance penalty, to me that is acceptable. An example of this is the read data coming off the disk on a hard drive. Bit errors occur more frequently than some people would suspect. But the modern day drive have powerful Error Correction Codes (ECC) appended to the data blocks that can detect multiple-bit errors in a sector of data and, even within it’s own ECC field. These codes can not only detect the bits in error, but correct them to what they should be all “on-the-fly” with no performance penalty. So data integrity is everything to me and that’s why Xmodem, or something similar, is so important to me when I’m using RS-232, especially if it is in a DNC situation. Xmodem has the capability to detect most transmission errors and recover from it – you need this when drip feeding. It’s frustrating when your down to the last few minutes on a part and a garbled character comes across, the Haas program processor balks and halts because is creates a syntax error. Worse yet is if the garbled character is in a numeric field, like a coordinate position. The false value is a number character and the complete number is still within the work envelope of the machine so the controller is not going to detect it and it will faithfully move to that unintended coordinate – we all know what several of the consequences of that scenario could be. Anyway thanks for your input on the capabilities of the Ethernet/HD option. For just the data integrity that it provides, it indeed sounds like a worthy, but pricy, feature. plm Last edited by pmurray; 07-13-2005 at 09:48 PM. |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | Search this Thread |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Who is making money with their CNC... | JavaDog | Polls | 162 | 11-13-2011 09:26 AM |
| haas ethernet connections | Jim Walker | Haas Mills | 11 | 04-25-2010 02:14 AM |
| Need money Help | cnc2k | DIY-CNC Router Table Machines | 5 | 11-22-2004 01:38 PM |
| Serial Ports over Ethernet | cely | Computers and Networking | 0 | 12-24-2003 01:19 PM |
| Ethernet Communication with Fanuc 18i-T | smabhyan | General CAM Discussion | 3 | 10-22-2003 11:45 AM |