AI Designer works best when you treat it as a co-engineer: give it specific context, confirm each step, and correct it when it goes wrong. These five practices cover the areas where new users most often get stuck.
Role, Context, and Instructions
This is the single most reliable way to improve first-attempt results. Before describing your project, set the structure with three parts.
Part | What to include | Example |
Role | Tell Claude what it is and what it specializes in. | You are an automation engineer working in FrameworX by Tatsoft, specializing in SCADA systems. |
Context | Describe your solution: its name, structure, and purpose. | I have a bottling line solution called BottomLine with areas for filling, washing, and capping. |
Instructions | State exactly what to create or change, with all relevant specifics. | Create a device called Filler_PLC1 using Modbus TCP at 192.168.1.10 with tags for run status (Boolean) and line speed (Float). |
Once you set the role in the first prompt of a session, you do not need to repeat it. Context and instructions update with each prompt as your build progresses.
Use FrameworX Terminology
Claude understands general automation terms, but using FrameworX-specific names gives it less to interpret and produces more accurate results.
- Use device instead of PLC, controller, or field device.
- Use UNS instead of tag database or tag tree.
- Use display instead of screen or page.
- Use historian tag instead of data logging or trend tag.
- Use area instead of folder or group.
Define what you know. Ask for the rest.
You do not need to specify everything upfront. Define the things you know. For everything else, ask Claude to suggest options.
Define these things yourself:
- Protocol and driver name
- Full UNS folder path
- Data type (Boolean, Integer, Float, String)
- Device IP address and port
- Alarm type and setpoint values
- Historian logging interval or deadband
Ask Claude to suggest these things:
- Color schemes and visual layout
- Icon choices and label formatting
- Object positioning and sizing
- Naming conventions for tags and devices
- Tag lists for equipment types you are not familiar with
Example of asking Claude to suggest a tag list:
"I'm building a water pumping station with two centrifugal pumps. I don't have the tag list yet. Suggest the most common tags for this equipment type, including data type and engineering units, and create them in FrameworX under Tag.Plant1/Utilities/PumpStation1."
Follow the pillars in order and split large builds across sessions
FrameworX solutions are built in layers. Each layer depends on what came before. Build in this sequence and confirm each layer works before moving to the next.
# | Pillar | Confirm before moving on |
1 | Tags (UNS) | Tags appear in the asset tree with correct paths, types, and initial values. |
2 | Devices and protocols | Channels and nodes are created. Protocol matches your hardware. Communication is confirmed in runtime. |
3 | Alarms | Alarm items reference the correct tags. Conditions and setpoints are correct. Alarm group is set. |
4 | Historian | Historian tags reference the correct UNS tags. Logging interval or deadband is set as needed. |
5 | Scripts | Scripts compile without errors. Logic runs as expected in runtime. |
6 | Displays | Displays open in runtime. Navigation works. Tag bindings show live values, not tag path strings. |
For larger builds, complete pillars 1–5 in one session, then start a fresh session for displays (pillar 6). This gives you a clean context window and prevents running out of tokens mid-build. Re-state your context briefly at the start of the display session so Claude knows the solution structure.
When building multiple displays, include this instruction in your prompt:
"After each display, stop and wait for my review before proceeding to the next."
When something doesn't work, tell Claude what's wrong
AI Designer is conversational. If the first result isn't right, describe the problem. You do not need to restart the session or rebuild from scratch.
Problem | What to tell Claude |
The display shows the tag path as text instead of a value. | The tag binding on the display is showing the tag path string instead of the value. Fix the LinkedValue binding on those elements. |
A navigation button doesn't go to the correct display. | The button isn't navigating correctly. The ActionDynamic is missing or pointing to the wrong display. Fix it. |
A script throws a compile error. | The script has a compile error on line 12. The error is: [paste error]. Fix the syntax. |
An alarm isn't appearing in the alarm viewer. | The alarm for this tag isn't showing when the value exceeds the setpoint. Check the alarm item configuration and fix it. |
Claude created things you didn't ask for. | You created displays and scripts when I only asked for tags. Remove what you added beyond what I specified and wait for my instructions before building the next module. |
If a session runs long and responses become degraded, start a new chat, re-state your context briefly, and continue. Most issues resolve in one to two follow-up messages.
Known limitations
AI Designer handles tag creation, device configuration, alarms, historian, scripts, and display structure reliably. Two areas currently require manual work after AI generation.
Area | What to do |
Display visual polish | AI-generated displays are structurally correct: elements bind to the right tags, navigation works, alarms display. The visual layout — element sizing, alignment, color consistency — typically needs manual refinement in Designer. Plan for 30 to 60 minutes of polish on a typical display after AI generation. |
Image placement | AI does not reliably place images on canvas displays. Place images manually in Designer, then ask Claude to build around them. If you ask AI to modify an image you placed manually, it may corrupt the placement. Make all image changes manually. |
Get Started
→ Setup instructions: MCP and Claude Setup
→ Overview of all AI features: AI Integration
→ New Solution Prompts: New Solution Prompts