• Not Answered

White Space in String Parameter and Unresolved Dynamic References

Hi All,

Having two issues with a string parameter and dynamic references:

1. This string parameter adds white space at the beginning of the input string. I have attached a screenshot of this. This string is used as part of a dynamic reference, so the reference becomes unresolved when this occurs. In the properties there is no space at the start, so very confused as to why this happens. Has anyone experienced this before? I can resolve the issue quite easily, but when this occurs it throws out calculations etc that are done by this module due to the bad status.

I have checked the event chronicle and seems to occur (I believe) when the ProPlus switches between primary and secondary ACN and if there is a device connection failure (ACN Comm Failure). This module is assigned to the ProPlus workstation.

I have other modules like this that are also assigned to a ProPlus workstation but do not experience this issue at all.

2. When this switching from primary to secondary ACNs occurs, all dynamic references become unresolved. Sometimes they resolve themselves, but I reckon this could be due to the module being assigned to the ProPlus workstation and switching between primary and secondary ACNs. In general, would you recommend to never assign control/equipment modules to the ProPlus? I could be missing some piece of information that would prevent this issue or some known issue with assigning control modules to the ProPlus.

Any advice/help is greatly appreciated.

Best regards,

Wilson

• DeltaV #DCS

Wilson Halligan

• 17 Jun 2025 8:58 AM
• Cancel

1 Reply

• Andre Dicaire

  

  • 17 Jun 2025 2:45 PM

  I have not observed String parameters padding a space without some "reason", such as an error in data entry or when the string is constructed programmatically. That said, not saying there isn't something happening that is not evident. For example, in a CND block, if you enter a path in the expression using lower case, the expression will parse it, and later when you open that expression, the path is shown in upper case. But if you view that expression with the Expression Viewer, that path shows up as unresolved (?????). Turns out the lower case path is still in the database, and when the Expression viewer pulls the expression for display, it cannot resolve the lower case path. (Issue has been there since v6 apparently). Knowing which path is failing, you can edit your expression and redo this path in upper case, save and Expression Viewer will then be happy, but note the path appears in Upper case in Control Studio.
  
  I wonder if this could be an "Override" issue, where the parameter is in an embedded block, and contains a String value, and the module has an override of the string value applied at the Module level. This is a long shot, but which ever item has the newest time stamp in the FHX, the parameter takes on that value. This issue was created in v12 when unique references to Embedded blocks was enforced on import, causing a new version of the embedded block to be created for multi referenced blocks. The new versions of the embedded block were dated on the day of the import, which reverted values to the block value rather than the module override. I believe if you import an FHX today with two modules referencing the same Embedded block, you could create this issue. Note in v12, the configuration tools in the database prevent duplication of embedded blocks. You'd have to be creating a new module via FHX copy and text replacement. You would be able to export your module and confirm if the value of the string is defined in two places and if one had a space, the other did not. I think this is low probability,
  
  If this is happening randomly, and not due to online changes (event chronicle would record these), I recommend a GSC call.
  
  As for item 2. I don't recommend modules assigned to the Pro Plus unless the system can live without them from time to time. The Pro Plus is primarily for engineering and is central to the system backups and firmware updates etc. It is more likely to be restarted for various reasons. In a small system, with one or two stations, you may not have a choice. If an Application station exists, I would assign modules to the Application station especially if there is OPC traffic with those modules through the App station. If you are writing values via OPC to these modules, they should be on the same station as the OPC server so that writes, especially continual writes, complete within the station and not over the network. If the Pro Plus is the OPC Server, then the modules belong there.

  Andre Dicaire

  • Cancel