MSG read/write versus HMI read/write - most efficient

I have an application where I am currently reading very small amounts of data from as many as 15 processors using a ML1100 dedicated to that purpose (over Ethernet). I should note that this "collector" is also connected to a small MODBUS RTU network and reads data from a couple temperature controllers. None of the data is process-critical. The data is only for determining KPI, so it doesn't have to be up-to-the-second. I have cascading messages set up on a counter. A timer increments the counter every .5 seconds. If the counter = 1 and MSG#15 is DN or ER or TO, MSG#1 is Enabled; if the timer = 2 and MSG#1 is DN, ER or TO, MSG#1 is ENabled... You get the idea.

The network works fine, but digital flow meters & totalizers on my HMI are being updated less-and-less frequently as more processors are added to the network. I'm now seeing up to a 3 second delay between meter updates. Originally, meters scrolled smoothly. Disabling some of the MSG instructions improves meter performance significantly, but defeats the purpose - no point in having a meter if there's no updated data to display! The one meter I'm most concerned about reads its data directly from the originating processor and doesn't wait for it to be written to the "collector".

BTW, the network has 3 x SLC 5/05, 8 ML1200 (all equipped with 1761-NET-ENI), 3 ML1100, one CompactLogix & one Contrologix. Two more ML1200 will be added to the network soon. One SLC 5/05 has been configured as a DH-485 to Ethernet pass-through. The 3 SLC 5/03 processors on the DH-485 network write data to the SLC 5/05 when data changes.

None of the MSG instructions read or write any more than 2 16-bit "N" registers or 2 32-bit "F" registers. For instance, one MSG reads "N7:0 & N7:1" from a single processor.

These processors are all on-line during production, since all machines start around the same time, but many machines run for hours after their counterparts are finished and shut down. Consequently, there is a lot of waiting for TO on some MSG. To get around this, I set up write MSG instructions from each processor to send data to the "collector". These write MSG are triggered when data changes in the originating processor. I ended up reducing the network traffic when machines aren't operating, but I'm sure that I'm also trying to send data from several processors at the same time, creating a bottleneck. I know that "writes" take more bandwidth then "reads", too.

Also on the network are 8 C-More HMIs, connected via Ethernet, which leads me to this question...

Would eliminating the MSG instructions and utilizing one of the HMI as a "data messenger" be more or less efficient than all the MSG instructions?

I could poll the individual processors and write data to my "collector" using the Event Manager. This seems to be a more sensible method of collecting this data to me.

I know - I'll get a reply asking why I don't just try it and see if it works. I could do that, but it's a lot of work and there's no point in reinventing the wheel. I know other HMI have the same read/write capabilities as the C-More so someone must be using one for the same purpose.

I'd certainly appreciate some guidance.

Two quick points...
Between PLC's, MSG READ instructions are much much more efficient them MSG WRITE instructions, as there is about 1/4 of the comms traffic involved. MSG WRITE instructions require several back and forth transactions, so if you are just aggregating information, use READS.

Secondly, yes, it is probably a much better idea to collect everything you need at the HMI, and write only when needed (perhaps only on change of state, or something similar). PLC's, especially the lower end, while capable, do not have many free communications buffers and resources. I try to use them sparingly.

Is each C-More dedicated to a single processor or do they also read from multiple processors?

Are you using Ethernet switches as opposed to hubs?

Every C-More is connected directly to a number of processors through the Ethernet network, with the exception of the PLCs that are on the DH-485 or Modbus networks.

Basically, I have five fillers and each has an HMI to allow the operator to select supply tank, view KPI, etc. The filler HMIs are each connected to four PLCs - a caser (reading a case count and a unit size indicator), a case stacker (reading a case count and a stack count) and the plant valve control PLC (to open / close valves from supply tanks). Passwords to access the HMI functions are stored on the "collector" PLC so I compared the passwords that are entered to those stored a few times a day. Two HMI are also connected to the PLC that controls the filler to prevent starting until a password is entered.

The lab has an HMI that is used solely for tank monitoring. They are alerted via a synthesized voice when an operator changes supply tanks so samples can be taken.

Two HMI are used for process control & monitoring. Both are connected to the three SLC 5/05 and the "collector". Their functions are identical.

The 3 SLC 5/05 processors are connected to a Sixnet managed switch / modem, as is the "collector" PLC. All remaining processors are tied into unmanaged industrial network switches (1 x 8-port, 1 x 24-port, 1 x 5-port), which are connected to the Sixnet switch. All wiring is CAT5.

It might be best to create a drawing of your PLC network, including the HMIs, and the DH485 network. Then it might be more obvious what changes could be made to your data collection. It might be best to have more than one PLC acting as a data concentrator, and then, using fewer messages, but larger blocks, get the data you need at a higher frequency without burdening the network(s).

rguimond said:

These processors are all on-line during production, since all machines start around the same time, but many machines run for hours after their counterparts are finished and shut down. Consequently, there is a lot of waiting for TO on some MSG. To get around this, I set up write MSG instructions from each processor to send data to the "collector". These write MSG are triggered when data changes in the originating processor. I ended up reducing the network traffic when machines aren't operating, but I'm sure that I'm also trying to send data from several processors at the same time, creating a bottleneck. I know that "writes" take more bandwidth then "reads", too.

Click to expand...

Is it absolutely necessary to power down the PLCs when not running? Your network will perform better if the messages succeed instead of fail and timeout. Then you could go back to reading from the collector PLC.

Alternatively, something to think about...
What if the PLCs sent a message when they powered up to the collector PLC to tell it "I'm running" and that enabled the read message for that PLC. Get a few TOs from that PLC and disable it's message until it wakes up again.

rguimond said:

None of the MSG instructions read or write any more than 2 16-bit "N" registers or 2 32-bit "F" registers. For instance, one MSG reads "N7:0 & N7:1" from a single processor.

Click to expand...

General rule of thumb for SLC/PLC5 messages: Up to 100 words a message takes pretty much the same bandwidth if it's 1 word or 100. If you have more than one message with the same path, consolidating them will improve overall performance.

I'd look closely at the ENI equipped PLCs for bottlenecking. They just don't have a lot of bandwidth.

I took the time and set up each filler HMI to send updated data to the "collector" as required. I also disabled the MSG instructions that were gathering the same information. I'll know tomorrow whether there is an improvement in meter display.

I tried writing to the "collector" when a PLC first comes online to enable read MSG instructions and it worked OK - sometimes. The trouble was that if the first write wasn't successful, no data was read. I suppose I could set up some sort of a "heartbeat" detector to check for vital signs every 5 minutes, or so. Something to consider.

No, I can't leave the PLCs on, at least not without installing new step-down transformers on the hot side of the main disconnect.

Writing KPI from the 5 HMI panels to the "collector" was MUCH more efficient than all the separate MSG instructions. When I get a chance, I'll set up a routine to compare the two methods. I like the 'heartbeat" detection method, too - will probably experiment someday.

Thanks for the suggestions.