Equipment Help in SA Templates

I'm currently configuring a new system and need a little advice. I am using the SA templates and have run into a cross roads. Let's start with the simple Meter, this make complete sense when you have a single element analog value with a single PV. But what if you have a dual element RTD, how would you configure this. A Meter type instance for each RTD element (A and B)? How would the selected or averaged value be handled as it's own PV? What if the averaged value is the only one that has the LL L H HH alarms, and even a high difference and other custom alarms?

It seems like with the example above, I would need 3 Meter type instances, two for each element and one for the averaged value and it's custom alarms. How would you tie them together in the project so the the trend window in the info pane shows all three PVs?

TIA.

Chris

  • Hi Chris, maybe you can use something like this:

    1. Define an item (INT) for selecting the type (0=average, 1=RTD1, 2=RTD2). You can add this item to your faceplate with the appropriate privilege to change.
    2. Add RTD1, RTD2 as your input items
    3. Add AvgRTD, the avgRTD (calculated variable) should have something like : (RTD1 + RTD2) / 2 in the address field
    4. For the PV item define a calculated variable item and call the following function:

    PUBLIC
    REAL
    FUNCTION
    GetPV(INT iChoice, REAL RTD1, REAL RTD2, REAL rAvgRTD)

    REAL rReturn;

    SELECT CASE iChoice
    CASE 0
    rReturn = rAvgRTD;
    CASE 1
    rReturn = RTD1;
    CASE 2
    rReturn = RTD2;
    END SELECT
    RETURN rReturn;
    END

    5. You can modify the [Workspace]InfoZoneTrends.TargetMeter parameter to add RTD1, RTD2 and the AvgRTD to th trend window

    Not sure if this could fulfill all you needs.
  • Hi Chris,

    A bit to digest there.

    A couple of questions:
    1. Is the RTD a single piece of equipment with 2 signals? Does each signal have (or need to have) more information such as practical range, optimal range, independent alarm limits etc?
    2. Ideally how would you like it displayed to the operator on the screen?
    3. Can each signal alarm? or just the synthesized average?

    To give you an idea of what could be done, I'll make the assumptions of:
    1. a single piece of equipment with two signals A and B and a synthesized Average signal - PV
    2. Only the Avg signal has alarm limits and will alarm.

    One technique you can do is create a custom meter template, based on our template. Use the PV item as your Average by changing it to a calculated variable and doing the avg between A and B. Create two additional variable items APV and BPV for your A and B signals. I name that to take advantage of the "prefix" feature of the meter composite genie templates. You can enable PLC based alarm limits for your PV (Average) if you don't want to use analog tag.
    On a page you can drop down the standard meter, configure it as temp if you want. By default it binds to an item called PV. Alarms will trigger when the avg of A and B meet your defined limits of your PV variable. To get all 3 trends displaying I nthe info zone, configure the InfoZoneTrends parameter has Bas mentioned. InfoZoneTrends can be configured in 3 ways (the help only mentions 2 ways.. sigh) You can set it globally, by type or for a specific equipment instance. as the help describes how to do the fist two, I'll describe how to do it per equipinstance. Add a new Runtime Equipment Parameter via Citect Studio (System Model > Equipment > Runtime Parameters). Set the Cluster, Euipment field. For the name field specify "InfoZoneTrends", for the value specify "PV, APV, BPV" (no quotes). set "IsTag" to false.
    You can then tailor a faceplate by adding all three values, or even set up meters on the faceplate for each signal . Use the prefix field on each composite to do that. (if you used the prefix pattern for your signals)

    If you wanted to display the values of all 3 signals at once on a page, well you can consider using the meter_multiple composite genie. this is where item prefixing also is essential. Set every equipment field to the same value. Leave item prefix #1 blank. Set Item prefix #2 as A, and item prefix #3 as B. To do this though, without compilation warnings of missing tags, you will need to set up PRLow, PRHigh, TrackDsp and ORDsp tags for A and B, e.g. APRLow, BPRLow. The meters require these tags at minimum to operate nicely.

    Cheers,

    bradley
  • Thanks, Bas. Not quite, but it gave me some additional things to think about for sure. Everything that you have suggested makes sense to me.

    I didn't know the we had that parameters though, the help isn't the best!

    Thanks again,

    Chris
  • Bradley, thanks for the very detailed reply.

    It does get a bit more complicated.

    Answers to your questions,
    1. Basically yes, the RTD (lets call it TE_101) in my example is a single temperature measurement with two elements, A and B. The additional info we need is an alarm for the A and B elements is the sensor failed alarm(one for each element).

    2. The PV of TE_101A, TE_101B, TE_101SEL should all be seen on the page. In some cases it could be TE_101A1, TE_101A2, and TE_101SEL. The reason that there is sometimes a slight difference in the suffix of the elements is because there are cases in which two dual element RTD sensors are used. In that case, it would be TE_101A1, TE_101A2, TE_101B1, TE_101B2 and TE_101SEL. This is rare but cases still occurs for time to time. I would probably just use a different equipment meter type for the differing scenarios.

    3. For the individuals elements, they only have a senor fault alarm. The "SEL" PV is normally averaged(only if the A and B difference is below a certain theshold) in the controller and has PLC limit alarms applied to it. Its called SEL because it is the Selected PV in the control being used as the most trusted PV for the application. The controller has a High Diff alarm between the elements too, when this occurs, it could select the highest or the lowest element PV, again depending on the application. Oh, and to add even more complexity to this, the SEL PV may only have H and HH alarms, OR L and LL alarm but not both usually.

    I have already setup my project to use PLC alarm limits, that all we use. In cases where we may only need a low alarm, we just set the low low limit to the zero EU value in the PLC.

    Your reply has a wealth of information in it and I hope to work out my issues from this point. There are many other challenges ahead on this project, so I'll probably be asking more questions.

    Thanks again,

    Chris
  • Hi Chris,


    Yep, OK, then I would definitely go with the approach of using a custom meter template, with the default PV being your "SEL". Given your statements above, this would bind to the controller itself, as you have complex logic dictating its behaviour. A and B can just be additional signals, and I would take advantage of the prefix feature so its easy to bind up to meters. It looks like Practical range and Optimal range would be the same for all signals, so you could define the extra ones for your A and B signals as calculated variables and just point them to your main PV's OR and PR's -to save any need for configuration.
    You can set up individual fault alarms on APV and BPV, and there is no problem putting a high diff alarm either on PV. These will all show up in the Info Zone etc. You could also set up a bit to indicate which is active source for SEL and put that on the faceplate.

    The trickiest part I see here is the alarm limits on SEL. Are they dynamic? Or is it a case that one instance would use LL, L and another instance H, HH? If they are not dynamic, then you can either create two template types - or override per instance.
    If they are dynamic, then I think that might be a trickier, mainly at the presentation layer of the composite genies. In general the limit markers are driven from the configuration of the workspace DefaultPLCLimits parameter or the PLCLimits equipment runtime parameter. Eq runtime params cannot be override at runtime. The one thing I would point out is that if you only need, say, upper alarm limits, then use the value of -1 to stubb out the lower limits. This is currently not documented, but we fixed that for 2018 R2. For PLC Alarm Limits, we have re-written the help for this topic for 2018 R2 as we found people were struggling with it.

    In terms of parameters for workspace (SA) projects checkout the topic : Parameters > Parameter Reference > Template Parameters > Situational Awareness Parameters.

    Cheers,

    bradley
  • Bradley, thanks again for the additional info. I think I have enough to experiment around with a few different things.

    Thanks,

    Chris