Abstract Classes

Hello Everyone,

A topic came up in a recent thread ( Interruption of module execution and synchronization of data) that reminded me of a problem we faced a few years ago. We had EM classes used widely, sometimes with different instrumentation (Profibus pumps having slightly different module classes, AI modules being FF or traditional). DeltaV is flexible to an extent, during EM instantiation you can bind a CM instance that's not of the same class like the placeholder defined on the EM class (placeholder in EM class could be class A, but you can bind an instance of class B during instantiation). However, there cannot be fewer input/output parameters in class B than class A. I think it's the same with alarms, there cannot be fewer alarms, although I'm not 100% sure, so I'll discuss just the parameters. This created a problem even with PCSD module classes, which, at least at the time, did not really facilitate this, classes of the same family would have different input/output parameters. Assume the EM is not using any of the "extra" capabilities that the module provides via its inputs/outputs, we just want to start/stop a motor and read a PV from an AI. Let's say:

- class A has param1

- class B has param1, param2

- class C has param3

If I build my EM class with class A as the placeholder, I can bind an instance of B. However, if I want to bind an instance of C, I need to add a dummy param1 in that class. We ended up having to "demote" input/output parameters to internal parameters, and in some cases having to add dummy parameters to all members of a family, if one member of the family had that parameter.

Did anyone face the same issue?

I was thinking this could be made easier by implementing something like abstract classes (https://en.wikipedia.org/wiki/Abstract_type). You'd build an empty CM class, containing just input/output parameters, no logic. The parameters would be the strict minimum, just the ones the EM class will use to operate the device, and shared by all devices that might be bound. This way you would facilitate interchangeability in the instances.

1 Reply

  • Istvan, Our library uses place holder Classes for embedded modules in classes, rather than a specific fully functional class. These would fit the description of a Abstract Class that you describe.

    Andre Dicaire