What RS232 baud rate do you use? and why?

[gar]

050620-2034 EST USA

What baud rate do you use? and why?

[psychomill]

Speed of loading......

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.

[gar]

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.

.

[ghyman]

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.

[miljnor]

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)

[SLOWJOE]

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

[pmurray]

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.

[miljnor]

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

[SLOWJOE]

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

[gar]

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.

.

[gar]

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.

.

[pmurray]

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