TM-1 rs232 communications

Anybody using simple hyperterminal or procomm to do rs232 communications with a Haas TM-1? If so got any settings?

Thanks,
Eric

Cable length and capacitance determines baud rate up to the maximum of the computer and CNC. Newer HAAS machines, after somewhere between 96 and 98, have 115.2 kbaud capability. With Belden 8723 stay under 6 ft at 115.2, with CAT-5E this is probably 25 ft.

Use EVEN parity, 7 data bits, 1 stop bit.

Software handshake only requires 3 wires. At HAAS 4 and 5 do not need to be jumpered. And 6, 8, 20 are don't care. Pin 1 is shield if you use it. Might be good to jumper pin 1 to 7. Pin 7 is signal common between CNC and computer. On Fanuc 4 and 5 have to be jumpered, and separately 6, 8, 20.

Probably avoid Procomm, and HyperTerminal is not easy to use.

With software handshake mode you only need TxD, RxD, and Sig common to communicate.

I have customers that had problems with Procomm. I do not like HyperTerminal but I have sent error free data at 115.2 kbaud. If you want to use Xmodem the settings are slightly different and I suggest Cimco DNC MAX. For software handshake and one machine CIMCO Edit 5 is simpler, but it lacks Xmodem capability. Do not use HyperTerminal for Xmodem.

Ground path noise can be a problem.

For high baud rate, long cable length, and a ground path noise solution see my Web site and our RS232 to RS232 I232 Isolation system
www.beta-a2.com

.

Gar has the parity, data and stop settings I use. I use NClite with my '02 TM1. It is free, only supports up to 9600 baud rate in the free version though, and no drip feed mode with the free version. Does anyone else know of a better freebie transfer program? How about one that will support drip feed DNC?

1 MB of memory goes pretty quick when doing 3d profiling.

RDesign:

If you can not DNC (drip feed) with NClite, then that means there is no hardware or software handshake capability. Is that the case?

HyperTerminal provides either hardware or software handshake, and Xmodem. As previously mentioned HyperTerminal Xmodem is inefficient.

.

http://www.cadem.com/dnc/choose-dnc.htm

The free version does not support drip feed machining.

I am pretty cheap. My 1mb memory equates to right around 100,000 lines of code typically. I have had to break up operations on some parts, for instance, load and run roughing operations, clear the program from the machine memory, load and run finishing. The transfer can take 45-50 minutes for a 80-90,000 line program. I work on other things for that time, there seems to always be cleaning to do.

080425-1243 EST USA

RDesign:

Try using HyperTerminal. What is your cable length? What is the cable capacitance per foot?

45 to 50 minutes does not equate to 1,000,000 bytes at 9600 baud. The theoretical maximums are:

At 9600 baud 960 bytes per second or about 1041 seconds to transfer 1 meg of data. 1041 seconds is about 17.4 minutes.

At 115.2 kbaud transfer should be about 87 seconds or 1.45 minutes for 1 meg.

The ratio of 115.2/0.96 = 12. 12*1.45 = 17.4 as it should.

.

I think I have 25' of cable, one I bought through CDW. I don't know what the capacitance of the cable is, would a measurement using my multimeter be meaningfull?

Now I am curious because I do not have a precise measurement of transfer time but I know it was considerably longer than 17 minutes.

Can hyperterminal be used to perform drip feed machining?

RDesign:

If there is a Belden part number on the cable, then from that I could find cable capacitance. I do not think you will find any cable less than about 15 pfd/ft, and some, such as Belden 8723, may be about 70 pfd/ft. If you measured from any one wire to shield with your meter, then you can get an estimate.

25ft of 70pfd/ft should not be a problem at 9600 baud, but will most certainly be trouble at 115.2 kbaud.

Our I232 Isolator system could solve any cable length and speed problem you might have. We can go 4000 ft at 115.2 kbaud.

See www.beta-a2.com

Yes, HyperTerminal can operate in software or hardware handshake mode and thus be used for "drip feeding". However, I much prefer Cimco software at
www.cimcosoftware.com

.

There are no markings anywhere on the cable. APC is molded into one side of the connector and 2040 is molded on the other side of the 9-pin end , 2070 on the 25 pin connector.

I am going to try a transfer test right now...
NCLite 4.0, parameters:
9600 Baud, Even, 7, 1

Send: 235585 bytes
4:06 transfer time to TM1.

Recieve: same file, same parameters.
4:29 recieve time, difference from walking to machine and hitting send after already setting PC end to recieve.

That is faster than I though it was. I was wrong in stating 45-50 minutes at 9600 baud. I had it set slower originally and I must have confused the two.

I was trying hyperterminal just for fun and I can not get it to send a file. Any tips?

I was trying 115200 baud, 7, even, 1, Xon/Xoff.
Emulation is set for auto detect, I also tried ANSI
There are input translation options that mean nothing to me and ASCII settings that I don't know how to use.
I made sure the 115200, 7, even, 1 and Xon/Xoff was also set in the TM1 settings.

A USB port sure would be nice on this machine right about now...

I can receive a file with hyperterminal, I guess.. I can highlight it, CNTRL-C and CNTRL-V into notepad or a G-code editor. What a pain. Is it possible to save it as a .txt file directly? When I hit receive in hyperterminal it tries to establish communication it looks like about 10 times really fast, then does nothing. When I hit send on the mill the text is transferred but just to a display window not to a file.

RDesign said:

I made sure the 115200, 7, even, 1 and Xon/Xoff was also set in the TM1 settings.

Click to expand...

Not all UARTs will support 115,200 baud. This is called "isochronous" mode, and it did not exist when earlier UARTs were designed. The UART is the integrated circuit inside each device that actually talks to the RS-232 line.

If both devices will support this data rate, there are environmental problems such as electrical noise and cable capacitance which can degrade the data to the point that you do not have a reliable connection.

Try 19,200 baud and see if the two devices will communicate. Preferred options would be no parity, two stop bits, and no flow control (XON/XOFF or RTS/CTS), if both ends will support this.

- Leigh

Leigh:

The 16550 and derivatives will hande 115.2 kbaud async and this has been around since the late 80s I believe.

Why not software handshake and/or parity?

I do all my testing at 115.2 with 7E1 and XONOFF. With one bit parity error checking and the normally low error rates you can be quite sure the received data is correct.

A bigger problem with some machines, not HAAS, is loss of whole characters and this is not a communication problem that encompasses the UARTs.

Xmodem could possibly solve the character loss problem depending upon where the loss occurs. I believe the machines with this problem lack Xmodem capability.

.

gar said:

The 16550 and derivatives will hande 115.2 kbaud async and this has been around since the late 80s I believe.

Click to expand...

Yes, I remember when it and its 16450 predecessor came out. Great improvements over the 8251A. Since I don't know the age of the machine involved (people are always talking about paper tape), it was one possible cause of the problem.

gar said:

Why not software handshake and/or parity?

Click to expand...

The first step in any troubleshooting effort is to eliminate as many variables as possible. The XON/XOFF handshaking is a whole program interposed in the data stream. It adds a level of complexity without advancing the diagnostic effort one millimeter.

Parity is an error detection mechanism. But what if there are errors on the line? Does your receiving software report that, or simply throw away the entire byte? This is what we're trying to determine. You can't diagnose the error environment if you throw away to evidence.

gar said:

I do all my testing at 115.2 with 7E1 and XONOFF. With one bit parity error checking and the normally low error rates you can be quite sure the received data is correct.

Click to expand...

Then you're not doing testing, you're doing system integrity verification.

You don't find errors by masking them. The purpose of testing is to find errors, analyze them, and eliminate the cause.

gar said:

A bigger problem with some machines, not HAAS, is loss of whole characters and this is not a communication problem that encompasses the UARTs.

Click to expand...

Interesting statement, although totally invalid.

Loss of entire bytes is THE classic symptom of parity errors. This is a very common occurrence in industrial environments with high levels of electrical noise.

The problem is totally internal to the UART. When the error is detected, the UART sets an error flag and generates an interrupt to the CPU. Handling of parity errors is controlled by the microprocessor, but all it can do is note that an error occurred. Usually it just resets the error flag in the UART. The data byte cannot be recovered because there's no way to know which bits are wrong.

This problem can be exacerbated by using one stop bit. Incorrect sampling can cause loss of byte-boundary synchronism which can cause framing errors on successive bytes. The errors will continue until the line goes idle or synchronism is regained by chance. Use of two stop bits reduces the problem by adding an extra bit time for synchronism to be established between bytes.

The UART receiver ALWAYS requires one stop bit; the option only controls the number of stop bits transmitted.

Data transfer protocols such as XModem generally can't correct missing bytes. There are some error detection and correction schemes which have this capability, using longitudinal and cyclic redundancy checking, but there's a huge overhead associated therewith.

- Leigh

080507-1100 EST USA

Leigh:

This thread is related to HAAS machines and there are others that operate in a very similar fashion.

At the CNC machine on a parity error the transfer is aborted and flagged as a parity error. What I dislike about the HAAS system is that everything up to that point is erased or not available.

Therefore, loss of a character is not a parity error problem in HAAS.

I will admit that running without parity and handshake at times is useful for troubleshooting. In most cases it is not necessary to go to this state.

If I run with parity and there are no data errors then my inserted equipment is working correctly. When we do the test the data is sent to the CNC and then sent back to the computer and a file comparison is made. This is a final test in an operational environment. This test is not used to find the cause of a problem.

It is true that with single bit parity checking that no correction is possible. But in CNC communication the assumption is made that the bit error rate is very low and thus an open loop system with parity check can can provide very reliable operation. If you do not have low error rates, then you solve the problem with some sort of isolation such as our I232 System.

In the drip mode of operation there is an advantage to using Xmodem because the rare occurance of a bit error can be automatically corrected, and a lights out operation gets the job done when expected.

I have a customer that makes molds and these may take 3 days or 72 hours of continuous operation. With our system in 7E1 XONOFF they will run this full program without error.

Xmodem will correct missing data in the sense that the bad packet is rejected and a repeat transmission is requested. After too many retries transmission is terminated halting the whole operation. Of the data actually received into the destination memory there are no errors.

With HAAS machines we are talking about 1990 and later.

Getting people to play with parameter settings gets quite confusing and if you can use settings that are known to work, then it reduces the problems talking with someone in the troubleshooting process. Also if you use a program that is known to work under certain conditions, then progress is quicker.

In other places I have provided information on using HyperTerminal and other techniques.

.

gar said:

I have a customer that makes molds and these may take 3 days or 72 hours of continuous operation. With our system in 7E1 XONOFF they will run this full program without error.

Click to expand...

WOW. 72 hours without an error at 115,200. That's some fancy stuff.

You obviously grew up in a Micro$oft environment.

The system I designed for IBM ran for twelve years without an error, 4,000 users 24/7 on multiple T-3 lines (45 Megabit data rate).

The equipment I designed for Lucent's 10 Gigabit Ethernet switches had error rates of less than one bit in 10e13.

But I don't have any experience with real high-rel stuff.

- Leigh

Leigh:

Average data rate is nothing like 115.2 kbaud for a mold in drip feed mode. This high baud rate is needed to prevent starvation of the machine on many short strokes when doing finish cuts in curved areas. Probably most files are less than 10^9 bits.

Most CNC manufacturers do not give any consideration to error detection and correction. HAAS does provide the Xmodem capability. However, this uses only a simple checksum test and specifically excludes a parity check per byte.

The Xmodem check probably only goes to the first buffer in HAAS. From here HAAS does some modification of the data before putting it in the working program memory. So there are internal error possibilities that are not checked.

The following are likely causes in the majority of cases where people have trouble making RS232 communication work:

Incorrect cable wiring.

Handshake signal wiring.

Ground path noise.

Understanding the communication program.

Getting parameters set correctly. One manufacturer has the CNC set to 8N1 while the computer is set 7E1. This obviously means they process the parity check someplace beyond the UART.

Understanding the program format and CNC response to this format.
For example: The first % starts the processing of the CNC code into the CNC memory and the second % terminates the loading operation. There is usually a message at the CNC indicating that loading has started.

In the case of Fanuc controls it is almost mandatory that handshake be enabled, and that the UART FIFOs be turned off at the computer end because Fanuc has an excessively short input buffer. The simplest approach here is XONOFF and three wires plus some hardware handshake signals jumpered.

The biggest problem is communication with persons that have few tools for working with RS232 connectors, cables, and practically no test equipment. So 7E1 9600 baud and XONOFF is a good base starting setup to work from. I have seen no need for 2 stop bits for either troubleshooting or transferring data.

Even though HyperTerminal is not easy to work with it is no cost on Windows systems, will receive and send data without any concern for format, and has no timeouts. On a moderately new computer with XP Pro I believe HyperTerminal will receive at 115.2 kbaud without sending any Xoff signals.

We are dealing with a high signal to noise ratio, and if it isn't, then that needs to be solved first. Since most CNC communication is open loop one has to have a high signal to noise ratio. Even if the manufacturers chose to used error detection and correction there is a noise level at which failure will occur.

.