• Replies 3 replies
  • Subscribers 583 subscribers
  • Views 386 views
  • Users 0 members are here
Options
Related

Redundancy with a Single Citect HMI

Joe

HI, I have a question as it relates to redundancy. I have upgraded a project that previously had a local and remote HMI and was configured with the appropriate primary and secondary computers, IO servers, alarms servers, and trend servers in a single cluster.

However, they have opted to remove the second HMI, leaving only one. The control device I am communicating to (Micronet) has two CPUs, and I want to be able to communicate to the second controller if the first one goes down. I only have one ethernet port on the HMI though, so I'm wondering if it is possible to configure two data paths from that single port. I tried a few different configurations that I thought would work: adding a the secondary IO server to the primary computer (threw an error about the IO server needing a unique IP address) and adding a secondary device to the Primary IO server (also threw an error about the standby device needing a primary on the same cluster--not sure this error makes sense to me).

Any thoughts as to if this is possible and where I am going wrong on the configuration?

  • Hi Joe,
    It certainly is possible to configure data path redundancy to your control devices.
    Could you confirm what Protocol you are using? I looked for a Citect driver, and I believe you are using MicrxNet, but please confirm. I'm also assuming this protocol uses a standard TCPIP Board to communicate with the end device and that the two control devices are connected to the same network? E.g. x.y.z.1 is the HMI, x.y.z.2 is PLC1 and x.y.z.3 is PLC2.
    So what you need to do is the following:
    1. Configure single Cluster.
    2. Configure an IOServer on this cluster.
    3. Configure Board of type TCPIP.
    4. Configure two ports, PORT1 for PLC1 with IP x.y.z.2 and PORT2 for PLC2 with IP x.y.z.3.
    5. Configure two IODevices, with different names, but same device number. This is very important for how redundancy will work.
    6. Set the first device, e.g. "PLC1" to priority 1 and mode to primary.
    7. Set the second device, e..g "PLC2" to priorirty 2 and mode to standby.
    8. Set each IOdevice to appropriate port, e.g. PORT1 for first device, and PORT2 for the second device.

    In the event that PLC1 is unavailable, it will then communicate with PLC2, using the same variable tags (and addressing) defined in the first.
    You would need to make sure the HMI has connectivity to either PLC. You need to think about different modes of failure and what this setup will accommodate.
  • Thank you for your reply Olivier, this is exactly what I was looking for! I tested it out, and it works!

    One question though--I noticed that if I fail one CPU it does indeed swap to the second, but then if I reconnect the first and then disconnect the second, it does not swap back to the first. All the data says PENDING. Is there something additional I have to do to enable this or is this by design?
  • Hi Joe,
    Apologies for the delayed reply. I forgot to hit enter on previously typed message! Doh.
    The behaviour you are seeing is not expected. It should switch back to the primary when it is available. Double check the status of the Channel (TCPIP connection) in the Kernel on the IOServer. Can you ping PLC1? I'm not familiar with the data status "PENDING", would this be related to scheduled IO? Sounds strange. I'd be happy to review your communications config if you direct message me with details.
© 2025 AVEVA Group Limited or its subsidiaries. All Rights Reserved.