Created Date: November 11,2004

Created by: Tech Guy

In my humble opinion, if you are needing data very fast that may well be too much to ask of the ECOM.

Your two EZ-Touch screens do not have a poll delay built into them. In other words they ask for data as fast as they can get it. This means they eat up quite a bit of bandwidth and there isn't a lot you can do about it.

Now as far as your PLC to PLC communications, if you can live with it being a bit slow, you could add a timer to space out the comm transactions and give the EZ-Touch's time to talk.

If the PLC to PLC has to be fast, then I forsee problems with this. If you don't have a timer to space out your PLC to PLC transactions, when something goes down (either an EZTouch or PLC) there is little likelyhood of it being able to reinsert itself into the communications stream, since with this scenario you are banging on the ECOM as fast as it will go with all devices. So if something goes down, a full reboot of all systems might have to be done to restart comms to all devices.

My advice is to put the EZ-Touch's on one ECOM and the PLC comms on a seperate ECOM. This will result in a much more stable system.

Created Date: November 11,2004

Created by: clasentech

Let me reply with this and ask for your humble opinion once again:

The PLC to PLC comm will be two seperate WX commands and each will be 2 bytes of data. The WX will only occur once every time a start is initiated. This means once every 15 minutes usually.

Now, I like your idea of the two ECOM's and that is the approach I will most likely take (just means a bigger switch or another). But now that you know my PLC to PLC is not too heavy on data, what is your opinion on the situation?

Created Date: November 11,2004

Created by: Tech Guy

My main approach to data exchange is a common sense approach that I call "The Knothole Theory. " In other words you can only stuff so much through a knothole at a time. Same thing applies to communications. A communications method, be it a serial, ethernet, or whatever type of device, has a finite data rate. You can only put bits in as fast as the device can accept them. Excess bits have to wait their turn, which causes backups, collisons, and other unwanted problems. I figure out how much I think will be too much by rough approximation and allow leeway for noise of other unforeseen problems that might arise.

A rough calculation that I might go with would be something like this; how much data is on each screen + the amount of trend data on each EZ-Touch + data going between PLCs / the update time that I can live with. If it all adds up to hundreds of words of info, I won't expect it to be fast nor necessarily error free depending on the communications method.

Your system doesn't seem to be data heavy on the PLC side (we haven't discussed the EZ-Touch side so I can't comment), so it will probably be fairly fast and one ECOM can most likely handle both jobs.

Sorry if I seem to be preaching, but this is a very common problem, so I took the opportunity to shed some light on an approach to 'how much is too much '. http://forum1.automationdirect.com/board/smile.gif

Created Date: November 11,2004

Created by: Tech Guy

Not quite 10x as fast. Remember with any ethernet transaction there is overhead. So the move from 10mb to 100mb is not necessarily a 10x speed increase depending on the number and size of transactions that must be processed.

Now that I 've been a wet blanket, yes, it will be a significant speed improvement over the 10mb cards. http://forum1.automationdirect.com/board/smile.gif

Created Date: November 11,2004

Created by: franji1

Realize that 10x doesn't mean that problems like this will go away. If you are running open loop, or "as fast as possible " and either side ends up queuing messages, you still have the same problem.

We are definitely seeing more transactions being processed (especially on the faster 260 CPU), but that means that there are more packets on the wire, but for a shorter period of time.

It's like an infinite loop taking up 100% of the CPU. If you go to a faster processor, it will still take up 100% of the CPU.

This reminds me of a joke I once heard:

Did you hear about the new super computer they developed at State University? It can do an infinite loop in just 6 seconds!

Created Date: November 24,2004

Created by: Russ

Just adding to all the good comments here...

My thoughts and practices are the same as Tech Guy: keeping excess traffic off the wire is a good thing and you should always plan on needing more bandwidth in the future.

I'd also add that for critical PLC to PLC communications, consider a scheme that uses a token passing / watchdog mutual reset system to monitor the integrity of the link between the PLCs.

Unfortunately, we don't always have control over what other systems do on the wire, so if you 're having trouble maintaining a well behaved network, consider using a switch with some extra intelligence. They are more expensive than the more common "unmanaged " variety, but a managed switch can give you network control options such as:

Rate Limiting: Allows each physical port only so much bandwidth.

QoS (Quality of Service): Traffic prioritization based on a number of factors (MAC/IP/Application/Port etc...)

VLAN (Virtual LAN): Establishes separate logical networks on the same physical structure. (Ports grouped together).

Hope these suggestions help, and I'd be interested in hearing of any others!

-Russ

Created Date: November 11,2004

Created by: clasentech

I am curious about the effect that multiple comm's on an ECOM mod will have. Here is my new senario:

Two EZ-Touch Ethernet communicating with and H0-ECOM (via a switch.) DSData communicating with the same H0-ECOM. And now...I want the same H0-ECOM to write to a H2-ECOM and eventually I want the same H0-ECOM to read and write to another H0-ECOM which will also do all of the above.

My main concern is the SP bits that designate busy for the WX/RX instructions. But a general reply will also be appreciated to shed light for everyone.

Thank you!