Hi Simon,

Jabbers are Ethernet cards that are transmitting continuously because they are faulty (ie jabbering)

Runts are data packets that have been cut off part way through transmission. (ie shortened)

EMI is likely to cause runts and packets with CRC errors.

BTW, all of the above will get through repeater hubs but are blocked by switches (ie bridges).

Regards

Peter Whalley

Magenta Communications Pty Ltd
Melbourne, VIC, Australia

 

Really, if your primary objective is to maximize data throughput, the factory default is the greater of two evils, but beware that changing
the settings can [will] effect the deterministic nature, and effective rate, of your PLC scan time. A switch may help here to maintain
determinism, assuming that the HMI polling remains constant. Note that this implies that your PLC scan time is likely to vary depending upon the operation of the HMIs. If you don't do scan time based tracking or PID loops, and you can handle the increase in the effective scan time, this approach may help you.

 

Hi Wes

Tried to find that option in RSLOGIX500 but could not find it in the channel settings nor anywhere else. Can You please give a hint where I can select between these two options.

Thanks Rolf ______________________________________
Rolf Gerste
PRISMA Automation Pty Ltd
PO Box 35867
Winnellie NT 0821
Australia
Phone 08-8984 4385
Mobile 0417 837 933
Fax 08-8984 4001
mailto:[email protected]
http://www.prisma.com.au
ACN 097 718 342

 

When you say slowdowns what do you mean....

Have you "data concentrated" your data into packets. AB processors still can only handle so much comms.

I try to follow rules of concentrating as much data into one or two registers to each PLC, you can drag down a PLC quickly with multiple requests for alarms etc from multiple data tables from multiple PC's, it doesn't take much.

Dave

 

Agreed....see my earlier reply.

 

I found it in S:2/15, OTU it. It did not have an effect on the scan time and did speed up comms.

 

Further to my last postins we are now sitting pretty with Ethernet buzzing at light speed. Heres what happened.

First, we had a number of cable termination issues to resolve. Poor connections. We have now learned to use CAT5 shielded cable and have the system certified.

Once we rectified those problems it was apparent we had a number of software issues to resolve. The first thing we did was to reconfigure the network to use an IO server with back up but using RSLinx as an IO server as suggested, we found it even more problematic. DDE was then bugging out on us. According to the WonderWare web site, there are numerous pointers about problems with Net DDE on a W2k platform. As somebody said <b>"DDE IS DEAD"<b> We switched to SuiteLink as according to WonderWare, "Suitelink is designed for industrial applications with high throughput" and all WonderWare servers support Suitelink but could not clarify whether RSLinx did and suspect that it does not even support it.

That really is about it other than we opened the flood gates by clearing s:2/15 and saw an improved performance!

Conclusions.
Check and certify wiring
Use shielded CAT5
Drop Linx
Use SuiteLink
Use WonderWare IO server with WonderWare apps.

In the land of little Ether's we are flying high!

Thanx for all your help and input and hope this may also help some other poor b***ard who is suffering a similar fate.

 

Now you're making me think! All I can remember is that it is a bit in one of the S-registers, possibly around S24? Assuming that you are
using RSLogix, just troll through and look at the comment for each bit. I think there might even be two different things to twiddle that would
have an impact, but it's been two and half years since I had to deal with this issue... If this doesn't help you find it, let me know and I'll see if I can locate an old manual somewhere.

Wes

 

Hi all,

Bell Labs / Lucent have pushed very strongly for many years that shielding Cat 5 cable creates more problems than it solves. They claim that the
shield can end up becoming an antenna and coupling interference into the system rather than keeping it out. You also have all the problems of
deciding where to earth the shield (one end or both ends etc). Shielded cables have traditionally been used for low data rate applications whereas Cat 5 is typically used for high and very high data rates where shielding
requirements are different.

The very high twist rate of Cat 5 compared to older style cables also creates very good noise rejection so shielding is not generally required
(provided your using a balanced transmission scheme). Ethernet is also a low impeadance transmission scheme so is much less suseptible to electrical noise than say RS232.

My understanding from what Lucent (and I'm talking about their head office engineering manager not local reps) say is that unshielded Cat 5 is OK for all but the most extreem industrial environments. He also said they could
do field strength tests to determine if their was likely to be a problem which would require special treatment.

Regards

Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 

Just another friendly nudge...

Don't forget to look at your PLC polling rate and message optimization. You want to minimize the number of individual requests you hit the PLC
with. Favor fewer large packets versus more smaller packets. Of course this is really something best designed for up front on the HMI side. One thing is I don't think RSLinx will automatically optimize packets for you when not used with an RSI product. By optimize, I mean for
example that if you want 10 dis-contiguous registers from a single register file, there is a point where it makes sense to get the block of
registers from the lowest to the highest that you need and throw away unused data, rather than send 10 separate requests for individual registers... Also, someone suggested a switch. This is a GREAT idea because the ethernet interfaces of the PLCs then don't need to waste their precious [little] processing power deciding if a poll for one of the several other PLC is actually intended for it because the switch takes care of this tedium. Usually switches are intended to ease
congestion, but in this case they do a handy job of demultiplexing the traffic from the data collector PC.

FWIW, I have seen Unshielded Cat5 Ethernet runs approaching 100 meters on a passive hub operate reliably as the communications mechanism between eight medium voltage (22kV) switch gear containers running 2 MegaWatts EACH. The really amazing thing is that the configuration works even when the containers are sourcing the power from lead acid batteries through 250 KiloWatt inverters (eight per container)... In case this is not clear, think 20 MEGA WATT Uninterruptable Power Supply, monitored by one PC talking to eight "data collector" PCs.

 

Thanks WES

I found It. S:2/15 and S:33/7 in the Ch1 configuration TAB

Best Regards Rolf

 

What do you mean by slowdowns? Is the Wonderware station centrally located? What types of traffic is being generated? On the surface, 20 devices in a switched environment SHOULD not be a problem. I don't know the topology but would be glad to help with more info. In regards to an analyzer, a PC based sniffer like Observer by Network Associates only analyzes the segment not the entire network. This can be done but probes are needed (devices connected to a network which allows monitoring from a remote location. It may be advantageous to pay for a network analysis as a one time thing
to find out the baseline of your network. Let me know some more info and I would be glad to help.