[pmurray]

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