PJM locational marginal price (LMP) data reaches a PI System by one of three routes, and your site's existing infrastructure decides which: market participant access to PJM's data page, the Data Miner 2 site feeding a UFL interface, or an active ICCP link into your EMS/GMS with the points forwarded to PI from there. The operator sees a price tag with no value, a flat line, or a stale timestamp. The checks below trace that back from the trend to the source, in order.
Which of the three LMP paths fits this site?
| Path | Prerequisite | PI-side component | Choose it when |
|---|---|---|---|
| PJM data page pull | Market participant access to PJM's data pages | Downloaded file parsed and loaded into tags | You need periodic or historical loads and have no EMS link |
| Data Miner 2 | Access to the Data Miner 2 site | UFL interface; an HTML-based interface is a possibility to validate with your PI vendor | You have no ICCP link to PJM market systems |
| ICCP into EMS/GMS | Active ICCP connection to PJM market systems, LMP points already in the EMS/GMS database | Whatever interface your site already uses to read EMS/GMS points into PI | LMP already exists in the EMS/GMS |
When two paths both work, take ICCP. The EMS/GMS has already handled the association, the data set, and the quality flags, so PI needs no external polling and no parsing. Fall back to Data Miner 2 through UFL when the EMS does not carry LMP. Confirm the exact PI interface configuration and environment with your PI vendor's technical support.
Check 1: Is LMP already updating in the EMS/GMS?
Open the LMP point on an EMS/GMS display and read its value, quality, and update time. Then compare with the PI tag.
| EMS/GMS reading | PI tag reading | Meaning | Next |
|---|---|---|---|
| Updating, good quality | Stale or flat | Binding fault between EMS/GMS and PI | Check 4, then the EMS-to-PI interface log |
| Stale or bad quality | Stale | Fault upstream of PI: ICCP association, data set, or PJM side | Take to the ICCP administrator; PI changes will not fix it |
| Point does not exist | No tag | No ICCP delivery of LMP at this site | Check 2 |
Check 2: Does your account have PJM market data access?
Log in to the PJM data page and to Data Miner 2 with your site's credentials and pull one LMP report by hand. If both return data, the source side is proven and the remaining work is the PI side (Check 3). If access fails, the fault is an entitlement or account issue with PJM as market operator. No PI configuration can pull data your account cannot view. Resolve access first.
Check 3: Does the UFL interface parse what Data Miner 2 delivers?
UFL reads a file or stream, splits it into fields according to its configuration, converts the timestamp, and writes each value to a tag by name mapping. Any mismatch between the source layout and that configuration produces a silent gap rather than a loud fault. Read the UFL interface log first, then match the symptom:
| Symptom on screen | Layer | Likely cause | Where to look |
|---|---|---|---|
| Tag never receives a value | Parsing or tag binding | Header row, delimiter, or field count differs from the config; point name in the config does not match a tag | UFL log for parse and point-not-found messages; compare the sample file to the field definitions |
| Some nodes update, others do not | Tag mapping | Location identifiers in the file have no matching tag | Tag list versus the location column in the downloaded file |
| Values arrive but timestamps are hours off | Time conversion | Source time zone differs from the zone the config assumes | Timestamp column in the sample file versus the config's time format and zone |
| Feed stops after a source change | Source format | Report layout or file naming changed | Fresh manual download versus the config |
Separate the two fault classes before editing anything. A tag fault means the tag exists but stores the wrong thing. A binding fault means the value never reaches the tag. Parse errors and point-not-found log entries are binding faults. Fix them in the interface configuration, not in the tag attributes.
Check 4: Why do LMP values arrive in PI but look wrong?
| Observation | Setting or location | Effect |
|---|---|---|
| Price spikes missing from the trend | Compression and exception deviation on the tag | A wide deviation drops short excursions; size it against $/MWh price moves, not a generic engineering-unit default |
| Negative prices never appear | Point type and zero/span | LMP can go negative; a tag with limited range or the wrong type clips or rejects it |
| Hourly and interval data mixed in one tag | Tag-per-product design | Day-ahead and real-time LMP have different intervals; give each its own tag |
| Values land at the wrong time | Interface time zone and timestamp column | Shifts every sample by a fixed offset, including across daylight-saving changes |
How do you bring the Data Miner 2 feed online and prove it?
- Pull one LMP report by hand from Data Miner 2 and save it as the reference sample. Record the delimiter, header rows, timestamp format and zone, and the location identifier column.
- Create one tag per location and product (day-ahead versus real-time), with a point type and range that admit negative values. Set compression from expected $/MWh movement.
- Write the UFL configuration against the reference sample: field split, timestamp conversion with the correct zone, and the field-to-tag mapping. Use the interface's own documentation and your PI vendor's technical support for syntax.
- Run the interface against the reference sample only, and read its log for parse and point-not-found messages. Clear every one before connecting a live source.
- Connect the live Data Miner 2 output and let it run through at least one full update cycle for each product.
- Compare the last five archived values and timestamps for each tag against the same rows on the Data Miner 2 page. Values must match to the source's displayed precision. Timestamps must match once the time zone is accounted for.
FAQ
Why does my PJM LMP tag flatline while PJM shows new prices?
The value is not reaching the tag. Check whether the point is updating in the EMS/GMS (ICCP path) or whether the UFL log shows parse or point-not-found messages (Data Miner 2 path). A tag that holds its last value is a binding fault, not a compression fault.
Why does the PI trend show LMP timestamps hours off from PJM's page?
The interface time zone setting does not match the source timestamp column. Read the zone the source uses in the reference sample and set the UFL time conversion to match it, then re-test across a daylight-saving boundary.
Why does UFL write nothing after I point it at the Data Miner 2 output?
The file layout differs from the field definitions in the configuration, or the configured point names match no tag. Compare the delimiter, header rows, and field count in a fresh download against the config, and read the interface log for the rejecting line.
Why does my LMP tag never show negative prices?
The tag's point type or range clips negative values, or compression is discarding them. LMP can be negative, so use a floating-point type with a range that includes negatives and confirm the archive by querying a period when the source showed a negative value.
How do I confirm the PI archive matches PJM's published LMP?
Pull the last five samples for each tag from the PI archive and compare value and timestamp row by row against the same rows on the Data Miner 2 page, allowing for the source time zone. Any row that differs points to a mapping, zone, or compression fault on that tag.