The Pi Connector for GE e-terraHabitat systems was apparently only written to support GE's Electrical SCADA systems (EMS/DMS) that are based on e-terraHabitat. They also have Oil & Gas Pipeline SCADA systems, also based on e-terraHabitat, known as "ETPL" (e-terraPipeline), which have a slightly different record structure for POINT and ANALOG records. Both expose their data via GE's SAMPLER technology, which at a basic level works the same for both types of SCADA systems, the difference is in the record structure related to POINTS and ANALOGS that is slightly different for each system.

The existing Pi Connector would need a minor tweak to also be compatible with the ETPL systems.

Currently, when the connector sees that I'm requesting an ANALOG record, it also attempts to read in a set of ANALOG record master data known as ALGNAM (analog name) records. The record structure for EMS/DMS systems has an ALGNAM description stored in a field named TEXTALGNAM. But the equivalent fieldname in the ETPL system is DESCRIPALGNAM. Unfortunately, when the TEXT_ALGNAM field is found to not exist, the Pi Connector stops reading any additional data. This should be a simple text-string change in the Pi Connector, for ETPL SCADA systems only.

Similarly, when it sees I've requested a POINT record, it tries to read POINT record master data from PNTNAM records. Here, there's a bigger gap in functionality. The EMS/DMS system tries to read TEXTPNTNAM, which should map to DESCRIPPNTNAM for an ETPL system. But it also tries to read a set of 4 TEXT##PNTNAM records, which would contain the 4 possible statenames in an EMS/DMS system. In the ETPL system, these fields don't exist; instead, the PNTNAM records each have a series of child records named DITEXT; and each DITEXT record defines one possible STATE. This would be a more complicated change, involving a request for all defined DITEXT records, and then parsing out the PNTNAM from the resulting composite keys, and then building the required digital state sets with variable quantities of states (2, 4, 8, or 16) and populating them with the IDDITEXT values.

Attaching pictures showing the record structure that exists in the ETPL system, and the errors encountered when attempting to read from an ETPL system.

Note that I worked with GE to test a temporary workaround involving the creation of dummy fields in the ETPL system that line up with the EMS/DMS system. But making this permanent would require re-compiling our SCADA system with the database schema update in place. It would also not have any valid data in the fields, so the resulting Digital State Sets would all have Null field values, and the descriptions would all be null as well in the Pi database.

The PI Connector for e-terraHabitat HabConnect SAMPLER pulls tag descriptions from the PNTNAM and ALGNAM records. For Oil & Gas e-terraPipeline (a.k.a. ETPL or "LMS") customers, the DESCRIP field on those records are usually left blank, or they have a very generic value. The description for new Pi Tags created by this connector should come from the individual POINT or ANALOG records instead. This information was confirmed by a GE employee as being applicable to all current ETPL/LMS customers.

For my company, here are a couple of examples:

DESCRIPALGNAM = "# - Interface Level - #"
DESCRIPANALOG = "Cavern 1 - Interface Level - Water (Trend)"

DESCRIPPNTNAM = "# Valve #"
DESCRIPPOINT = "Manifold Valve T2"
DESCRIP_POINT = "DRA Discharge Valve DD1"

Please either: make it possible to configurably request DESCRIP off of ALGNAM vs ANALOG and PNTNAM vs POINT, or preferably, just assume that if we've configured for "DESCRIP" (which only applies to an LMS system) that we want the DESCRIP value from the ANALOG or POINT record.

Note - this likely means you don't even need to register for any ALGNAM or PNTNAM data, if DESCRIP is the only thing you're getting from those record types.