RS232 Communication Help

Hi guys,

Helping a customer out here. They have a Quick Tech CNC Machining Centre running Syntec 900ME controller. I have a known working cable and computer, but I cannot communicate with the machine.

I am using a USB to RS232 adaptor, into a 9 pin to 25 pin cable, into the machine. The same setup communicates with a Mitsubishi controlled lathe no problem.

Does anyone know what RS232 comm settings I should set the machine to ? I have tried a bunch of different settings including baud rates, parity settings, handshake etc to no avail. Obviously I am matching the settings on the computer side of things too. Any help greatly appreciated. Thanks.

Have you talked to Syntec? Some USB to serial converters are problamatic.

What is your com software? I ended up buying DNC software to get my 3T going.

Ed.

NO experience with this machine, but

try sending from the machine first

are you getting nothing?
are you getting garbled data?

is the machine showing it is connected?

My heidenhains are super fussy, they need jumpers and such to make the comm work

I am still using an old laptop with a serial port
I just bought a little usb emulator to play with

good luck

Different adaptors are different.

We had past where only the radio shack sourced one would work, meaning out of box it was good where others required messing with.

Try different drivers or different adaptor.

Sent from my SAMSUNG-SM-G930A using Tapatalk

I usually recommend the freeware program RealTerm (from Sourceforge) for deep dives into serial port stuff. It will show data on the terminal screen even if the baud rate, parity, etc. is incorrect... it will just be 'garbage data'. But you can then tweak variables until what you see is reality. It can even be in-line between two ports (using port echo and two adapters).

The USB to 232 adapters I've had good luck with for a couple decades are the IO Gear product for about $30, and the (legit) FTDI-chip products at slightly more $ -- USConverters XS880 for example. Both are Mac/PC (and presumably Linux) compatible. The 880 has actual data flow indicators. The IOGear used to, but now it's just a pilot light. Otherwise good and usually locally available.

SEI_Adam said:

...The same setup communicates with a Mitsubishi controlled lathe no problem.

Does anyone know what RS232 comm settings I should set the machine to ? I have tried a bunch of different settings including baud rates, parity settings, handshake etc to no avail. Obviously I am matching the settings on the computer side of things too. Any help greatly appreciated. Thanks.

Click to expand...

I use 9600,e,7,2 Xon/Xoff.

You can communicate fine to the Mits control. So look at that machine's settings, set the other machine to the same settings, and leave the computer side alone.

Are you getting any error messages?

guest said:

I use 9600,e,7,2 Xon/Xoff.

Click to expand...

There are two standard methods of flow control for RS-232, RTS/CTS* and XON/XOFF.
If the two ends are set differently, they will NEVER talk to each other.
While it's possible to enable both methods on a single interface, you should not do so.

RTS/CTS is a "hard" control protocol that uses wires in the interconnecting cable.
These wires must be properly connected at both ends.
This is the original flow-control protocol in the RS-232 standard (all versions).

XON/XOFF is a "soft" control protocol that uses characters sent over the serial data lines.
This was developed for systems that did not have wires in the cable to support RTS/CTS.

- Leigh

*Note
RTS - Request To Send
CTS = Clear To Send

Thanks for your help guys. I have had problems in the past with USB-RS232 adaptors, so i specifically bought a FTDI-chip set adaptor for that reason. Whilst I understand it still could be the adaptor, I am hoping the one I have fits the bill fine as it uses the FTDI-chip. I want to explore all other avenues before buying another one.

The machine's default settings were RTS/CTS handshake. Is that likely to mean that it needs to run that handshake protocol? On the Mitsubishi lathe it works fine with no handshake. So why do some machines require a handshake ? Is it only for drip feeding ?

Do you know if another serial port device can communicate with the machine?

Why I ask is that it is rather common to have the line driver chips get damaged preventing communication from taking place.

Also make sure you've got the transmit/receive on pins 2 and 3 correct. I've been tripped up by this more than once. See Data terminal equipment - Wikipedia

SEI_Adam said:

The machine's default settings were RTS/CTS handshake. Is that likely to mean that it needs to run that handshake protocol? On the Mitsubishi lathe it works fine with no handshake. So why do some machines require a handshake ? Is it only for drip feeding ?

Click to expand...

Most modern RS-232 interfaces will work with no flow-control protocol active.
Flow control goes back to the days of 300-baud modems that had to switch between transmit and receive.

The proper wires exist in the 9-pin RS-232 connection definition, but may not be in the actual cable.
Here's a good reference to the 9-pin connections:
https://www.stratusengineering.com/rs232-9-pin-pinout/

If you're not sure your cable has the proper wires, I suggest using XON/XOFF.

- Leigh

SEI_Adam said:

The machine's default settings were RTS/CTS handshake. Is that likely to mean that it needs to run that handshake protocol?

Click to expand...

Yes. That is hardware flow control and it will only work with a compatible cable. I have some doubt you will be successful using RTS/CTS with all those adapters in the line.

I would set both ends to software flow control- Xon/Xoff- and try that. You should check to see if it affects the Mits when you do that.

SEI_Adam said:

The machine's default settings were RTS/CTS handshake. Is that likely to mean that it needs to run that handshake protocol? On the Mitsubishi lathe it works fine with no handshake. So why do some machines require a handshake ? Is it only for drip feeding ?

Click to expand...

Hello Adam,
It only works fine, because data from the Input Buffer of the machine's control is being processed at the same speed. or quicker than the sending device is sending data and therefore, no Handshake Event is being raised.

Most Comms Software have a feature to be able to add a delay after each Block and or, after each character. This is a bit of a fudge used to overcome the short falls of either the sending, or receiving device. My guess is that the system is using a fairly slow Baud Rate, and that delays at least after each Block have been set. I'd also guess that whoever set the comms with no handshaking didn't know very much about RS232 communication and got a result through dumb luck. Bump the Baud Rate up and you will probably experience Buffer Overflow with the machine.

I suggest you actually determine the configuration of the cable you're using, so that the correct Handshake Method can be set. Alternatively, decide what Handshake Method you will use, then build, or buy the cable to match the Handshake Method.

The typical settings of the RS232 protocol for your control is as follows:

Data Bits = 8
Stop Bits = 1
Parity = Odd
Baud Rate = 4800 (starting point)

Software Handshaking (Xon/Xoff) is the easiest method to set up and the most commonly used, but Hardware Handshaking is the most reliable. Following us the cable pin-out for Software Handshaking:


Machine Side ---------------------------- PC Side
DB25 Male Connector -------------------- DB9 Female Connector
1 --- Shield Trace ----------------------- Not Connected
2 ----------------------------------------------------- 2
3 ----------------------------------------------------- 3

4
| Bridged
5

6
|
8 All Bridged
|
20

7 ----------------------------------------------------- 5

Regards,

Bill