Alias Resolution in DeltaV
by Mark Noseworthy, Group Engineering Manager I was recently working at a client and made some DeltaV code changes on the Development system to a composite1 used in a control module. One of the code changes involved adding an Alias2 reference out to a different control module to obtain some information running in that other module concurrently. Once it was all configured and tested, the code was downloaded successfully to the Production system, and I didn’t think any more on it. Fast forward a few months, and a colleague is modifying the same code for a different project. He was experiencing some odd behavior in the code that he couldn’t explain. He pulled in the client and me to look at it, and none of us could figure out what was happening. The phase that was running on the unit module that contained the control module with the composite that we had both updated would not run successfully the first time through the code, but if manually manipulated, the phase would run as expected subsequent to that first pass through the logic. We troubleshot the issue by first reinstalling the code without my colleague’s changes, assuming that would fix things. It did not. We were flummoxed. Since my colleague’s logic needed to be used in Production, the client indicated that it was acceptable to put on the Production system, attributing the odd behavior as a Development system issue. Upon doing this there were no issues running in Production. Although grateful, we were doubly flummoxed now. Clearly the issue lies in the Development system, but where? Trying to Uncover the Mystery Flaw in the Control System Further investigation discovered a yellow question mark (which generally means some sort of error) on a CALC (calculation) block that was definitely not there when the initial code was verified. This also happens to … Continued
