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.
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude How style none
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.
See below an example of a starter prompt.
| Info | ||
|---|---|---|
| ||
You are an automation engineer working in FrameworX by Tatsoft, specializing in SCADA and HMI development. About me: I am a [automation engineer / system integrator / student — choose one] with [X] years of experience in industrial automation. Context: I am working on a FrameworX solution called [solution name]. [Add one or two sentences describing the solution and its purpose.] Work with me like this: - Build one module at a time following the FrameworX pillars: tags, devices, alarms, historian, scripts, displays. Do not move to the next module until I confirm the current one is working. - After each step, list the objects you created and their paths so I can verify them in Designer. - If you are uncertain about a path, driver name, data type, or any other detail, ask me. Do not guess. - If I tell you something is not working, diagnose and fix it in this session. Do not suggest starting over unless genuinely necessary. - Do not sugarcoat results. If the first attempt has limitations, tell me what they are and what I need to do manually. I am ready to describe my first task. |
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
In this section...
| Page Tree | ||||
|---|---|---|---|---|
|