Resolving AI-1300 Object Not Found Error in Schneider Concept 2.6

1. Problem Summary

The AI-1300 "Object not found in database" error blocks project opening in Schneider Electric Concept 2.6 / 2.6 SR6 programming software. The fault fires when Concept's interpreter cannot reconcile a project database entry against the installed library definitions in CONT_CTL.DTY after an FFB substitution prompt is dismissed with Yes. Operators see two sequential dialogs:

1. FFB substitution prompt: "FFB 'PIDFF' was changed. Do you want to substitute all instances of old version?"
2. Database fault: "Object not found in database / Error Id: AI-1300"

The project browser never appears, the .PRJ is not opened, and no rollback is offered. The condition is recoverable without OEM involvement provided the original ASCII export (.asc) is intact.

2. Affected Software and Versions

The OEM archive in this case study contained the header line CP_VRS AI: 15.1 DBGEN: 14.0 Conv expand DATE: Tue Nov 20 11:29:25 2007 CONCEPT_2.2 SP2, identifying the source as a 2007-era Concept 2.2 SP2 project that had been exported through dbconv.exe to an ASC file before being zipped.

3. Root Cause Analysis

AI-1300 is not a database corruption error - it is an integrity check failure between two Concept subsystems:

1. The DTY-type library (CONT_CTL.DTY) that describes the structure, I/O signature, and version of every standard Function Block Function (FFB), including PIDFF.
2. The project database (*.PRJ, *.C0-*.C5, *.P1-*.P4, *.Qx, *.CCO) which references the FFB version that was current when the project was authored.

When Concept opens a project, it scans every FFB instance and compares it against the loaded DTY. If the FFB signature has changed (parameter name, data type, version stamp), Concept prompts the user with the substitution dialog. The user accepts the substitution, Concept writes the new signature to the project - but if the install is incomplete, the library file is missing or the FFB was deleted from the project file pool, the resulting object reference cannot be resolved against the in-memory dictionary, and AI-1300 is raised.

Three independent failure paths converge on the same symptom:

• Path A - Library absence: CONT_CTL.DTY is missing from C:\Concept\LIB\ or is a downlevel version relative to the FFB being substituted.
• Path B - Mixed-version project pool: The same project folder contains both a full set of binary files and a more recent .asc import, so the converter regenerates *.PRJ while older compiled sections remain in the directory.
• Path C - Ascending conversion skipped: The project was authored in Concept 2.1 / 2.2 and the user attempted to open it directly in 2.6 SR6 without first converting with the matching dbconv.exe from the older version. The "Version of project does not match" prompt is the upstream symptom; AI-1300 is the downstream symptom after a forced conversion.

4. Pre-Diagnosis Checklist

Run the following before any destructive operation. Record the output of each step.

1. Confirm version: Help → About Concept. Record the build string (e.g., "V2.6 SR6").
2. Inspect the ASC header: Open the .asc file in a text editor. The first line must read CP_VRS AI: x.x DBGEN: x.x Conv expand DATE: ... CONCEPT_x.x SPx. If it does not, the ASC was truncated.
3. List the project directory: A complete Concept project contains at least 16 binary files. The OEM archive in this study contained 18: .asc, .C0, .C1, .C2, .C3, .C4, .C5, .CCO, .DSK, .his, .JJJ, .P1, .P2, .P3, .P4, .PRJ, .Q1, .Q2.
4. Verify CONT_CTL.DTY: Confirm the file exists at C:\Concept\LIB\CONT_CTL.DTY and is non-zero length. Open it in Notepad and confirm the string PIDFF appears in the TYPE / STRUCT declarations.
5. Test a fresh section: File → New Project, create a section, press Shift+F, type PIDFF, place the FFB on the FBD sheet. If the FFB places cleanly without a warning, the DTY library is intact and AI-1300 is a project-specific corruption.

5. Recovery Path A - Clean Reinstall of Concept 2.6

Use this path when the local Concept install is suspect or when CONT_CTL.DTY is confirmed missing or corrupted.

1. Uninstall Concept through Control Panel → Programs and Features. Remove "Concept V2.6" and any "Concept V2.6 SRx" patches.
2. Delete the directory C:\Concept\ entirely. Do not rename - the install scripts reuse directory state if any residue remains.
3. Insert or mount the Concept 2.6 base media. Select Concept V2.6 basic during the install - the default "Typical" install includes only the IEC 61131-3 editor and the minimum library set; you need the Control library subset.
4. Apply the 2.6 SR6 patch in ascending order if your environment requires it.
5. Restart the engineering station. Verify C:\Concept\LIB\CONT_CTL.DTY exists.
6. Open Concept, run the test section step from Section 4 (item 5). If PIDFF places cleanly, proceed to Recovery Path B.

6. Recovery Path B - ASCII Export / Import via Concept Converter

The Schneider Electric Concept 2.6 User Manual documents the converter workflow in the Upgrade.pdf file installed with the product. The procedure forces a clean rebuild of every binary file in the project pool.

1. Create a fresh working directory, e.g., C:\Concept\RECOVER\<projectname>\. Copy only the .asc file from the OEM archive into this directory. Do not copy any .C*, .P*, .Q*, .PRJ, .CCO, .DSK, or .JJJ files.
2. Launch Concept Converter (dbconv.exe) shipped with your Concept 2.6 SR6 install. Choose Import ASC and point at the single .asc file in the new directory.
3. Select the target PLC family (Quantum 140 CPU 651 60 / Premium TSX P57 4634M / Momentum 171 CCS 760 00, etc.) matching the PLC that will run the project. The original PLC is identified by the CP_VRS line and the *.Q1/*.Q2 rack maps.
4. Click Convert. The converter regenerates a complete fresh project pool in the same folder: .PRJ, six section files (.C0-.C5), four parameter files (.P1-.P4), configuration files, and the .CCO cross-reference output.
5. Open Concept 2.6 SR6. Use File → Open Project and select the regenerated .PRJ in the recovery folder.
6. When Concept raises the FFB substitution prompt ("FFB 'PIDFF' was changed. Do you want to substitute all instances of old version?"), click Yes. With the fresh CONT_CTL.DTY in place, the substitution succeeds and the project opens cleanly. Click the Project Browser icon to confirm program sections are visible.
7. If Concept refuses to substitute at open time, click No to dismiss the prompt, then use Objects → Replace FFB to swap each FFB instance manually. Filter on the FFB name (e.g., PIDFF) and confirm the replacement version.

7. Recovery Path C - Manual FFB Substitution

Use this path when the converter refuses to regenerate, the ASC header is unparseable, or only the binary pool is available.

1. Create the recovery folder as in Section 6 step 1, but copy the entire binary pool from the OEM archive (skipping .asc).
2. Launch Concept 2.6 SR6 and open .PRJ from the recovery folder. When AI-1300 fires, click OK to dismiss.
3. Without closing Concept, use File → Open Section and manually open each section file (.C0, .C1, ...). Each section may trigger the substitution prompt independently. Accept each substitution.
4. Use Objects → Replace FFB from the main menu to substitute PIDFF (and any other flagged FFB) at the project scope. The dialog lists all instances of the FFB and the target version.
5. After all substitutions are accepted, run Project → Save As to write a fresh .PRJ. Concept will recompile the section pool and regenerate .CCO.

8. CONT_CTL.DTY Library Reference

CONT_CTL.DTY is the data-type library for the Concept Control library - it carries every regulation-block DFB / EFB definition used by IEC 61131-3 programs written in Concept. The PIDFF block (PID with Feed Forward) is the most commonly substituted FFB because Concept has issued four formal revisions of its control algorithm since 2.1.

If any of the above are missing, AI-1300 can also fire on FFBs other than PIDFF. Repeat the verification and substitution procedure for each missing FFB.

9. Project File Structure Reference

10. Diagnostic-to-Recovery Decision Matrix

11. Verification Steps

1. After recovery, open the project in Concept 2.6 SR6 and confirm the Project Browser lists all program sections.
2. Open each section and confirm no FFB instance displays the yellow caution triangle that indicates an unresolved library reference.
3. Run Project → Analyze → Cross Reference to regenerate the .CCO. Confirm it completes without error.
4. Run PLC → Connect and verify the online / offline comparison passes. A clean diff confirms the recovered project matches the controller's binary.
5. Download the project to the target CPU (or run in simulation mode) and exercise one PIDFF loop. Confirm the PV tracks SP and the CV output responds to step changes in SP.
6. Export the recovered project as a fresh .asc using File → Export → ASCII. This becomes the canonical interchange artifact going forward.

12. Prevention and Best Practices

• Always archive the ASC, not the binary pool. The ASC is the only version-stable interchange format. Binary pools are coupled to the Concept version that generated them.
• Pin the Concept install. Document the exact Concept version (2.6 SR6 build) and patch level in the project README. Reproducibility is impossible without it.
• Preserve CONT_CTL.DTY. Back up C:\Concept\LIB\ after every patch install. The DTY files are the single source of truth for FFB signatures.
• Refuse cascading substitutions. If Concept prompts to substitute more than two or three FFBs at open time, cancel, verify the DTY file, and investigate before accepting.
• Use a controlled converter workflow. When porting from Concept 2.1 / 2.2, retain a copy of the original dbconv.exe in a versioned archive directory. The 2.6 SR6 dbconv.exe cannot import a pre-2.5 project directly without an intermediate conversion step.