In the past, at our plant, we have used the sim enable feature as part of a process to allow us to manipulate or pre-scale the field value before running it through the final analog input block.
The process is something like this:
In this example, we're using a pressure pad to give us a tank level and the calc block lets us calculate the percent of the tank level (out 1). Then we take that percent as the AI1 input and scale it to feet.
We don't always have a calc block between the two AIs. However, we always have AI2 pull the value in from the field device and perform a preliminary scaling before going to the AI1 block. Our display templates are set up with AI1 as the displayed block on the operator screen.
I am curious if anyone else has come up with a way of doing something like this without the need to use the simulate_in parameter. This method causes alerts/anomalies in the diagnostic area on the detail display.
In turn, I get notified about errors that are not really errors because in the past someone created the control module to operate in this way.
I will be happy to provide additional information if I am able to do so. Thank you for your time in reading this post.
-Brent
Excellent question. I've seen various approaches in the past.
There have been several versions of a composite block, sometimes referred to as a PSUEDO_AI, where the block has been constructed with all the parameters of an AI block, thus allowing it to function with the defined Display dynamos and such. In one implementation of the PCSD library, this PSEUDO_AI actually consumed more than 5 times the CPU of the AI block itself. And since it was used primarily with Soft Tags from Modbus Datasets, the controller would take a hit on CPU loading due to the serial data integration.
I'd suggest that a PSEUDO_AI composite block can be built with minimal functionality to align with the display dynamos, and not necessarily execute logic for things like Block Error. You would create a Faceplate and Detail faceplate for these modules since they are different from a straight AI based module. Basically, just stripping out the added features of the AI, like Simulate, XDScale, L-type, etc. This block takes a treated value and possibly rescales it for display. Another aspect of this is to use the Scan Multiplier on embedded features so that block uses less CPU overall.
The challenge comes with Alarming. The PSEUDO_AI would have used an ALM block and have the alarm parameters elevated in the Composite so the module alarms would reference paths like AI1/HI_ACT.cv.
A more simple approach is to tread this as a calculated value and just use an ALM block as your AI1. However, the ALM block does not have an OUT parameter. You could create a similar Dynamo for AI references and use these in displays, displaying the AI1/PV, where the ALM block is called AI1.
The ALM block gives you the alarming and scaling that you are looking for. The PV value can be exposed as and output to connect to downstream blocks. There is no need for Low Cutoff as this can be done in the CALC block or the initiating AI block. L-type does not apply as the value is currently simulated, which bypasses these functions. If available, it would be set to direct or direct independent.
The ALM block does not support MODE, and for a calculated value, is this needed?
I think of the ALM block as my Soft Tag input. It can be tied to an IO channel, such as a Dataset/register, or to the EIOC Logical device signals. With the change in licensing of v12, reading Serial data directly in control modules does not incur additional DST licensing so one could use either ALM or AI blocks to read registers that require scaling. For process values, I would use the AI block in v13 or v14, where I might need some of the block's additional features. For internal calculated values, the ALM block works well.
Andre Dicaire