Control.com - Nerds in Control

We are using a third-party driver to subscribe for periodic data on a MarkV B. Alarms are getting generated continuously whenever a subscription or unsubscription is done (even for one single point). Here is a list of some alarms:

30-DEC-2007 12:04:51.000 S1 1 C 0004 DIA DCC BMS: request size max pool size
30-DEC-2007 12:04:51.000 S1 1 C 0010 DIA DCC DPM: no BMS memory for isr
30-DEC-2007 13:34:09.000 T2 1 C 0010 DIA DCC DPM: no BMS memory for isr
30-DEC-2007 13:34:09.000 T1 1 C 0004 DIA DCC BMS: request size max pool size
31-DEC-2007 11:08:13.000 T1 1 C 0004 DIA DCC BMS: request size max pool size
31-DEC-2007 11:08:13.000 T1 1 C 0010 DIA DCC DPM: no BMS memory for isr
31-DEC-2007 11:10:44.000 T1 0 C 0004 DIA DCC BMS: request size max pool size
31-DEC-2007 11:10:44.000 T1 0 C 0010 DIA DCC DPM: no BMS memory for isr
31-DEC-2007 11:17:58.000 T1 1 C 0004 DIA DCC BMS: request size max pool size
31-DEC-2007 11:17:58.000 T1 1 C 0010 DIA DCC DPM: no BMS memory for isr
31-DEC-2007 11:19:51.000 T1 0 C 0004 DIA DCC BMS: request size max pool size
31-DEC-2007 11:19:51.000 T1 0 C 0010 DIA DCC DPM: no BMS memory for isr

Besides the third-party driver, there is an HMI and a historian polling the same unit, could this be caused by a load on the MarkV controller?

What could be the cause of these alarms?

Basically, the alarm tends to indicate some memory allocation issues in the C Core DCC, do you know if reading from another core (control processor R,S or T) will be of any help in this case?

Thanks in advance.

What is the percentage of C core processor utilization?

C core is the communication core and the only location for Mark V communication via stage-link.

When the C core processor is overutilized, errors will occur. Check C core processor utilization before and after the connection to your third-party software.

DPM means Dual-Ported Memory; DCC means Drive Control Card (the main microprocessor card in the Mark V processors); BMS means Basic Message Service.

These errors are typical of poorly formed requests, requests for data which does not exist, requests for excessive amounts of data, or requests for data at extremely fast rates. What's an excessive amount of data? That depends on how much data is being requested, what data is being requested, and how frequently the data is being requested. Most people who try to write drivers for data from any proprietary control system think that they need every piece of information that's available as fast as it can be obtained. I'm always amazed why people need to read the values of Control Constants, for example, and every Control Constant at that.

Unfortunately, there's no method for determining when the "limit" is being reached, except the error messages like the ones you are experiencing. Data-gathering, especially from a Speedtronic turbine control panel, is a compromise. Someone has to sit down and go through the lists of data being requested and decide what's critical and what's not. While it would be wonderful if data for every point could be captured at the fastest possible rate in the event that some obscure value would be available for trending or review in the event of some possible problem, it just isn't possible with the Mark V.

Most GE Mark V HMIs have CIMPLICITY Projects which are very poorly configured, and the nature of GE Mark V HMIs requires that the HMI request data for every point in the project, regardless of whether or not that data is used on any display or for any purpose, and to request that data at least once per second. Historians are only slightly "better" at their data requests (for some unexplained reason), but an HMI and a Historian are probably already taxing the <C> core at or near it's limit.

You could probably request data from other processors, but that data would be prevoted data, and the request(s) would have to go through <C>. About the best thing in your case would be to try it and see what happens.

Can you tell us who makes the driver you are using?