Serial Connection Lost and Timeout

[gsussman]

Before you spend too much time chasing grounding issues, have you installed the resistors?

The terminating resistors will increase the current flow through the loop and will have the effect of minimizing or eliminating any induced interference.

With no resistors, each of those opto isolated transcivers has a very high input impedance. This allows your cable run act like an antenna for picking up electrical noise with no ability to dissapate it (This is one reason why RS-232 works so poorly in electrically noisy environments). Once you add the resistors, you will increase the current flow in the loop and provide a way for that scant amount of induced charge to dissapate with little or no effect on the actual signal. 

If that does not work for you then the grounding issues may be a good next step.

[Soroush]

I made an AC termination unit, consisting of two parallel 270 ohm resistors (135 ohm) followed by a 100 nF capacitor. Then, I installed it on the last node of RS485, but to my disappointment, there were no difference and the "Write Timeout" error occured just as before.

Investigation about grounding issues, showed a same experience that Ben has talked about. The RS485/USB converter was completely isolated. Therefore the ground of RS485 was not connected to the ground of PC in any way. I am not sure if it is a bad thing at all, but I connected the ground of PC to the ground of RS485 using an extra wire, and a considerable improvement was observed. Terminating resistors were also in place.

Actually, I thought that the problem has gone away, but after a while, another "Write Timeout" ruined our ceremony!

What shall I do now?

In summary,when I wired the ground of RS485 to ground of USB port (which is also connected to the metal structure of the tower PC) with a wire (no longer than few centimeters) the system became more stable and could tolerate more switchings (we repeated the test several times) but it is not reliable enough yet. Is there any other thing that can improve the quality of the ground?

[jjcimon]

the good news is it improving, It means it is a sum of many noise immunity problems

more than one fix is required

as you wrote.... became more stable and could tolerate more switchings

then what happen to the DIODE on the Relays, you mentionned Switching problems

and the only elements that switches are Relays and Motors,

on the motors you could try  TVS(like diode) but clean all inrush current coming from the motor(if brush motor)

Your motor is a brush or brushless? if brushes ou will have to put also capacitor  to eliminate radio noise......

let me know 

[Ben]

So it sounds like it was CMR (Common Mode Rejection) was hitting you and may still be. 

"Noise reduction Techniques in Electronic Systems" by Ott should be consulted for more suggestions.

Ott suggests keeping the "noise in" (make sure covers and shielding is installed) rather than trying to "keep it out (ferite beads etc).

If the spikes are really big, a very large guage wire and solid ground ref may be required.

Are you using the proper wire, Twisted-pair shielded ?

Ferite beads may help.

Double check the hardware manual about the termination resistors since some devices have them built in so extra could goof it up.

Sounds like you are making progress.

Don't "get stuck creating a topgrahpical map of your navel", step back and decide if a check for the time-out followed by a re-try may be easier to fix that re-running cable through a plant.

[Soroush]

Thanks jjcimon. The motors are brushless and the relays are equipped with heavy-duty diodes. I still think the electric power design is well enough.

The network cable has a twisted pair and the shield connector is used as the ground. Is it proper? or the shield conductor shall be different from the ground. (I suppose that the shield conductor should also be connected to the ground.)

Unfortunately, all hardware parts are custom and I do not have access to their documentation. I will call the manufacturer and ask if there is built in terminating resistors. Moreover, I did not test without terminating resistors after connecting grounds together. I will try it.

Not me, but the program gets stuck when facing the first "Write Timeout". If you take a look at my code, posted earlier, you will see in "Write-Ser-9bit.vi" that I have put the "VISA Write" in a while loop to stay in the loop while the error is "Timeout". A useless idea, because after getting the first "Write Timeout" error, it will stay in the loop forever! (I did NOT use shift register to transfer error cluster from one iteration to the other)

[Soroush]

Ben!

I googled "Ferrite Beads". I wll try it too if removing the resistors will not do. I hope my problem will be solved before you become the next Knight of NI!

[Ben]

RE: "the next Knight of NI!" that is not me! Click the link and you will see who is soon to be Knighted.

Ben

[gsussman]

Ben's advise on the retry is sound in that a software retry is quicker to implement than running new cable, however depending on the number of commands you need to send and the number of times the software needs to retry to get the command through, this may generate unacceptable latency in the program.

If changes to the electrical characteristics of the bus have improved things then the issue is almost certainly electrical in nature.

If your bus is parallel terminated (as opposed to AC coupled) putting an ohmmeter across the A and B lines of the bus should show a 120 ohm resistance (or there about). Doubling the termination resistors (slave device internal and external) will have the effect of drawing much more current from the transcievers to the point where the voltages between a 1 and 0 become too close together and result in poor data transmission (not a good situation). If this is the case, you should either remove one set of terminations or add the bus biasing to get the voltages back up where they belong. The biasing may also help things especially if your new USB transciever has less capability to drive the bus than the previous one.

Here is something I just thought of. Have you checked the integrity of your cable? Is there a pinch point somewhere that may have broken some of the insulation allowing one side of the bus to partially ground out? 

Other thoughts:

1) Try a different RS-485 communication device. The extra cost of a different device is probably well below the cost of your labor to continue debugging this issue.

2) Remove 2 of the 3 devices from the bus. Can you communicate reliably with a single slave device? 

3) Run a new cable to the slave devices. Even if it is just a temporary cable that runs across the floor it may give you some insight into whether or not it is an issue related to the installed cable.

[Soroush]

To Ben: I guessed that you meant Christian! I learnt so much from him too, but always there is place for the "Next".

gsussman! Good ideas! I should think of a step-by-step procedure for the next try. Perhaps starting by removing terminating resistors, inserting ferrite beads, removing some of slaves, biasing the network with bias resistors, temporary new cable and a new converter at last. I believe that there is no problem with cable integrity, since the old system still works prefect when it comes to communication reliability.

Here, we have reached the weekend. So, my next post on this thread will probably appear in next two days.

[gsussman]

I would not recomend removal of the terminating resistors. The resistors are an integral part of the noise suppression capability of an RS-485 system.