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.
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.
Last edited: