Problem in Data Read/Write on Servo Drives in RS232/485 Communication

Have you checked for proper terminating resistors?

This might be due to flow control. The old DOS machine might have been set up to use XON/XOFF or RTS/CTS hardware flow control. This is a common cause of dropped data in serial systems. Flow control settings are set against the serial port. I think the old DOS command was MODE or it might have been set within the software. Flow control allows the receiver to request a pause in the data flow to prevent buffer overflow. It can also be the case that if the DOS system was set to no flow control and the Windows system is set to XON/XOFF, then if the machine happens to send an ASCII XOFF then the PC will stop sending data.

With the servos being in parallel, you may be experiencing bus contention, everybody talking at once. Try inserting delays of 100-300mS between commands. You might also check the baud rate, and try one step slower.

It worked for 18 years.
Something changed and now it doesnt' work as well as it used to. Hmmmm.

What changed?

The old system ran with/without terminating resistors, so the new one should, too.

The old system had no bus conflicts with belligerant drives talking when they shouldn't.

The converter has not changed.
The field wiring has not changed.
The drives have not changed.

Why should 'noise' be present now that wasn't before if the drives, field wiring and converter have not changed?

The PC and O/S changed. It is not clear whether the software changed, or not.

What do the changes or lack of changes tell you?

Windows 7 accesses COM much differently than DOS did. Hmmmmmm.
What about the software?

Dear All;

Thanks for your participation. The original DOS based PC is just like a Black Box for us as we don't know any thing about it. We have written the sequence of operation of machine in codes in Microsoft Visual Studio, Net framework 4.5. We just remove the DB9 connector from old PC and connect it to our new system.

The old system has/had been working well. The reason which compelled us to design a new system is that OEM declared that they have made obsolete this machine and they don't have any kind of spare of it.

Apparently, the communications works some of the time to all drives, correct?
In fact, one might say that communications works most of the time to all drives, but there's an occasional missed message?

The PC and the software program have changed. Nothing else.

I see some potential problems

1) You are now wear the hat of a software developer which means you now have the responsibility to debug your system, since the software drives a com port and is responsible for communications.

Since the only change is the PC and software, some issue arises that causes a message to not be sent or not received or to send a message when the receiver is supposed to be listening.

The only remedy I know of is to shop for a serial port sniffer software/hardware package (also called serial protocol analyzer software, or serial port monitor software) that listens on the serial line and displays what happens on the serial line. Google will find them for you.

There might be freeware, but anyone I've talked to who has actually solved a real serial problem has use a licensed software package. Packages are $300 - $2,000 and need a Tee or Wye hardware device (one company calls it a bus tap) to tap into the serial line.

The RS-485 package I am aware of is different than packages for RS-232. IFtools MSB RS-485 package provides not only traffic display but has a scope display (not a true scope, just a waveform display. Serialtest makes a hardware tap for 232.

Caveat Emptor, there is a learning curve.

2) RS-485 is supposed to have termination resistance installed at each end. However, it appears that your 232/485 converter has not changed, not the field wiring. If that's the case, termination is not likely the problem now if it wasn't before. Incorrect termination results in reflections that disrupt bit patterns for messages in progress or cause a false byte reception if a reflection is interpreted as a start bit.

3) Co-incident with your changeover to new PC/new software, something was installed or or something else changed its performance so something now generates electrical noise which disrupts the serial communications.

An oscilloscope issue will help you see the noise, but finding the source can be a challenge. The good news is that since communications works some or most of the time, you have a baseline of what good communications looks like on a scope screen. The bad news is the effort to locate the source of the noise.

Finding out 'what changed' generally requires nagging and harping and bitching at the people involved in the area about who did what to make changes. Locating that fluorescent light ballast that is generating a storm of noise is sometimes just luck.

I think option 1 is far more likely than options 2 or 3.

If the cost of the software and the learning curve to get any value out of it seems too high, then consider the alternatives
- live with the problem,
- hire a consultant to fix the problem (VB people rarely know serial comm)- replace the drives and the software to get the performance needed.

A log can be an aid in assessing the problem.

It occurs to me that one of the devices might be faulting its communications intermittently.

You might want to consider logging whatever failure mode it is that makes you aware that there's a comm problem to see if the problem is associated with a given device.