I have a table in a protocol that will only ever have one row based on how we use standalone Rack PDUs and don’t cascade them.
In the active alarms a table column parameter will have the index or display key suffixed to the parameter description. This makes the parameter description confusing by suffixing the 1.
I read through this post here
Alarm console displaying interface index instead of Interface Display Key [IDX]
and attempted to use either:
<NamingFormat><![CDATA[; ]]></NamingFormat>
or
<ArrayOptions index=0 options=”;naming=/”>
or other attempts playing around with the above.
But no success from those attempts which I was kinda expecting due to “A display key must not have leading or trailing whitespace.” and I was trying to set a display key with only white space.
Also had a look at information templates but they didn’t seem to be able to mask the index either.
Is there anyway to avoid a table index being show in the active alarms and just have the raw column description?
The best alternative I can think of is to scrap the table completely and just make static parameters instead.
Hi Sam,
As far as I know, there is no way of doing what you wish.
You have a few ways to define the DisplayKey of a table but all of those are designed to have content to make identifying each row easier.
And that is what also gets used in alarms for the same reason so that you can easily tell to what entry the alarm corresponds to.
The options I see that you could try are to either have a separate column on that table that you would use to set a more meaningful value and have that appear on the alarm or to have that table converted to standalone parameters given that you only have 1 entry.
The caveat of this last option is that it is only really feasible if that connector would only ever have 1 possible entry on that table. As soon as it can have more than 1 it no longer makes sense.
Hi Sam,
Checking the device, it seems that this specific model supports only two sources:
https://www.cyberpowersystems.com/product/pdu/switched-ats/pdu44004/
This means that your proposal of using single parameters makes sense. We could keep using a table if:
- You expect more than 2 sources (looking at the hardware of this specific model, it seems that this is not possible)
- This connector is used by other models, and these models support more than two sources. Checking quickly other models, it seems that the main difference is the voltage/current that the device supports/provides, not the amount of sources. However, I didn’t go into the details to confirm this statement.
Hope it helps.