...
- FrameworX Designer installed and running
- MCP tools connected
MCP Tools and Tables
| Category | Items |
|---|---|
| Tools | open_solution, get_table_schema, write_objects, get_objects, list_protocols, list_elements, list_dynamics, designer_action, get_solution_info |
| Tables | UnsTags, UnsUserTypes, UnsEnumerations, DevicesChannels, DevicesNodes, DevicesPoints, HistorianHistorianTags, HistorianHistorianTables, AlarmsItems, DisplaysList |
Implementation Steps
Step 1: Create the Solution
...
get_solution_info()— confirm object counts match expectations- Navigate to MainPage:
designer_action('navigate', 'Display.MainPage')— dashboard should show live gauge valuesNavigate to AlarmsMonitor:designer_action('navigate', 'AlarmsMonitor')— alarms should evaluate against limits when simulator values cross setpoints - Navigate to HistorianMonitor:
designer_action('navigate', 'HistorianMonitor')— confirm tag values are being logged
...
- In Step 4, replace
list_protocols('ValueSimulator')with the target protocol (e.g.,list_protocols('ModbusTCP'),list_protocols('OPCUA')) - Configure Channel/Node with real connection parameters (IP, port, etc.)
- Map Points to real device addresses
- Everything else (Tags, Historian, Alarms, Dashboard) remains the same
Common Pitfalls
| Mistake | Why It Happens | How to Avoid |
|---|---|---|
| Guessing protocol field formats | Skipping list_protocols | Always call list_protocols before writing device tables |
| Bare tag names in DevicesPoints | Forgetting asset path | Always use full path: Plant/Tank1/Level |
| Creating unnecessary HistorianTables | Not checking defaults | Check get_objects('HistorianHistorianTables') first |
| Creating unnecessary AlarmsGroups | Not checking defaults | Predefined groups exist (Critical, Warning, AuditTrail) — check get_objects('AlarmsGroups') first |
| Omitting PanelType on dashboard | Seems optional | Always set PanelType explicitly |
| Pre-fetching all schemas at once | Over-eager optimization | Fetch each module's schema only when ready to write it |
| Screenshotting to verify writes | Unnecessary self-validation | Trust write_objects success. User sees live updates |
| Forgetting to start runtime | Skill ends at config | Always end with designer_action('start_runtime') |
| Using alarm field names from examples without checking schema | Examples may not match current schema | Always verify field names against get_table_schema('AlarmsItems') |
| Using simple variables for repeated equipment | Didn't plan UNS structure | Step 2: if 2+ identical equipment instances exist, use UserTypes |
What's Next
- Canvas displays, process diagrams, visual dynamics: Load the Display Construction skill —
search_docs('displays', labels='skill') - Scripts, expressions, automation: Load the Scripts and Expressions skill —
search_docs('scripts', labels='skill') - Real device connectivity: Use
list_protocols()to browse available protocols, then adapt Step 4 - Asset navigation pattern: The Display Construction skill covers how to build asset-driven dynamic displays
Overview
Content Tools
Tasks