SA InfoZoneTrends Secondary Equipment

Hi colleagues !
What is the correct way to add secondary equipment parameters to primary equipment faceplate trend zone? 
  • Hi Petr,

    I am not too clear what you mean by "Secondary equipment parameters".

    Do you mean the Trends from the secondary equipment (as indicated by selection adorner)? Or do you want to display the values of Equipment Runtime Parameters from the secondary equipment?

    Could you explain what you are trying to achieve? (I assume this is for use with a group type object like a MEO enabled drive, Polarstar?)

    cheers,

    bradley
  • Hi Bradley !

    To speak more precisely, our Meters and ControlValves are separate DFBs with separate DDT data structures at PLC level. This leads to create two equipment types: one for Meter with PV and SP items and one for ControlValve with OP and FB items.

    What i'm trying to achieve is to combine two equipment types in one common faceplate. For tags i've used SecondaryEquipment association built-in selection adorner. For trends it seems to be more complicated since _InfoTrend_PALoadTask function doesn't support secondary equipment. Probably there is a trick how to create an alias to avoid direct cicode modification and also to avoid Meter and ControlValve binding at equipment database level.

    Actually there was a nice feature in LibEquip, where we could configure an individual .pav file for each equipment, which would load if file exist.

    BR

    pf

  • Hi Petr,


    Aah ok understood. The workspace does not support this scenario. The reason for this is that the Alarm, Trend and Interlocks zone show content for a single piece of equipment only - the context of the system.

    The only suggestion I have to avoid writing your own info zones, is whether you can create an equipment template which contains the signals from both DFB's (especially if they are tightly coupled). You can then still use this same piece of equipment with a Valve Comp Genie and/or a Meter Comp Genie as all they care about are the items they need for the options you have selected are available.

    As for the LibEquip, we intentionally moved away from this such that the context system is consistent, but also it means we have a single configuration model for which trends are displayed when a piece of equipment is brought into focus.

    cheers,

    bradley
  • Hi Bradley !

    Thanks a lot for your explanation and suggestion. Apparently this was my design mistake, have to think about the workaround solution. As far as basic projects become more and more complicated to customize, we have to be more attentive to restrictions they have. On the other hand you have to go deep into the code to understand how it works.

    BR
    pf