Coil Validation Setup
This page covers the implementation and configuration of coil validation — where the coil lookup actually happens and how to set it up. For the operator-facing concept (the two-step flow, override behavior, and XL controller parameters), see Coil Validation in Core Concepts.
When an operator loads a coil, the XL controller sends the coil serial number and Eclipse looks up the coil's material code (plus remaining length, lbs/ft, and user fields where available) and sends it back. There are two independent decisions in how that lookup is implemented:
- Which product answers the controller — Eclipse Classic or Eclipse Pro. Exactly one of them owns validation at a time (see Ownership below).
- Where the coil data lives — a local coil inventory maintained inside Eclipse, or a live on-demand SQL query against your ERP/inventory database at the moment the coil is entered.
That gives four supported configurations:
| Local coil inventory | On-demand SQL lookup | |
|---|---|---|
| Eclipse Classic | Validates against the local COILS table (populated by Table Import or manual entry) | Classic SQL Coil Validation — live ODBC query per coil (below) |
| Eclipse Pro | Validates against the coil inventory populated by Coil Sync | Pro On-Demand Coil Validation — live query via an External Connection (below) |
Eclipse Pro also supports ERP-specific validation implementations (e.g. NetSuite and Dynamics 365 connectors) built on the same on-demand mechanism. These are configured per-customer — contact AMS Controls.
Choosing a strategy
On-demand always reflects the source database at the moment the coil is loaded — there is no sync lag and nothing to keep in sync. The trade-off is that the database must be reachable from the plant floor system at coil-load time; if it isn't, coils cannot be validated until connectivity is restored.
Local inventory (Coil Sync in Pro, table import in Classic) validates instantly against a local copy and keeps working through network or database outages. The trade-off is sync latency: a coil received moments ago may not be visible until the next sync cycle. In Eclipse Pro, the local copy also powers inventory screens, the warehouse app, and reporting — so many sites run Coil Sync regardless, and the choice is only about which source validation reads from.
Ownership: Classic or Pro, never both
On a system running both products, only one of them may answer the controller. Ownership is recorded in xlwin.ini:
[XLCommon]
ProCoilValidation=T
F(or absent) — Classic owns validation; Pro's validation service refuses to start and reports "Pro coil validation not allowed because Classic validation is enabled."T— Pro owns validation; Classic yields.
You normally never touch this flag directly:
- Enabling coil validation in Eclipse Pro automatically disables it in Classic — the server detects the conflict and sets the flag for you.
- The Eclipse Agent status page shows which side currently owns validation (Coil Validation: Pro / Classic) with a button to switch back.
- If the flag says Pro owns validation but Pro validation is disabled, Eclipse raises the alert "All forms of coil validation are disabled" so the plant isn't silently running unvalidated.
Even when Pro owns validation, the response still reaches the controller through Classic's XL-COMM program — Pro performs the lookup and hands the result to XL-COMM for transmission. XL-COMM must be running in either configuration.
Eclipse Classic: SQL Coil Validation
Classic's on-demand mode replaces the local COILS lookup with a live ODBC query. When a coil serial number arrives from the controller, XL-COMM connects to the configured DSN, runs one query (or stored procedure call), sends the result to the controller, and disconnects. A fresh connection is made for every validation, so credential or network changes take effect immediately.
Enabling
Coil checking itself is turned on with the Verify coils when loaded setting (Settings → General → Controllers). Switching the lookup from the local COILS table to an on-demand SQL query is done with the XL SQL Setup utility — always use the utility; the connection password is stored encrypted and can only be set through it. In XL SQL Setup you provide:
- The ODBC System DSN, user ID, and password for the source database
- The table or view to query, or the name of a stored procedure to call instead
The query issued is:
SELECT * FROM <CoilData> WHERE <CoilNumberField> = '<serial>'
-- with an optional branch/plant filter:
-- AND <BranchField> = '<BranchName>'
or, in stored-procedure mode:
EXECUTE <GetCoilData> '<serial>'
Any ODBC source works; XL-COMM automatically adapts quoting for known drivers (e.g. PostgreSQL).
Field mapping — coil_verify.ini
Column names in your table or procedure result are mapped in a separate coil_verify.ini file (in the XL-COMM program directory), section [CoilVerify]:
| Key | Default | Purpose |
|---|---|---|
Coil Number Field | INVCOIL | Coil serial number (matched against the entered serial) |
Material Field | MATERIAL | Material code returned to the controller |
Status Field | STATUS | Coil status; C marks the coil complete |
Length Remaining Field | REMAINING | Remaining length |
Lb per Ft Field | (none) | Pounds per foot, sent to the controller when mapped |
Heat Number | (none) | Heat/lot number, recorded with production history |
User 1 / User 2 | USER1 / USER2 | Custom fields, sent to controllers with newer firmware |
Branch Field / Branch Name | (none) | Optional plant/branch filter added to the WHERE clause |
CoilNumberMacro / CoilStatusMacro | (none) | Optional FoxPro expressions to transform the serial before querying, or the status after |
Outcomes and messages
| Situation | Behavior |
|---|---|
| Coil found, active | Material code (and lbs/ft, user fields) sent to the controller; "OK to run" message shown unless Disable coil OK to run message is set (Settings → General → Controllers) |
| Coil found, complete | Controller told the coil is invalid; "shows as completed" warning |
| Coil not found | Controller material stays blank; warning that the coil does not exist in the SQL data (message 10109) |
| Coil already in use on another machine | Warning identifying the other machine |
| Cannot connect to the DSN | Warning 10297; validation is retried |
| SQL error running the query | Warning 10298; details appended to Error.txt in the data directory |
| Data source fails verification (missing table/fields) | Warning 10299 |
:::warning No fallback
CoilSQLServer=T fully replaces the local COILS lookup — if the SQL source is unreachable, Classic does not fall back to the local table. It warns the operator and retries.
:::
The material match itself (coil material vs. order material) is enforced by the XL controller when the operator starts the machine; Eclipse's job is to supply the trusted material code for the loaded coil.
Eclipse Pro: On-Demand Coil Validation
Pro's equivalent is the Database Coil Validation integration, configured in the web UI under Settings → Integration → Coil Validation, on top of a shared External Connection:
- External Connection — the database connection (SQL Server, PostgreSQL, MySQL, Oracle, DB2), optionally carrying a Plant Code.
- Table or view name — what to query. Unlike Coil Sync, you do not write the SQL yourself; Pro issues:
SELECT * FROM <TableOrViewName> WHERE INVCOIL = @serial
-- and, when the External Connection has a Plant Code:
-- AND SQLPLANT = @plantCode
Column requirements
The table or view must contain INVCOIL and MATERIAL (case-insensitive, same as Coil Sync). This is verified when the configuration is saved, so a missing column fails fast rather than at coil-load time.
Additional columns are used when present:
| Column | Purpose |
|---|---|
STATUS | Coil status, passed to the controller response |
REMAINING | Remaining length (ft) |
LB_FT | Pounds per foot |
USER1, USER2 | Custom fields, sent to controllers with newer firmware |
The query must return at most one row per serial (per plant, when plant-filtered). Duplicate serials in the source cause a lookup error, not a silent first-match.
Behavior
- Valid — the material code and coil details are sent to the controller (via Classic XL-COMM), and the operator sees a confirmation message. If the coil doesn't exist in Pro's local inventory yet, a temporary coil record is created so production can be tracked against it.
- Not found — the controller is told the coil is invalid and the operator sees a "coil was not found" message.
- Lookup error (connection down, duplicate rows, …) — the operator sees "Error loading coil … See Eclipse", and the validation is retried automatically; a not-found result is final, an error is not.
Testing
The configuration page includes a test dialog: enter any coil serial number and see exactly what a controller would get back, without loading a coil. Use it after initial setup and whenever the source view changes.
If you already run Coil Sync and only need validation against that synced inventory, you don't need an on-demand configuration at all — that is the default validation mode. On-demand is for sites that want validation to hit the source database live.