M580s sharing %Ms with other M580s

[PJ-PwrQ]

I have 6 line up sets of M580s with EH58640s and I need to share %Ms between each lineup. Can someone point me in the correct path of documentation on how to get this accomplished? Also which comm module would be used?  Thank you for your help.

[Trinxs1]

For a hot standby pair of CPUs, the memory bits are automatically shared between the primary duty PLC and the standby PLC. I assume you want to share the %M bits from one PLC pair with many other CPU pairs, meaning one CPU pair writes values to the memory bits while the others read them. I also assume that each PLC pair does the same thing for their own %M bits.

In this case, the best way to share information is to map the memory bits to a word. For example, 16 bits to a word. There may be several words for each PLC, mapped into one variable which is an array of words. Let's call this "PLC1_status." Each PLC that requires this data must read the "PLC1_status" array from this PLC. There may be several PLCs reading data from several other PLCs.

Using Modbus TCP is the easiest way to do this. A BMENOC0301 card will be installed in both racks of each pair of CPUs, and the user will configure the IO scanning table for each transaction using CPU DTMs. The IO scanning table will have multiple transactions as it reads the data from each CPU it needs data from.

An alternative is to use an OPCUA module and use the CPU as an OPCUA client to read the data from the server. This can be configured to effectively publish the data to the clients. This process is more challenging to set up, and I am waiting for an improved process. There is a video to help you configure this at each CPU. Each PLC to be a server must have a BMENUA0100 (OPCUA server module).

I hope this helps.

[ciupol]

Trinxs1 sum it up pretty good. I will add few comments from my own experience:

1. You do not necessarily need additional module to exchange data. You can possibly use ethernet port on your CPU but it all depends on the architecture of your system. Since you use hot-standby system I assume that you have remote racks for IO so you probably utilize CPU ethernet ports for EIO network. In such case additional module is the way to go.

2. You can use any of the available ethernet modules for data exchange: BMENOC0301, BMENOC0311, BMENOC0321.

3. Remember that when you are using DTM to exchange data you can't make changes to DTM online. Offline build is required. So if you go that route plan to configure some extra spare data exchange (for future needs). Unless your application allows you to perform offline build without problems.

4. Using Modbus through DTM requires you to add addresses to the variables you will be exchanging. I personally am trying to eliminate as much addresses as possible. If you don't want to configure addresses for your variables you can use Local Slaves functionality in DTM. As in 3 changes to DTM require offline build.

5. Besides DTM you can also use communication blocks. Contrary to DTM changes to the blocks are possible online and this is big advantage. You can use READ_VAR, WRITE_VAR blocks for modbus exchange (your variables must have addresses) or READ_REMOTE, WRITE_REMOTE for data exchange based on data dictionary (no addresses needed).

At my factory I run system similar to yours. I have about 10 hot-standby systems with BMEH586040 processors. Pretty much each CPU exchanges data with all others. I tried multiple things but as of now I settled on READ_REMOTE blocks. I try to avoid WRITE_REMOTE and use only READ_REMOTE on both sides of the communication channel.

As I said I try to eliminate modbus adresses so did not want to use modbus methods (when I started to work here there was only 984 logic utilizing MBP_MSTR blocks). When we upgraded to M580 we switched to local slaves method. After some time I found a problem with that that though. In the configuration for local slaves it is impossible to configure Input Fallback Mode. It is locked to Set to Zero. What that means is that when the communication drops for whatever reason all transmitted values are immediately set to zero. Since I use the exchanged data for some interlocks my equipment was tripping when that happened. That was a problem for example when controllers switch - in such instance comms drop for very short period of time and my equipment trips. That is why i changed my communication to READ_REMOTE blocks. Opposite to local slaves they hold their value when comms drop. I have a logic with timer and after 5 seconds of no comms I zero them in logic. Of course the blocks solution have some disadvantages as well but that is what I found to work best for me.

[Lionel_Maire]

Hi PJ-PwrQ,
I had a similar situation 2 years ago when upgrading Premium PLCs sharing Global data to M580s.
My solution back then was to create multiple communications between the CPUs and a PLC serving as concentrator/reference.
But between now and then I discovered a communication module BMXNGD0100 with global data service, that might be a more simple solution.
In your case, it seems that you use Redundant PLCs (pairs!?). I don't know if you could use this module on the main racks (in a redundant way)? Do this communication modules support HOT/STBY? something to consider!
But if they don't, another possibility would be to insert them in RIO drop racks. Assuming you use RIO drop(s) in your HW configuration.
I hope this could help you, and for everybody: don't hesitate to elaborate on that idea!
It is always good to learn something new 🙂