Troubleshooting RS232 Communications

  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.
  • : Function ereg() is deprecated in /services16/webpages/util/j/a/jamessmith.site.aplus.net/public/includes/file.inc on line 646.

 

Please note that CNC Innovations is happy to assist customers with questions about configuring and using our Focal*Point DNC or Easytalk Shell software. However, we can not offer free assistance for configuring or using your machine control. In most cases, extended technical support or on-site service may be purchased to address these issues.

 

Preparatory Note - For extended troubleshooting it is advisable to run Focal*Point or Easytalk from a laptop computer situated near the machine control as this will save time spent accessing a remote DNC host.  Keep in mind that both Focal*Point and Easytalk provide a free 10-Day trial when installed on a new PC.

If troubleshooting involves diagnosing serial port hardware, see Loop-Back testing described below.

Always start troubleshooting by sending from the machine control to Focal*Point or Easytalk.  The DNC software is much more flexible in how it receives data and will not issue Alarms and halt transfer as machine controls will do.  Furthermore, the nature of the data received may help you identify the source of the problem.

 

Troubleshooting Steps

 

1. Send a program from the machine control to the PC.

 

If the machine "Alarms":

The cable may not be connected to the correct port at the machine control. Check the cable configuration at the machine end, particularly pins 6, 8, and 20. 

 

If the machine acts like it is prepared to send but "sits" continuously in send mode:

A file will not be sent if the CTS line (pin 4 or 5 depending on the machine configuration) is not asserted. The cable should have a jumper between pins 4 and 5, or they should pass through to their compliment lines on the computer end.

 

If the machine looks like it is trying to send but you receive nothing in the Receive File Administrator:

 

Check the cable. Pins 2 and 3 may need to be swapped to match the send/receive lines on the machine control with the receive/send lines on the computer. Check the continuity of pins 2, 3 and 7. If hardware handshaking is being used and your cable requires pins 2 and 3 be swapped (null-modem) then pins 4 and 5 will also need to be swapped.

 

Check to see that the correct machine port has been selected. A quick test is to unplug the cable while trying to send. If the control alarms, the correct port is being addressed.

 

Check the Focal*Point communications parameters to be sure the correct COM port has been selected. A simple loop-back test as described below will verify correct operation. You could also try sending to Focal*Point from a known, good machine to validate proper operation of the serial port(s).

 

 

If garbage characters are displayed on the computer while receiving:

 

The communications parameters are probably mismatched. Check to see that the data types (ISO, EIA, or ASCII) match. Many machines have a parameter setting to select between EIA and ISO. If these settings match, check the baud rate.

 

Other possible sources of "junk characters" are long or unshielded cables, cables with poor connections, cables running near EMF sources such as transformers and florecent lights, or more commonly, improper grounding.

 

 

2. Once data is successfully received, most configuration problems will have been eliminated.

 

At this point it is best to capture a program from the machine control, and edit the program number so it can be loaded back to the control memory without overwriting an existing program.

 

If software appears to send the file but the machine acts like it is not receiving:

 

Again, check the file contents, and perform the initial tests with a file that has been received from the control. Do not use a new program generated on your CAD/CAM system. Many controls require an end of block at the beginning of the file or require a program number at the beginning of the file. Check the control's manual for program termination codes such as decimal 04 character. Some controls also require a M30, M02, %, or the END statement at the end of the file.

 

If a partial program is received (blocks of data appear to be dropped), or the machine issues a data overflow alarm:

 

Make certain that the computer's RS-232 ports are not configured to utilize their built-in FIFO buffers. This setting is accessed from the Windows Control Panel and is discussed in the Windows help program as well as Focal*Point's installation notes.

 

Check to make sure handshaking has been properly enabled. If the cable uses only pins 2, 3 and 7,  select X-ON/X-OFF protocol. (Also referred to as Software Handshaking or DC1/DC3 control codes.) If the machine is old and does not support software handshaking, use a cable with pins 4 and 5 connected. This will enable RTS/CTS handshaking.

 

Loop-Back Testing For Cable and Serial Port Hardware (Not for use on machine controls)

 

 

Loop-Back tests are helpful to determine the proper function of COM hardware and the continuity of cabling. It does NOT validate proper cable wiring or determine the correct RS-232 parameters for communications.

Begin by constructing a loop-back connector, which is simply a DB25 or DB9 connector with the Transmit / Receive (pins 2 & 3) and the RTS/CTS pins jumpered.

 

 

25 Pin Connector 9 Pin Connector

Jumper Pins:  2 and 3

                   3 and 4

                   6, 8, and 20

Jumper Pins:  2 and 3

                    7 and 8

                    1, 4, and 6

 

Testing Procedures

 

  • Place the loop-back connector on the cable or COM port to be tested.
     
  • Using Focal*Point or Easytalk open the Terminal mode screen--in Focal*Point the screen is available within the Communications setup section--and begin typing characters in the Terminal window.
     
  • For every character typed you should see two occurrences in the terminal window. This represents the character being transmitted and the echoed (received) character as jumpered on the loop-back connector.
     
  • If only one character is displayed there is a problem with either the cable or the RS-232 port. Perform the test again but eliminate the cable as a source of the problem by placing the loop-back plug directly on the COM port. Note that some device hardware may terminate with a RJ-45 connector. If so, use the device-supplied, loop-back plug or substitute a known "good" cable.

 

The loop-back test should prove the proper functioning of your COM hardware and, if so, should direct your attention to the control setup and its RS-232 port. Note that some controls allow you specify different ports and device types for both Send and Receive. Refer to your control manual for instructions regarding port setup and configuration. Pay particular attention to device "type" and any configuration options for the control code characters used for data flow-control. Some machine controls require specification of both the DC1 and DC3 codes before operating correctly.  

Warning - Do not attempt to use the loop-back connector on your control unless advised or directed so by the control manufacturer.  Loop-back testing requires a terminal mode function that is not supported on older controls. 

If necessary, verification of the RTS / CTS hardware handshake lines may be performed using port monitoring software or a simple RS-232 LED line tester, both of which are widely available via the internet.