Emerson Exchange 365

• Not Answered

Download Behaviour for Redundant controllers 13.3

We are experincing some issues associated with downloads on 13.3, on a MD+ controller with freetime of 37, post a download the controller drops to 3 and gives a low controller freetime warning.  In V11 I remember anything over 20% was acceptable to download without exepiriencing warnings.

It seems the download behaviour has changed with later versions, previously the standby controller would become unavailable post download as the partner was updated, but we are not seeing that on 13.3, both controllers are always available.  The other side affect of this is that inter-controller connections are dropped and with some of our legacy logic, it causes modules to alarm.

If anyone has any details on what the download behaviour is now for 13 and above?

Thanks 

AdrianOffield

• 15 Oct 2019 5:10 AM
• Cancel

3 Replies

• Andre Dicaire

  

  • 15 Oct 2019 6:02 PM

  The v13.3 MD+ controllers still run the same OS as v11. The recommendation for minimum 20% freetime helps avoid issues with burst loading conditions such as partial downloads. However, the consequence of a particular download might be an elevated CPU load and FreeTime could drop to 0 as the controller processes whatever is needed as a result. The Low Freetime is not an issue onto itself.
  
  I'm not 100% sure what has changed for an MD+ between v11 and v13, but in earlier versions, the Standby configuration needed to be downloaded to synchronize it with the Active controller. The Restart location would become the Workstation and a Cold Restart download was needed. This was done to allow a series of partial downloads to be taken without having a Total download to the standby on each one. This is why the standby goes unavailable.
  
  In v12, I think, the partial download behavior was changed such that the Active controller passes the downloaded module to the standby and both controllers get the new configuration, eliminating the need for the Cold restart download. Now the standby controller remains available through the module download.
  
  This would explain the additional CPU usage through the download process. Once the download is completed and all modules are running, the Freetime should return to an appropriate indication, based on the downloaded changes.
  
  The inter controller connections are another issue, but could also be contributing to the low Freetime. When a module is downloaded, the new version of the modules may require a rebinding of the Proxy Client/Server connections. There were changes to how inter controller bindings are handled in order to improve the robustness of user configuration during controller switchover. In earlier versions, users were advised to set Algorithm Options in Calc Blocks and Condition blocks in order to handle loss of communication on a switchover. The Controller Redundancy Analyzer Program was provided to identify configuration references that could result in loss of communication BAD Status on Switchover.
  
  V13 does have some changes to handle these references and maintain good status through controller switchover.
  
  So, other than the alarms, does the download complete and does the CPU return to 30+% (or to an expected Free Time)? Do the Inter Controller references resolve and work as expected after the download, and there are no unexpected Interlocks or other logic firing?
  
  If you focus on one of these Alarms and any inter controller references in the module, can you discern if the alarm is valid and what is causing it?
  
  Final comment, I would expect that the CPU freetime in v13 to be different than v11 with the same configuration. Emerson notes that the free time post upgrade could be less by up to 5 %. In reality, this greatly depends on the configuration. Sometimes a Function block might be modified such that new features are added and this could reduce Freetime, to the extent that block is used. In some releases, optimizations in function block code could actually increase freetime. You did not indicate if the drop to 3% freetime was a transient condition or if the new freetime is now permanently 3%.
  
  The Time Utilization Chart for MD+ controllers should show you the CPU consumption for Control, Redundancy, Communications, Other and Idle time. The CPU freetime diagnostic is normally based on the Control task, based on an allotment of 65% total CPU for control. Under a download, you might see the IDLE time drop and Other Task, Communication Task increase as the download is processed. This would provide some clearer understanding of what the controller is doing during the download and post download.
  
  Hope this helps.

  Andre Dicaire

  • Cancel
• AdrianOffield

  

  • 20 Oct 2019 3:31 PM

  In reply to Andre Dicaire:

  Thanks for the indepth repsonse, as usual!
  
  You've given us plenty to go on for now, the controller returns to 30+% but we can't explain the mass alarming of modules following the partial download. It may be related to serial modules and some direct links to IO parameter in some very old logic.
  
  We will review the logic and try to find the culprits.
  
  Out of interest, would MX provide any benefits to this situation?
  
  
  Many thanks.
  
  Adrian

  • Cancel
• Andre Dicaire

  

  • 22 Oct 2019 4:13 PM

  In reply to AdrianOffield:

  An MX will provide significantly more CPU processing capacity, so your Freetime would move from 37%+/- to somewhere between 70 to 80% freetime. things would complete quicker. You would increase the overall controller communication capacity and it also increases the redundancy link speed.
  
  As to whether any of this directly impacts the source of the mass alarming I can't say.
  
  Note that in v14, MX and MQ controllers will update to the new OS used in S-Series since v12 and allow support for CHARMS. The MD+ is still supported, but like the SDPlus, will continue to run the current OS.
  
  If an upgrade to MX is being contemplated, I would highly recommend the move. If doing an Offline upgrade to v14, you might also want to consider a PK controller. An MD+ DST count is certainly far below the "rated" 750 DST. You are "full" based on CPU. If your DST count is below 300, a PK 300 could be used, and you'll get the full CPU capacity that is 4 times that of MX. The PK 750 is slightly more than an MX in price, but an MX is typically CPU bound at 600 to 800 DST, depending on configuration.
  
  You can upgrade to MX on line from MD+. If customer has MX already, they have Spares, so MX is a good move. If they have no MX, and upgrade is offline, you have a good path to PK hardware, which lands you into the latest controller hardware platform, with integrated Ethernet and ability to support a local HMI via Modbus TCP or OPC UA. PK also supports 25ms and 50 ms Modules with new Plus IO cards.
  
  Something to think about.

  Andre Dicaire

  • Cancel