050620-2034 EST USA

What baud rate do you use? and why?

Speed of loading...... :D

I've found that 19.2 seems to work best for me in speed and complete loads. Some of my older machines go only 9600 max. And of course the newer stuff is on ethernet so its just drag and drop. I've tried a few times to get faster but found that the length of the cable has a effect on getting the loads. It would drop codes etc. This is for all of my machines, not necessarily just to Haas.

:cheers:

050622-1459 EST USA

Where are all the 9600 users. Our HAAS serviceman said the majority of his contacts operate at 9600. He indicates considerably more than half are at 9600, and extremely few at 115.2 k.

So far we are top heavy at 115.2 k, but a very limited sample.

Check more than one baud rate if you operate at different rates.

.

I have used a CAT5 hookup with RS232 converters at each machine; and had each machine mapped (by IP address) to it's own phantom COMM port. This allowed long cable runs, no switch boxes, transfer to the CNC from any PC on the network, higher data speeds, etc.

It also worked horribly - dropped characters, converter boxes that had to be re-booted any time the machines were powered down, limited data transfer programs due to the use of phantom ports, and a PC that would hang at random times due to having two network cards.

I finally gave up on it (the local company that pitched the idea to us and sold us the hardware was never able to make it work right in 8 months), and hard-wired all of the machines to a central PC with a pair of switch boxes.
Everything is running at 4800 baud, and I've not had a problem since!
2 Fanucs were already set at 4800, so I set all of the machines the same, so I only need a single setting at the PC. And 4800 is fast enough that the program is in the control by the time the operator wanders back from the PC.

I know it's not 'life in the 24th and a halfth century' DNC, but it works smooth and easy first time every time. And that's good enough for me.

i currently use 19k baud and it works fine at every machine. Although the newer machines can go as high as 52k (although I think it a cable problem) I keep all of them the same for simplicity.

If I have to many more problems I will probably look into something like what gar mentioned, but the cost is probably too high to justify. (one of the reasons for wiring all them with cat5 cable)

I bought the setup from GAR to run 115.2 kbaud on my HAAS minimill. I have had no problems with losing data in the transfer to the machine. The cost to get this from GAR was 265.00 with 125 feet of cable. I ran the cable mounted the isolators and used the settings GAR supplied me with and was running in less then 3 hours (2.5 hours running and mounting isolators). I will be buying from BETATRONICS when I get my next machine because the product is as described and the service is A1 (still calls me to make sure all is going well). If you are not sure if this is for you call GAR and ask him (Gordon) why it is better he talked to me for 1/2 hour explaining the benifits. This is not a sales pitch just one happy customer.

Joe
JPW Machining

I am still using floppies to transfer programs to my Haas; however, I am starting to get into 3-D surfacing and noticed that the size of the programs are getting quite large and are on the verge of exceeding the size of the floppy and Hass onboard memory.

Because of this I have been contemplating using the RS-232 connection to drip feed a large program and use in lieu of the floppy for small-program transfer to Haas memory.

I have not looked into this yet but, since this thread came up on the forum, I thought some of you may be able to address my concerns and questions.

I am hesitant of sending raw ascii/hex code with out some sort of data integrity check. My question is: Irregardless of baud rate, can you transfer data to/from Haas using a protocol that has some sort of data integrity check (CRC or similar) on small data blocks with auto resend on a block when an error is detected? As I recall I think the old Xmodem protocol used this sort of technique.

If so, what is a good program to use on the computer side to drip feed a large program to the Haas or just download a complete small program that would support a data xfr protocol (with data integrity/resending) that the Haas supports?

Also, can you tell me more about the BETATRONICS product? From reading the above posts it appears to extend the normal 30-40 foot range of RS-232. I will need about a 20-20 ft connection and would like to transfer at 115K (still only about .7 MB/min) but know from experience that this would be iffy.

Any info would be appreciated.

Hey slowjoe what kind of cable is it that the unit uses? I thought it was wireless. (must be thinking of something else :) )

I used a CAT 5 cable supplied by Betatronics. My cable length is 137 feet. I use this setup to do all my transfers to/from the machine as I dont have a floppy drive. I figured I saved 150.00 by going with Batatronics I232 setup because the floppy drive from haas is 400.00. I would go to betatronics website http://www.beta-a2.com/i232.html and read the information plus you can call Gordon there and he can answer any question you might have.

Joe
JPW Machining

050623-1513 EST USA

pmurray:

I put this poll under HAAS rather than at a general point, because HAAS since about 1998 has 115.2 kbaud capability.

HAAS provides Xmodem under RS232. This operates as you indicated.

Few people use Xmodem, but it would be better if it was used. Anybody using it please indicate this.

On HAAS if you use Xmodem, then you must select no parity and 8 data bits. I always suggest that you use 1 stop bit unless for some reason an RS232 source or destination requires 2 stop bits.

If you do not use Xmodem, then you should use parity, and 7 data bits. There is no need for 8 data bits. If you use 8 data bits then you transmit about 10% slower than with 7 data bits.

Single bit parity is an error detection method. This is the only type available in standard UARTs. The parity check is done on a byte by byte basis. A single bit parity check will flag any odd number bits in error in a byte. Thus, two bits reversed in a byte will not produce a single bit parity error, but three bits in error cause a parity error. For much analysis in information theory it is assumed that the error rate for two bits is the square of the error rate for one bit. With an error rate of 1 bit 100,000,000 bits you see the error rate is extremely low for two. Usually this is based on the noise being white Gaussian. This is not necessarily true in the industrial environment, but still you expect the two bit error rate to be less than the one bit rate.

If a greater number of parity bits are used, then more complex errors are detectable and some error correction is possible.

Note, Xmodem does not use a parity but rather a checksum over a block of bytes. On detecting an error Xmodem requests a retransmission.

On receipt of data HAAS flags errors it can detect. If parity is on, then this is one type of error.

If you are not doing DNC (meaning drip feed) then a very good error check on data sent to the CNC is to send the file back to the computer and do a file comparison.

I do not believe any HAAS machines provide a means to compare two programs in their memory. So to check a program sent from HAAS to a computer send the program twice and compare the two in the computer. What we normally do is a SEND ALL, then send each individual file. If we find a problem later, then we compare one with the other.

With a suitable interconnect system you can get very low transfer error rates without Xmodem, but Xmodem is better. I do not have a suggestion for an Xmodem program. We may have to write one.

In an environment that is not too noisy we can transfer 115.2 kbaud 4000 ft and actually functioned to 8000 ft, but the signal level is too marginal at that distance and baud rate.

This poll is not a sales pitch, and we will not contact anyone without their request. So we are not probing for names, and therefore feel free to mark all the different rates you use. The names that show up in the poll are useful to indicate multiple baud rate useage. What I want is to try to get a realistic response of what users are doing and why. There are no incorrect answers. The goal is to get relatively unbiased answers.

.

050623-0934 EST USA

I had to run some tests tonight. These were at 115.2 kbaud, XON/XOFF, 7 data bits, even parity, and 1 stop bit. The machine is our 1998 VF-3.

It took about 54 seconds to receive a 550,000 byte file from HAAS. To send the same file back to HAAS took about 77 seconds.

Thus, receive from HAAS was about 611,000 bytes per minute, and sending to HAAS was about 430,000 bytes per miinute.

.

Gar,

Thanks for the reply and info.

I didn’t realize you were with Betatronics until I looked at your profile. I have a couple of more questions about a good host program to use for drip feeding and the best handshake protocols to use with the Hass, etc.

I got your phone number from your website, so I will try to call you tomorrow or early next week - I am interested in your product an like what I see.

Thanks,

plm

FYI,

I got around to hooking up my laptop’s RS-232 to the Haas in order to do some experimenting.

Using the Xmodem protocol (sending using a terminal program I had that supported Xmodem) and a cable length around 25’ at 38.4K baud was the maximum speed I could obtain. As I recall this was the max baud rate recommended by Haas when using a cable that is 25’ or less.

The next highest baud rate available on the Haas was 115.2K baud which I tried with the same 25’ cable and using Xmodem – couldn’t get to first base. On the computer upload end, which has a status screen for the upload, I kept getting an unknown start code message.

So the problem wasn’t even an over abundance of block re-sends. The initiating start character for each block that is sent by the Hass to tell the sender to start sending a block could not be understood (i.e. the very first character).

plm

050627-0544 EST USA

pmurray:

Your experiment is probably about correct.

For a standard RS232 direct connection the cable length at a given baud rate is primarily a function of the cable capacitance and the source resistance of the RS232 driver.

Source resistance is constant for a particular source, but may vary from one port to another. A 1488 type driver has an internal resistor driven by a voltage source limited at about 10 milliamperes. Thus, it is a non-linear source. (edit 050627-0630) It is not so much that it is non-linear, but the initial charging rate looks like 1200 ohms (12 V / 0.01 A) so this current limit slows down the charging of the cable capacitance. (end edit)

The cable capacitance is proportional to cable length. Without going back to details on measurements that I made, my memory is that Belden 8723, a Beldfoil shielded cable, is in the range of 60 picofarads per foot, and unshielded CAT-5 cable is about 15 picofarads per foot. Thus, unshielded CAT-5 would allow a cable about 4 times longer than 8723.

With Belden 8723 in a direct connection from computer RS232 port to HAAS RS232 our experience at 115.2 kbaud was good up to about 6 feet. In our I232 system we use 2 feet for the RS232 cable.

Between our I232 modules we use a much lower source resistance and CAT-5 cable to get 4000 feet at 115.2 kbaud, 8000 feet at 19.2.

Common mode noise is also a problem, but is not necessarily a function of cable length and/or baud rate. (edit 050627-0630) If there are no noise problems then Xmodem does nothing for you. Also, if noise is extremely high, then Xmodem does nothing for you. In between it is great and should be used if at all possible.(end edit)

It is good to see some 9600 baud rate responses in the poll because this is where I expect the peak of the distribution curve to occur.

.

050627-2134 EST USA

pmurray:

Per your phone call to me today find information in a personal message to you.

.

I used a CAT 5 cable supplied by Betatronics. My cable length is 137 feet. I use this setup to do all my transfers to/from the machine as I dont have a floppy drive. I figured I saved 150.00 by going with Batatronics I232 setup because the floppy drive from haas is 400.00. I would go to betatronics website http://www.beta-a2.com/i232.html and read the information plus you can call Gordon there and he can answer any question you might have.

Joe
JPW Machining

Joe, I replaced the floppy in my Haas with a new Sony drive. That, as well as using Sony floppy disks seems to have improved the frequent read errors I was getting.

I still use a floppy for small programs, but I have a standard wireless ethernet setup to use a comport emulator which converts ethernet transfer back to RS232. (My Haas is older and does not have ethernet). I have run this a couple of times at the max that my Haas will permit, 38.4K and it is okay. I always prove out the program after transfer in graphics mode, in hopes of catching a transmit error.

I can't vouch for how error free it is in heavy usage. I just don't have to transfer large files very often, and that's what I got it for (well I was going to bypass my flakey floppy, but now its okay...)

I've heard that it takes a Pentium4 to do successful transmission and error checking at high baud rates.

I still use a floppy for small programs, but I have a standard wireless ethernet setup to use a comport emulator which converts ethernet transfer back to RS232. (My Haas is older and does not have ethernet). I have run this a couple of times at the max that my Haas will permit, 38.4K and it is okay. I always prove out the program after transfer in graphics mode, in hopes of catching a transmit error.

hey HuFlungDung where did you get this unit and roughly what does it cost and brand name ect...

Miljnor,
Note I am not necessarily endorsing or encouraging use of this product. It seems to be okay.

It was about $380 USD.

http://www.moxa.com/product/NPort_5110.htm

050701-1515 EST USA

Hu:

Could you run several experiments with your RF setup at 38.4 kbaud. These would be:

1. Create a test file of about 50,000 bytes. Use 7 data bits, even parity, 1 stop bit, and XON/XOFF. Or if you are not setup this way, then identify the values.

2. Measure the time to send this file to HAAS.

3. Measure the time to send this same file back to the computer.

Theoretically the maximum rate is 3840 bytes per second with this 10 bit serial word. I believe HAAS is doing more processing of incoming data on receive than when the same data is sent beck to the computer. Thus, I don't expect the same rate in both directions, and I expect some inefficiency.

The next experiments are to add interference.

4. Place a microwave oven at the midpoint between the computer and CNC antennas. Run the microwave during the entire time that the large file is sent and repeat tests 2 and 3.

5. If this completely stops communication, then perpendicular to the line between the computer and CNC, and from this mid point move the microwave to a location so that the radial distance from the computer to the microwave is equal to the distance between the computer and CNC. Now what are the results.

A quick test we did on an RF link where the transmitter and receiver were about 50 ft apart and separated with a cement block wall, and the microwave was about 120 ft from the perpendicular point produced a 50% reduction in thruput.

.

I have a haas vf3 94 mdl and I use the 19.2 rate with good results. I would try the 38.4 as I can still feed faster than the machine can take in data but it seems that the predator editor v6 software I use has a limit of 19.2 and I have no idea whether this is a real limit or if I just dont know where the settings are for the increase to 38.4. Anyone know about this?

050711-1947 EST USA

lapuser:

Go to www.predator-software.com and ask your question.

Gar, the real problem with this suggestion is that the version of predator editor I am running was a part of Surfcam 2003 and I dropped my maintenance with them to go with VX cad-cam about a year and a half ago. They will sell me support for an hourly fee but I am not rolling in dough this year so at the very least I can work at 19.2. The faster feed rate did sound nice though and I was hoping someone here would know if it can be done and how. As an aside, it seems a shame that there is allways a bad side to software. I bought VX and the cad side of the app is wonderful. The cam side however is seriously lacking and it is a shame to say that over a year after I had this I was still using Surfcam to run my mill. VX has just recently finally generated a post for the haas [ and in my opinion and compared to Surfcam a lot of fooling around to get it to work and not a decent tool library or feeds and speeds proceedure anywhere in sight!] but guess what!!! Now I still have to use the predator editor app to post to the mill because VX can't. I find myself with one foot in Surfcam and one foot in VX cad-cam and many thousands of dollars and gobs of time later pondering just how smart I am in my choices.

050712-0618 EST USA

lapuser:

If you use an external program for transferring programs to and from the HAAS, then you do not need to be limited in choices.

We transfer programs with our own software, or from Mastercam.

An important point with Windows is that you inhibit the UART FIFO. Under Windows this means setting it to 1 (minimum). Probably makes no difference for HAAS but can be a big problem on Fanuc.

You might try Hyperterm in Windows for transfer, or some other tricks. Maybe pmurray will help you.

.

lapuser,

I looked into using Hyper Terminal to use as a general file transfer program over an RS-232 link. The problem I found was that it supports a very limited number of protocols. It does not even support raw ASCII which most people would use and, is the only protocol most machines support. Personally, my machine will support Xmodem, which I like to use, but there are several variations of Xmodem and the one I needed was not supported.

Before looking into Hyper Terminal, I was using an old terminal program that was written prior to WIN2K. I am running XP now and for some reason, the old software had a lot of latency between characters. Even though my baud rate was set to 115.2K baud, my character throughput was less than 700 characters/sec – this is slower than using 9600 baud.

Like you, I did not want really want to spend the money for new software, thus the reason for looking into using Hyper Term. But, I had been already been contemplating getting a copy of ProComm Plus to replace the older terminal software I had been using because ProComm has a few handy features I can use with other work I do with serial ports on embedded controllers I build.

So I decided to kill two birds with one stone, fix my CNC transfer problem and get a more powerful tool to use with my embedded controllers. I was already familiar with ProComm because it was what I used in the later years of my professional life and I knew it would work well with XP. Since getting it, my CNC files transfer at the expected rates and it gives me the extra tools I needed for my other projects.

I bought it here: http://www.atomicpark.com/xq/aspx/symantec-procomm-plus/familyid.6141/buy.software/qx/productlist.html

They are listing it for $73.99 and that includes shipping – this is about $60 cheaper than what I saw at a lot of other places.

I know you don’t want to hear this because it means more $ and does not really consolidate all the software you are already having to use. But, it is all the help I can offer right now.

I remember looking at some commercial DNC software, quit expensive, but it would only support a raw ASCII protocol. In talking with gar, I mentioned that when I get the time I could patch together a fairly nice DNC/File transfer program from previous programs I’ve done and I would put it in the public domain for anyone to use or bundle with their own product – source code included and it will be free for anyone to use, even for commercial benefit. The only catch is, I might make enhancements to it but I won’t officially support it but, the source code will be supplied.

One feature I would like to see, and maybe some of the commercial programs do this, is send a list of files all at once so one does not have to walk back and forth between machine and computer when transferring several files. I’ve also seen some of the commercial programs have a text editor – I can add one of those too from an IDE Compiler/Assembler I wrote for use with a custom processor I had to design and build.

If only I had the time but, right now I’m swamped.

Well I’m starting to ramble and had better let you go.

Sorry I could not have been of more help to you. . .

plm

Thanks for the time spent in your reply. I am not sure what this program would do for my problem as I clearly lack the experience you have in cnc communication. I bought a grizzly cable some time back for data transfer and do not think I have a problem in lost or corrupted data transfer. And basicaly I am quite satisfied with predator editor and have made that work fine with VX. Where the problem is for me is the 19.2 limit that I think is tops for dnc in predator editor. In the sdnc I could theoreticaly send up to a 115.2 rate and why the difference between dnc and sdnc I don't know. Any more thoughts on this issue would be apprciated. Thanks, Dave

050722-0907 EST USA

lapuser Dave:

I have no idea what "predator editor" can do and their web site contains no useful technical information. Have you call them to see if there is a ways to do 115.2 kbaud?

Try searching the Internet for free demo software that you could try as stand-alone communication software.

The difference in software is a result of what the designer decides to include. Also sometimes capability may be hardware limited. If one software package will run at 115.2 on your machine, then the capability for that speed is there.

UARTs are driven by a clock at some relatively high speed. This clock signal is then divide down to a frequency that is 16 times the baud rate ( 16 is typical ). This 16x clock signal is used to sample the incoming serial data. At the start of a data word ( leading edge of the start bit ) ( a data word is the roughly 10 bits used to send a byte ) an 8 count counter is enabled and counts the 16x clock. When a count of 8 is reached the incoming data is sampled. Thereafter the counter counts to 16 to determine the sample point of the next bit. The divider that generates the 16x clock is the only item changed to change baud rate. Most new UARTs operate to at least 115.2 kbaud.

For example an 11.0592 mHz clock divided by 6 = 1.8432 mHz. Dividing 1.8432 by 16 = 0.1152 mHz or 115.2 kbaud. Dividing by 18 instead of 6 produces 38.4 kbaud.

Even though you can set and operate a UART at 115.2 kbaud does not mean that actual thruput will equal the theoretical maximum. This can be greatly influenced by Windows problems as interrelated with the application software.

.

lapuser,

Look at this thread on this form, it talks about a free transfer program you can download:

http://cnczone.com/forums/showthread.php?t=939&highlight=scomm

plm

050727-1518 EST USA

If we exclude the 115.2 category, then the distribution curve is looking more like I would expect. Why are there so many at 115.2? Maybe because it is useful and HAAS provides this capability.

I would like some thruput experiments to see how different systems are working.

The experiment is from computer to CNC. Measure the time to send a file from a computer to a CNC. The file size should be such that transfer time is a minimum of 10 seconds. For 115.2 this is about 100,000 bytes, 38.4 about 40,000, 19.2 about 20,000, 9600 about 10,000, 4800 about 5000, and 2400 about 2500.

To calculate thruput divide NUMBER OF BYTES SENT by TIME in seconds. When responding indicate baud rate, thruput, data bits, parity, stop bits.

HAAS will cause some loss of thruput but not much, software at the computer some times causes a major loss.

Depending upon how Windows is operating, CPU load and number of programs open, can cause some very severe loss of thruput. This might require larger files than above to observe the effect.

.

As far as I know 9600 is the fastest I can go on my 94 Fadal withh 88HS control.
I have to be carefull with my 3D programming if I get a lot of really short moves the machine goes into slow motion waiting for my DNC code.

050909-0854 EST USA

DareBee:

If you are truely limited to 9600, then there are little tricks that may gain a small increase in thruput. But, first check with Fadal and see if this is truely the maximum, or maybe there is an update, or modification for higher baud rate.

Any recently manufactured UARTs (universal asynchronous receiver transmitter) should be able to operate much higher than 9600 baud. Thus, any limitation should be a software problem only.

You may already know these little tricks:
1. Use 7 data bits if possible.
2. Use 1 stop bit.
3. Do not use line numbers, except on lines that require them.
4. If possible eliminate spaces, and other non-printing characters.
5. Eliminate CR and LF, either or both, if possible.
6. Change from floating point representation to fixed point if small increments are represented as few digits.
7. Do anything that you can to reduce the number of characters sent.
8. DO NOT eliminate parity. It is better to have the machine stop on a parity error than to have a machine crash.

.

Thanks
Modification means a new or newer version of my control.
I am already doing 7 of 8 of the suggestions and don't know what #5 is so maybe I am doing 8 of 8 ;-)

050912-1316 EST USA

DareBee:

My comment #5 means this:

If you have a line of code like

G0 X 0.000 Y -1.050 change it to

G0Y-1050

Eliminate the blank spaces. The blank spaces could be the "space" or "tab" characters as well as others.

This won't save you much.

To keep your machine from jerking you can slow the feed rate in the region of short strokes.

If CR and LF are both sent from your computer, then determine which is used by the CNC as end of block. Then find software that will allow you to specify the end of line character. If your CNC requires ; for end of block, then eliminate both CR and LF.

If you could find someone to disassemble your CNC internal program, then they could change the bit pattern for initializing the UART and map this to an used by you baud rate selection. For example 300 baud selection could actually select 38.4 kbaud.

(edit) Looks like I was answering #4.

I have said something on #5, but here is more.

CR stands for the carriage return character, and LF stands for line feed character.

In the typewriter days the carriage lever did both CR and LF unless you only lightly pulled it. The Teletype introduced separate codes (characters) for these two functions. This has carried over into the computer field and the ASCII alphabet.

Some CNCs may be satisified with only a ; to separate records ( NC blocks ). In this case you can eliminate the CR and LF, but that is not easily worked with in a word processor.

(end edit)

.

050918-1549 EST USA

The distribution curve is get more interesting.

For those that are operating at different baud rates because of different machine limits enter in more than one category.

We operate at 115.2, and 38.4. These are the max rates for the machines. If the machines would operate at 230.4 we would use that speed.

Since we have a moderate number of entries I am going to add our values because these will not have a major effect on the distribution, but will illustrate a double entry.

(edit) This idea of multiple votes won't work. Normally this might be a good restriction, but it is not satisfactory for my objective. Since the identity of voters is provided it would be possible detect a bias from multiple votes. But also if you are restricted from voting more than once in a category that would be ok. (end edit)

.

I run my Haas at 115.2. I measured the file transfer rate roughly empirically, how big a file size in how much time. It was a long time ago, but I seem to be getting around 90 on average. I think about a minute and a half to transfer a 1Mb file. Using DC codes, 7+1, even IIRC. Have SE DNC to transfer data, which is very reliable. My cable is only around 5 feet though, I have a dedicated server (old win 98 machine) next to the machine networked to my main computer. Formerly I had about a 40 foot cable, no problem either.

I run a lot in DNC, as I have a lot of work that is bigger than the 1Mb memory. DNC runs a lot slower (like about 10% of max) if you just let it trickle into the machine without running. I have never run out of code though, it seems the Haas picks up receiving speed when it's running eating through the buffer faster, it pulls in the code as fast as it needs it... --ch

051004-1853 EST USA
chmillman:

Your figures are about as I would expect for effective thruput.

However, 40 ft at 115.2 kbaud seems long unless you had extremely low capacitance cable .

HAAS has a very good system for DNC (drip feed). In a HAAS control a large percentage of the unused CNC program memory space is used to buffer incoming DNC data. Thus, when you start drip feeding the RS232 data flows in very fast until the available buffer memory is full, then the flow rate is determined by the average demand of the CNC machine.

I believe many Fanuc machines have a very small buffer so that you must disable the UART FIFO in your computer to prevent overruning the Fanuc control.

.

Gar:

"However, 40 ft at 115.2 kbaud seems long unless you had extremely low capacitance cable"

I made my own out of the best shielded material I could find... Seemed to work...

"HAAS has a very good system for DNC (drip feed). In a HAAS control a large percentage of the unused CNC program memory space is used to buffer incoming DNC data. Thus, when you start drip feeding the RS232 data flows in very fast until the available buffer memory is full, then the flow rate is determined by the average demand of the CNC machine."

I keep my machine memory virtually empty for that reason. I don't do repeat programs very often. But, as I explained before, the download speed for the same file in Recv232 mode and in DMC mode is very different (assuming I don't run the machine in DNC, just let it download). In DNC mode, the download speed is around 10% of the Recv232 speed. But if you run the machine, the download speed in DNC picks up as a function of how fast the machnie is consuming code. So there's some internal function managing this... As I said, I've never been able to run the buffer dry. --ch

We use several different baudrates on Haas controls, depending on the CNC model and on the customer's needs. We install a lot of DNC systems, and we've found that there's really no benefit to using the maximum baudrate unless the customer has some performance issues to deal with.

If you're uploading or downloading very large files on a regular bassis, it's worth the time to experiment and find the highest baudrate that the CNC can handle. Most of the time, you'll find that the control's internal software has a much lower limit than the maximum available baudrate. There's no point to setting the baudrate at 115k-baud if the CNCs software can only process data at a fraction of that speed.

XMODEM protocol is fine for insuring data integrity, but it can also mask the more serious problems of cable capacitance, noise, poor connections, etc. With XMODEM, you may not realize that you have another problem, like bad crimp connections, oil in the connectors, wrong type of wire, etc.

We've found that about 90% of our customers only upload/download files of modest size, and saving a fraction of a second per download just isn't worth the trouble. For them, we just use 9600 or 19,200 baud depending on the cable length.

gar is correct when he says that the cable capacitance becomes a big problem as the cable gets longer. We like to use the lowest capacitance double-shielded cable we can find when we wire a shop. The best cable we've found is from Black Box Corporation. The BB catalog number for a 500 foot spool is EMN07A-500, and it has a capacitance of only 12pf/ft. It also has both foil and braided shielding for maximum noise resistance at all frequencies.

Probably the best way to connect a machine that can use high RS232 baudrates is to install a 1-port Ethernet serial hub like the Quatech SSE-100D on the machine, then run a very short serial cable between the hub and the control. That way, you've got Ethernet speeds with TCP/IP between your DNC system and the hub, and you can run those high baudrates more reliably with a 3 or 6 foot serial cable. The Ethernet connection has common-mode rejection for noise, and it also isolates the ground on the CNC from the DNC system. The only downside to using the Ethernet hub is the added cost, but you make up for part of that added cost by being able to run much cheaper CAT5 or CAT5E cable to the machine instead of shielded data cable.

051120-0843 EST USA

The peak of the distribution curve is at 9600 baud and this corresponds with qualitative answers I get from asking servicemen obout the most used baud rate.

At 9600 baud and a 10 bit serial word the maximum transfer rate is 960 characters per second. The approximate times to send the following file sizes are:
1000 bytes ---------- 1 sec
10,000 bytes -------- 10 sec ---- 1/6 min
100,000 bytes ------- 100 sec ---1.67 min
1,000,000 bytes ----- 1000 sec --16.7 min

At 115.2 kbaud the times are divided by 12. So to transfer 1 mega-byte the time is 1.4 minutes. Typical efficiency at 115.2 kbaud is about 80 to 90 %.

The size of files is very much application dependent.

In the mold or contour business the sizes may typically be in the range of 1 to 100 mega-bytes. In many case this will force the use of drip feeding. Averaged over an entire file the average baud rate required may be very small, possibly 100 baud. But the instantaneous rate needed may be above 38.4 kbaud to prevent machine starvation during short strokes. Buffer size in the CNC in combination with baud rate and program requirements will determine whether stravation occurs.

One of our mold customers had a machine limited to 9600 baud. This machine would stutter because of starvation, and also there were data noise problems that caused program failure. This customer had the machine modified to operate at 38.4 kbaud and also added our I232 High Baud Rate Long Cable System and this eliminated both the noise problem and the starvation. Cable was about 125 ft.

In some very simple drilling or milling operations program files sizes may be in the 1 to 10 k range. If programs are never more complex than this, then high baud rate is not needed.

In a job shop application there will be much more variability in file size. A sampling of file sizes my son runs are:

less than 10k ------- 42.7%
10 k to 29.9 k ------ 21.6 %
30.0 K TO 99.9 K --- 17.1 %
100 K TO 299 K ----- 9.0 %
300 k to 999 k ------ 7.7%
1 meg to 2.99 meg -- 1.4 %
over 3.00 meg ------ 0.5 %


All of our I232 customers have been elated with using higher baud rates than they previously used.

.

Hello,

I realize that this thread may be toast since it has not had a post this year, but I am new to the board, so I thought I'd throw this in. I run at 19.2K on my 1995 Haas VF-2. it is connected via shielded rs232 cable to a dos PC running Procomm. The cable legnth is probably 25', although the machine is only about 10' away. I just coiled up the extra, and since it worked I never bothered with buying a shorter cable. My complete settings are:

19.2K Even 1 Xon/Xoff 7

I just started looking into this, because I am contemplationg replacement of the DOS PC with a new one at some point. I would then need a Windows based DNC program. I am open to suggestions there.

We actually have two Haas machines, each with it's own PC, and I think the settings are the same on both. We occasionally get an error when starting a transfer, but a retry usually fixes it. It happens proably once a month, and I don't even remember the error. Maybe something about parity?

One problem that I do know is consistent, is that on our VF-6, if I am DNCing a program and the spindle speed is hi ( 4000 rpm) then I will almost certianly get an error. My guess is noise from the spindle drive. For this reason, I don't DNC much on the VF-6, just transfer and then run if the files are too big for a floppy. We have 4 MB of memory. I have not looked at it in a while, but I suppose slowing the baud rate might help, but starvation is always an issue that I want to avoid.

We are a Pattern Shop, I use PowerSHAPE and PowerMILL from Delcam, we have a VF-2, VF-6, and an older Sharnoa SVC-36. The sharnoa has a 200 MB HDD, and is PC based, so I just use the network to grab files and put them on the HDD.

Sorry for such a long post, Thanks for the forum. I see myself learning a lot here.

Steve

060407-1450 EST USA

Stevenlpkr:

Some time prior to June of 1996 HAAS added 115.2 kbaud to their available settings. Prior to this from at least 1993 the maximum was 38.4 kbaud. Many other brands have lower maximum rates.

The higher the baud rate the faster you can transfer files. At 115.2 kbaud it is about 600,000 bytes per minute.

The distribution curve shows that most people use 9600 baud. Most likely because someone suggested this and the user did not look into the subject further.

Our I232 and E232 systems provide high baud rate capability, electrical isolation for noise reduction and protection of equipment, and long cable length. See our web site www.beta-a2.com .

Our customers have virtually no communication errors with our isolators, and some of these customers were never able to drip feed previous to using our I232 because of electrical noise from the brushless servos. This is appearing to be a somewhat common problem on HAAS.

Lower baud rates do not necessarily reduce errors unless you add filtering at the receiving end.

Sources of software for Windows machines:

See Dan Fritz, Suburban Machinery Software, Inc., above on page #37. Click on Dan Fritz, then on his home page. Which is www.sub-soft.com . You are currently on page #40.

See also www.cimco-software.com CIMCO Edit 5.

.


.

050620-2034 EST USA

What baud rate do you use? and why?
9600 due to the distance of my computer from the machine. If over 50ft then you can't run over 9600 without have communication problems.

060528-2058 EST USA

tetrault:

If you go to low capacitance cable you can operate at higher rate at 50 ft, or you can go a longer distance at 9600 baud. But in all cases direct connection of RS232 ports has substantial potential for noise errors or equipment damage from electrical faults.

For more information see my site www.beta-a2.com .

.

I am not currently using any Rs 232, cuz I am having some trouble finding the cause of alarm086. My partner and I think weve got the right pin config, but someone he spoke with seems to think the alarm has something to do with signal strength. Interestingly we get the same alarm with no cable attached. So anyone out there have pin configs for this old machine? Or any idea what this alarm may be? I believe we are running system 11 version9 Fanuc 6M.

Also I read somewhere that Dan Fritz sells and sets up drip feed systems for these controls. Just what is drip feeding? and what are the advantages?
Dan?

Thanks in advance, for any help I may recieve. I'm an experienced machinist, but have never had to set this type of thing up before. With a new company, theres alot of things I'm doing that I havent done before......

We use 4800 because we transmite 200+ yards

. So anyone out there have pin configs for this old machine? ...system 11 version9 Fanuc 6M.
Just what is drip feeding? and what are the advantages?

versa1 drip feed refeers to a program sent to the controller thought DNC (direct NC)software. It use when program are to large for controller to handle.It's send the code in stages as the manchine controller buffer excutes the program more code is send to buffer.Also attached is a file from Bobcad website on RS-232 and pin-out. Rember that you need to have your cable coming from Comm. port 1 it the 9 pin rs-232 not the printer port on back of pc.Hope this help you

060807-0921 EST USA

versa1:

The following is for software handshake (XON/XOFF):

Assuming you have a 25 pin female D connector on your CNC, and a 9 pin male D connector on the computer, then try the following cable wiring:

The colors are for Belden 8723 cable. This cable has two independent twisted pairs individually shielded, and a drain wire. It is a fairly common wire, but about 60 - 70 pfd /foot, vs 15 pfd/ft for a low capacitance cable.


******* Your cable will have a 25 pin male D connector at the CNC wired as follows:

Pin ....... function ........ description and a possible color

1 ......... shield ............ machine chassis, no insulation. Connect the shield only at this end. Also maybe called drain wire.

2 ......... TxD .... data transmit ..... green ..... connects to RxD (pin 2) at computer
3 ......... RxD .... data receive ...... red ......... connects to TxD (pin 3) at computer
7 ......... common ........ black, white, connects to common (pin 5) at CNC. Common reference for all signals.

Jumper the two following pins together and nowhere else.
4 ......... RTS (output)
5 ......... CTS (input)

The CNC when in receive mode will force RTS high forcing CTS high which apparently Fanuc requires even in software handshake.

Jumper the three following pins together and nowhere else.
20 ....... DTR (output)
6 ......... DSR (input)
8 ......... CD (input)

Again when everything is ready to receive, then DTR will be high, and this forces DSR and CD high.


******* Your cable will have a 9 pin female D connector at the Computer wired as follows:

Pin ....... function ........ description and a possible color

none...... shield ............ no connection at this end.

2 ......... RxD .... data receive ...... green ..... connects to TxD (pin 2) at CNC
3 ......... TxD .... data transmit...... red ........ connects to RxD (pin 3) at CNC
5 ......... common ........ black, white ...... connects to common (pin 7) at CNC. Common reference for all signals.

Jumper the two following pins together and nowhere else. Most computers and their software will not require these to be connected in software handshake mode. But connect them anyway.

8 ......... RTS (output)
7 ......... CTS (input)

If the softwares requires CTS to be high, then RTS must be forced high to get CTS high or some other source is required. But generally at the computer end CTS is ignored in XON/XOFF mode.


Your cable only uses three wires for data transfer in software handshake mode.

Your maximum baud rate is determined by baud rate, cable length, cable capacitance, and driver impedance; or is limited by the CNC.

visit our web site www.beta-a2.com . Here I discuss the potential problems of this type of direct connection of one RS232 port to another one.

.

060807-1035 EST USA

ajl6549:

If you would benefit from a higher baud rate, lower error rate, and equipment protection, or even longer cable lengths, then look at our I232 System at www.beta-a2.com .

.

Than You very much! I will look into that. As we are still working on this.

Listening to you guys sure makes me appreciate that my machine is connected to my LAN so all I have to do is copy whatever I want to machine over to the correct directory and when I go to the CNC, it is all there...

Larry

I'm @ 19.2...ever since i lost data at higher baud and sent a 2.5in shell mill through my vice....the sandvic held up quite well and what a light show it made!

060906-0811 EST USA

SmokeBanshee:

Do you have PARITY enabled for serial communication (mostly EVEN is used), and what is your cable length? At what baud rate did your failure occur?

When you send a file to the CNC do you first run in graphics mode to check the program?
Do you ever send the file back from the CNC to the PC and do a file comparison at the PC before running the part? Obviously this can not be done in drip mode.

.

I have built an ethernet adapter for our Haas Lathe using an industrial RS-232 converter with galvanic isolation and transient protection (westermo ED-10) we are using it with xmodem protocol and it works great. So far I've only tested at 9600 baud just because that was what the machine has always been set at.

If anyone's interested, the PC software will be posted on the internet just as soon as I've written a help file for it.

Andy

I use 9600 on my HAAS mini mill using BOBCAM so send DNC. this is as fast as I can transfer and get good integrity. It works ok as the machine cannot process the program as fast as it is received. I'm not sure if it is BOBCAM's fault or the USB to serial cable I am forced to use (no serial port on comp), but the longer the program the greater chance of errors. the big problem is I cannot do any work with the computer during transfer as any program, even a screensaver, will cause the transfer to crash.

061207-1941 EST USA

bishb25:

On older HAAS machines, before about 1996, the maximum baud rate is 38.4 kbaud, after that the mximum is 115.2 kbaud.

Your problem is most like with the PC software or the USB to RS232.

However, provide more information on your settings at both the PC and HAAS. I would suggest 7 data bits, 1 stop bit, EVEN parity, and software handshake. These settings must be the same at both ends, HAAS and the PC.

Even without handshake I have transferred files of 150,000 bytes to HAAS at 115.2 kbaud without error. This is many times for many millions of bytes. I suspect you need about 300,000 bytes of free space on HAAS to do this (this is conjecture). With handshake you can accomplish this with about 150,000 bytes of free space.

What is your definition of DNC? Is it Direct Numerical Control, which is HAAS's definition, and my preferred definition, or is it Distributed Numerical Control which is basically file transfer into or from HAAS program memory storage accomplished with SEND or RECV?

Crashing of the data transfer when you try to run some other program on the PC is probably PC software or USB driver problems.

Is your computer a laptop or desktop? In either case you can get RS232 boards that connect into the PC bus rather than use a USB adapter.

.

I bought a USB to serial adapter to try it - and it is rubbish! Windows won't even start when it is plugged in, have to uplug it, start computer, then plug it in. Piece of junk.

I now much prefer to use network/serial adapters because you don't need 3rd party drivers if your file transfer software talks to TCP sockets - I just borrowed a UDS1100 from a Lantonix rep last week to do some testing. First impressions are that it works great, starts/stops properly with hardware handshaking pausing the TCP connection without lost data.

Like gar has already said, throw your USB adapter in the bin:)

GAR,
My mini mill is a newer model (2003 or 04) I use the same settings you list. When I say DNC I mean Direct Numeric Control. I'm "drip feeding" the program to the HAAS control from my company's Dell Insperion 1300 laptop. My USB>serial adapter cable is 3ft long and my serial cable is 10ft.
BOBCAM'S program editor stinks for DNC. I down loaded a trial copy of "easyDNC XP" and used it for the last DNC job I did and it Works Great! It sent in 20 min's without error a program that BOBCAM takes 2hrs to send at the same Baud and it will often send horrific errors. However, I still can't break the 9600 threashold.
The Software Tech at my HFO reccomends a prog from WWW.DNCsoftware.com, but I couldn't get the trial software in time to properly test it. He has also used similar USB adapter cables on laptops and says I should be able to get better results than I have been getting.

Andycarter,
Have you installed the driver software for the adapter? I had the same problem until I got the correct drivers installed.

The Software Tech at my HFO reccomends a prog from WWW.DNCsoftware.com,

I've used the older version (SE DNC) for years and can highly recommend it if you just have a single machine. I have never had it fail and it is very easy to set up and use. I run at 115k in both download and DNC to my 1999 VF0-E, feeding multimegabyte nc files for 3D surfacing.

I didn't know he brought out a new version, have to see if I can upgrade. --ch

050622-1459 EST USA

Where are all the 9600 users. Our HAAS serviceman said the majority of his contacts operate at 9600. He indicates considerably more than half are at 9600, and extremely few at 115.2 k.

So far we are top heavy at 115.2 k, but a very limited sample.

Check more than one baud rate if you operate at different rates.

.

the haas manual (i believe) recommends a slower baud rate then you can actually use. we used to run at 9600, but now running at the top speed and i have no problems with it

070615-1656 EST USA

I have combined the results of this poll, as of several days ago, with the similar poll under POLLS. These two graphs are shown together and some comments at my web site
www.beta-a2.com
on the Baud Rate Useage Poll page.

It is surprising there is not more difference.

.

If anyone's interested, the PC software will be posted on the internet just as soon as I've written a help file for it.

As promised, here it is: http://www.iworkshop.co.uk

Andy

I`ve used a baud rate of 4800 E-7-1 and have had no problems uploading or downloading to the haas ,the machine is old though.
And as far as the machine limits on x y axis, the ones we have are mechanical,we have had them changed due to the wires and conduits becoming hard and brittle due to age and have had no problems since.

070630-1650 EST USA

GASPER:

Why have you not tried working at higher baud rates than 4800? How long is your cable? How large are your largest files? How small the smallest?

Old age is not the reason your cables fail, but rather the choice of insulating material by HAAS and that the insulation is probably soaked in coolant for the X-axis. PVC insulation is make flexible by the addition of plasticizers, and the coolant leaches these out of the PVC over time. In some cases in as little as 6 months with hydraulic oil.

.

I have tried higher baud rates but the machine is ancient and is far more stable at 4800,and you are right about the cables but everything deteriorates with age:)
the new m/cs run at 19200 and the difference is only a few seconds on download

070731-0645 EST USA

GASPER:

The data transfer rate is approxoimately 500 bytes/sec @ 4800 baud, 1000 @ 9600, 2000 @ 19.2 k, 4000 @ 38.4 k, and 12,000 @ 115.2 k.

2 seconds for a 1000 byte file, and 2000 seconds (33 minutes) for a 1 meg file at 4800 baud.
0.1 second for 1000 bytes, and 83 seconds (1.4 minutes) for 1 meg at 115.2 kbaud.

Obviously you are dealing with small files if you are dealing with only a few seconds difference between different baud rates.

On your old HAAS are you using handshaking? How old is the machine? With an appropriate cable length you can get reliable data transfer (zero errors) at HAAS's maximum baud rate.

On a 1993 HAAS with a maximum baud rate of 38.4 kbaud you should probably work reliably at that rate with up to 20 ft of Belden 8723 cable. Of course with either hardware or software handshake active. Your RS232 cable length is roughly inversely proportional to baud rate for a given type cable. There are lower capacitance cables than 8723 and these will allow a longer length at a specific baud rate.

.

Gar,
I agree with your basic facts and informative as always.

I am moving data at 115.2 on rs232, around 15 feet of belden shielded cable. I also dnc 8-10meg of data with no bproblem at all on a Dell workstaion to a 08 hass vf3.

080425-0802 EST USA

DRD:

What is the Belden wire number, and the capacitance per foot?

.

115.2K...Because I can! Thanks to Betatronics and Gordon (Shameless Plug;)

RCA