Hardware alarm indication

Hi Michael 

I've not seen the ability to turn a hardware alarm into a process alarm. Not saying it isn't possible, but it probably requires some scripting to achieve.

The way I've seen this achieved in the past is either through SNMPII driver comms to the end device, then configuring an alarm on top of that tag.

Another way is to configure an Advanced Alarm, with a call to a Cicode function that calls ServerInfoEx to get the remote I/O Server status.

Hope you find the solution you are looking for.

Kind regards

Olivier

I think Olivier's answer fits your issue the best.

Howerver, if you don't want to configure extra alarms you could also take a look at the Citect.ini parameter [Alarm]HwExclude.
This parameter filters out all hardware alarms you don't want to evaluate, leaving only comm-issues in the list in your case.

There are 2 downsides to this approach:
- Excluded hardware alarms are not presented anywhere anymore, including the standard hardware alarm page.
- You probably have to exclude a lot of alarm codes, maybe more than will fit in the parameter string

Usually, what I see is that customers create Advanced alarms to call IODeviceInfo() for each device. If you have redundancy or other complications, you may need to create a Cicode function to return the device's status. Here's an example for a redundant project:

//Returns TRUE if the specified device is not online on either the primary or standby server
//This can be called from a client or server
//
//sDeviceName Name of the primary or standby device
//
INT FUNCTION IODeviceOffline(STRING sDeviceName)
  INT cDevClientState = 3;
  INT cDevRunning = 1;
  INT cDevStandby = 2;
  INT cDevNumber = 11;

  INT nDevice = IODeviceInfo(sDeviceName, cDevNumber);
  INT nState = IODeviceInfo(nDevice, cDevClientState);
  INT bRunning = (nState BITAND cDevRunning) OR (nState BITAND cDevStandby);

  RETURN NOT bRunning;
END

It can also be helpful to create alarms for server processes as Olivier suggested.

Make sure to test your alarms. Sometimes you don't get the results you expect with these info functions. For example, IODeviceInfo may combine 2 or more states in the client state value. That's why my Cicode function uses BITAND to check for specific states.

Also, some modes may not work because you need to run the command from within the server process you're querying, or the code may need to block to retrieve data so it can't be used in foreground code, like an alarm expression. That's why I used IODeviceInfo mode 3 (client I/O device state) instead of mode 10 (I/O server I/O device state).