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.

In the PI Connector for FANUC Focus, each data source has the IP address of the related machine specified. The "Device ID" is also part of the configuraiton. If a Device ID is not specified, the IP address is used as part of the Device ID and ends up becoming part of the AF hierarchy as well as the PI point names.

If a user goes to change the IP address for an existing data source, and the default Device ID is being used, they will inadvertently create a second set of PI points (Duplicates, orphaning the original PI points which already have data, potentially) and a second AF hierarchy (Again orphaning the original AF hierarchy).

The UI should give a warning when saving the configuration explaining the consequences of changing the IP address for an existing data source if the default Device ID is being used.