tia-openness-bag-pulse

name	tia-openness-bag-pulse
description	Use when working in an open Siemens TIA Portal V17 project through Openness, especially for SCL bag pulse logic, PLC/HMI tag tables, TP1200 screens or popup screens, WinCC VB scripts, cycles, text lists, graphic lists, data records, alarm records, scheduled tasks, structured HMI tag naming, import/export loops, compile checks, or repeatable skill packaging.

TIA Openness Bag Pulse

Use this skill to turn a user request like "connect to TIA and build a bag pulse dust collector", "create a TP1200 button and a popup screen", or "verify HMI VB script/cycle/text-list import and export" into a repeatable Openness workflow.

Project Isolation

When this skill is used from D:\skills\codex\Tia, treat that workspace as the only authoritative source for project-specific knowledge.

• Use the project-local skill folder: D:\skills\codex\Tia\skills\tia-openness-bag-pulse.
• Use the project-local knowledge folder: D:\skills\codex\Tia\knowledge\tia_sanjiu_learning.
• Keep generated SCL/XML/log/export/verification files under D:\skills\codex\Tia unless the user explicitly gives another target.
• Do not import assumptions, reference files, scripts, or generated artifacts from other workspaces or same-named global skills.
• If prior memory or a global installed skill is consulted for orientation, re-verify all task facts from this workspace before acting.

Assume the work happens on Windows with PowerShell, an already-open TIA Portal session, and a CPU that supports SCL blocks. Prefer creating new blocks and tag tables over mutating unrelated existing logic.

Workflow

1. Run the multi-monitor preflight before any UI click, selection, copy, paste, or screenshot operation.
2. Inspect the local Openness environment.
3. Attach to the open TIA Portal process.
4. Discover the target project, PLC software object, existing blocks, and existing tag tables.
5. Generate or update the SCL source files in the current workspace.
6. Import the source into TIA with Openness, creating blocks, DBs, HMI screens, HMI popup screens, VB scripts, cycles, text lists, graphic lists, or HMI tag tables.
7. Create or update the PLC tag table for field IO and status words.
8. Compile the generated PLC blocks when PLC logic changed.
9. Export generated HMI objects or PLC blocks for verification.
10. Save the project.
11. Report what was created, what addresses were used, and whether OB1/Main or HMI screens were changed.

Multi-Monitor Preflight

The user's Windows workstation can have two or more monitors. Always inspect the monitor layout and target window placement before any coordinate-based UI operation. Do this first, even when a screenshot is visible.

Run:

powershell -NoProfile -ExecutionPolicy Bypass -File "D:\skills\codex\Tia\skills\tia-openness-bag-pulse\scripts\inspect-window-screens.ps1"

Rules:

• Record each screen's DeviceName, Primary, Bounds, and WorkingArea.
• Negative X coordinates are normal when a secondary monitor is placed to the left of the primary monitor.
• Locate Codex, PowerShell, TIA Portal, WinCC, and script/editor windows by process name and title.
• Determine which screen contains the center of each relevant window.
• Do not use hard-coded click coordinates from a previous run unless the same window is still on the same screen and the bounds still match.
• If Codex and TIA/WinCC are on different screens, all clicks and screenshots must be based on the target window rectangle, not on the active Codex window or the primary screen.
• If the target window cannot be located or is minimized, stop and ask the user to bring the TIA/WinCC editor window into view before attempting UI actions.

Quick Rules

• Prefer C:\Program Files\Siemens\Automation\Portal V17\PublicAPI\V17\Siemens.Engineering.dll when V17 is installed. If V17 is missing, search under C:\Program Files\Siemens\Automation\Portal* for Siemens.Engineering.dll and use the newest matching PublicAPI version.
• Use PowerShell and load the DLL with Add-Type -Path.
• Enumerate TIA processes with [Siemens.Engineering.TiaPortal]::GetProcesses().
• Attach to an existing UI session instead of opening a new hidden TIA process when the user says Portal is already open.
• Find PLC software through DeviceItem.GetService[SoftwareContainer]() rather than assuming the PLC sits at a fixed device-item depth.
• Prefer adding new blocks with distinct names such as FB_BagPulseDustCollector, DB_BagPulseDustCollector, DB_BagPulseDustCollector_IO, and FC_BagPulseDustCollector_IO.
• Compile newly generated blocks first. Then compile the PLC software object to confirm the whole software tree is clean.
• Save the TIA project after a successful compile.

Compile Operation Policy

Compilation is allowed and expected, but do not use coordinate clicks to start it.

• Prefer Openness compile helpers for PLC/HMI verification.
• Exception: for the current WinCC RT Professional HMI-5X project in this workspace, compile-rtpro-hmi-device.ps1 has been observed to compile successfully and then leave the TIA UI window closed/disappeared after the attached Openness session is disposed. Do not use that script as the default verification path when the user needs the already-open Portal UI to remain open.
• If using the TIA UI, use the verified shortcut Ctrl+B for "Compile object" after the correct TIA editor/object is already active.
• Ctrl+B compiles only the currently active object. If a PLC block/program is active, it compiles the PLC object. If a WinCC RT Professional object is active, it compiles that RT Professional object. If a TP1200/HMI object is active, it compiles that HMI object. If no compilable object is active, it may do nothing. Therefore, before treating Ctrl+B as a valid compile check, verify the target object is active from the visible editor, selected project tree item, status/output pane, or user confirmation.
• After Ctrl+B, check the compile status/output promptly. Do not wait a fixed 30 seconds, and do not take screenshots merely as proof unless the user asks or a failure needs visual diagnosis.
• Read references/tia-v17-shortcuts.md before relying on TIA keyboard shortcuts.
• Never send Alt+F4, Ctrl+W, Ctrl+F4, or Ctrl+Shift+F4 during verification unless the user explicitly asks to close a window or project.
• Do not click toolbar buttons, title bars, close buttons, or editor chrome by screen coordinate to compile.

Default Deliverable

Unless the user asks for a different structure, generate these objects:

• FB_BagPulseDustCollector: the reusable core SCL FB
• DB_BagPulseDustCollector: instance DB for the FB
• DB_BagPulseDustCollector_IO: parameter and status DB for HMI/operator tuning
• FC_BagPulseDustCollector_IO: IO wrapper that maps field signals to the FB and writes outputs/status back out
• Main or OB1: call the IO wrapper only when safe to do so

Keep the core behavior conservative:

• Default BagCount := 4
• Make PulseTime, ValveInterval, and CyclePause adjustable
• Support manual pulse and pressure-difference requests
• Support enabled-bag selection and optional per-bag pulse time

Read references/default-io-map.md when the user does not provide an IO list and you need a ready-made closed loop. Read references/tia-v17-shortcuts.md when the user asks for TIA Portal V17 shortcuts or when keyboard-driven UI navigation is faster than hunting through menus. Read references/hmi-screen-popup-import.md when the user asks to create or verify TP1200/HMI screens, simple buttons, popup screens, or HMI XML import/export through Openness. Read references/hmi-structured-tag-naming.md when HMI variable names must be easy to trace from the property pane back to PLC DBs, for example DB_ActivePopup_Heater01_ActiveID. Read references/hmi-plc-linked-tags.md when HMI tags should be moved from internal variables to direct PLC-linked variables with Connection and ControllerTag, for example DB_ActivePopup.Valve01.Visible. Read references/hmi-popup-sim-800x800.md when the user asks to continue the HMI弹窗 [FB1] / DB_Components / DB_ActivePopup popup simulation, create an 800x800 popup, bind internal Int HMI tags, add button SetTag actions, or verify the known-good Codex_Popup_Sim_800x800_IO2 workflow. Read references/hmi-advanced-objects.md when the user asks about VB script import/export, HMI tag-table fixes for SmartTags, cycles, text lists, graphic lists, data records, alarm records, scheduled tasks, or the 记录 / 计划任务 / 周期 / 文本和图形列表 nodes. Read references/hmi-data-record-audit-vb.md when the user asks to learn, verify, or extend data records, operation logs, audit trails, ReadFile_DATA1, ReadFile_Audit, or archive-display screens such as C1_数据记录 / C2_操作日志. Read references/wincc-rt-professional-scripts.md when the user mentions WinCC RT Professional, RT Prof, PC station, HMI-5X, ScriptLib, .bmo, .bac, USEDVBSMODULES.CVB, or upper-computer/HMI scripts that do not expose TP1200-style HmiTarget. Read when a WinCC RT Professional data-record page such as must add or verify a VB-driven archive field such as . For RT Professional source edits, default to the manual body-file handoff: generate and files for the user to paste between the fixed and skeleton lines.

For RT Professional VB source edits, the default mode is interaction mode: Codex prepares the changed code, the user manually fills or pastes it, and Codex only reads back, verifies, and compiles. Do not directly send Ctrl+A, Ctrl+V, Delete, typing, or keyboard-driven body replacement into the RT Professional VB editor unless the user explicitly authorizes that exact write action in the current turn. Keep verification lean: confirm the actual pasted text matches the generated text, confirm structure and hidden-character checks, then compile the active RT Professional target and report whether compile has errors. Do not take screenshots, export snapshots, or hash script artifacts by default.

Safe Edit Policy For Main/OB1

• Inspect existing Main/OB1 first.
• If OB1 is empty or effectively empty, replacing it with a simple SCL caller is acceptable.
• If OB1 contains real user logic, do not overwrite it silently.
• In a populated OB1, prefer one of these:
  • export the block first and preserve a backup in the workspace
  • add a single new FC/FB call if you can do it without disturbing existing logic
  • otherwise stop short of OB1 mutation and tell the user the generated caller block is ready to be inserted

Report explicitly whether Main/OB1 was changed.

PowerShell Pattern

Use short inspection commands first:

Get-Process | Where-Object { $_.ProcessName -match 'Portal|Siemens|TIA' }
Get-ChildItem -Path 'C:\Program Files\Siemens' -Recurse -Filter Siemens.Engineering.dll -ErrorAction SilentlyContinue

When attaching through Openness, use a helper like this:

$dll = 'C:\Program Files\Siemens\Automation\Portal V17\PublicAPI\V17\Siemens.Engineering.dll'
Add-Type -Path $dll
$process = [Siemens.Engineering.TiaPortal]::GetProcesses() | Select-Object -First 1
$tia = $process.Attach()

For PLC discovery, prefer a recursive walk over device items and a reflected generic GetService helper when PowerShell has trouble calling the generic method directly.

Block Import Pattern

Generate source files in the current workspace, then import them through ExternalSourceGroup.

Recommended source files:

• BagPulseDustCollector_OpennessImport.scl: core FB, instance DB, IO DB, IO wrapper FC
• Main_Call_BagPulseDustCollector.scl: optional OB1/Main caller

Recommended sequence:

1. Create or find the external source.
2. Call GenerateBlocksFromSource(KeepOnError).
3. Compile the generated blocks individually.
4. Compile the PLC software object.

If block export fails because blocks are inconsistent, compile first and retry export only if you actually need the export.

Read references/generated-objects.md when you need the default block naming and responsibility split.

Tag Table Pattern

Create a dedicated PLC tag table, for example BagPulseDustCollector_IO, and keep the IO mapping there. Avoid mixing these tags into the default system clock tag table.

Use the default map from references/default-io-map.md unless the user supplies a plant-specific address list.

If the target project already uses those addresses, stop and ask for the actual IO allocation instead of guessing.

HMI Screen Pattern

For TP1200 or HMI requests, find Siemens.Engineering.Hmi.HmiTarget through the HMI device item's SoftwareContainer. Use ScreenFolder.Screens for normal screens and ScreenPopupFolder.ScreenPopups for popup screens.

Use XML import for simple generated HMI objects:

• assets/hmi-screen-templates/hmi_import_Codex_Button_Test.xml: normal screen with one button
• assets/hmi-screen-templates/hmi_import_Codex_Popup_500x500.xml: 500x500 popup screen

After import, export the new HMI screen or popup to verify that the object exists and that key attributes such as Width, Height, and the button object name are present.

For the verified HMI弹窗 [FB1] simulation, use these scripts in order:

powershell -ExecutionPolicy Bypass -File ".\scripts\import-popup-sim-int-tagset.ps1" -OutputRoot ".\tia_popup_touch_sim"
powershell -ExecutionPolicy Bypass -File ".\scripts\create-popup-sim-visual-screen.ps1" -OutputRoot ".\tia_popup_touch_sim" -ScreenName "Codex_Popup_Sim_800x800_IO2" -BindIntSet
powershell -ExecutionPolicy Bypass -File ".\scripts\create-popup-sim-visual-screen.ps1" -OutputRoot ".\tia_popup_touch_sim" -ScreenName "Codex_Popup_Sim_Runtime" -ScreenNumber 21 -ScreenWidth 1280 -ScreenHeight 740 -AsNormalScreen -BindIntSet
powershell -ExecutionPolicy Bypass -File ".\scripts\import-popup-sim-int-tagset.ps1" -OutputRoot ".\tia_popup_touch_sim" -UseStructuredTagNames -SkipTagNames "DB_ActivePopup_Heater01_ActiveID"
powershell -ExecutionPolicy Bypass -File ".\scripts\create-popup-sim-visual-screen.ps1" -OutputRoot ".\tia_popup_touch_sim" -ScreenName "Codex_Popup_Sim_Runtime_Named" -ScreenNumber 22 -ScreenWidth 1280 -ScreenHeight 740 -AsNormalScreen -BindIntSet -UseStructuredTagNames -FocusComponent Heater01
powershell -ExecutionPolicy Bypass -File ".\scripts\compile-current-hmi-target.ps1" -OutputRoot ".\tia_popup_touch_sim"

For TP1200, do not import an 800 x 800 object as a normal screen. Import it as Hmi.Screen.ScreenPopup through ScreenPopupFolder.ScreenPopups. If runtime interaction needs a directly openable normal screen, use 1280 x 740 with -AsNormalScreen; this target rejected both 800 x 800 and 1280 x 800 normal-screen imports. For traceable HMI tag names, use -UseStructuredTagNames. The naming pattern is DB_Components_<Component>_<Field> and DB_ActivePopup_<Component>_<Field>, for example DB_ActivePopup_Heater01_ActiveID. If the project already contains a manually created tag, pass it through -SkipTagNames and keep the existing object. To connect generated HMI tags directly to PLC DB variables, use scripts/import-popup-plc-linked-tagset.ps1. It adds Connection and ControllerTag links, preserves DoubleClickTime as an internal helper because the exported PLC DB has no matching member, and can skip tags already created in 默认变量表.

HMI Structured Naming Pattern

Use structured names once the basic import path is stable and the user needs to find data from the HMI property pane.

• Component-side inputs: DB_Components_<Component>_<Field>, such as DB_Components_Heater01_ClickTrig
• Popup/status outputs: DB_ActivePopup_<Component>_<Field>, such as DB_ActivePopup_Heater01_ActiveID
• Known components in the current popup simulation: Valve01, Heater01, Fan01
• If a tag already exists, preserve it with -SkipTagNames; do not delete or overwrite manually created tags.

Read references/hmi-structured-tag-naming.md before adding component names or mapping the screen to real PLC DB members.

HMI PLC-Linked Tag Pattern

Use this after structured naming is stable and the user wants the HMI variable table to show a PLC connection like HMI_连接_1, PLC_1, and DB_ActivePopup.Valve01.Visible.

powershell -ExecutionPolicy Bypass -File ".\scripts\export-hmi-tag-table.ps1" -OutputRoot ".\tia_popup_touch_sim" -TagTableName "Codex_Popup_PLC_Named_Int_Tags"
powershell -ExecutionPolicy Bypass -File ".\scripts\import-popup-plc-linked-tagset.ps1" -OutputRoot ".\tia_popup_touch_sim" -TagTableName "Codex_Popup_PLC_Named_Int_Tags" -ConnectionName "HMI_连接_1" -ReplaceExistingTable -SkipTagNames "DB_ActivePopup_Heater01_ActiveID"
powershell -ExecutionPolicy Bypass -File ".\scripts\compile-current-hmi-target.ps1" -OutputRoot ".\tia_popup_touch_sim"

Read references/hmi-plc-linked-tags.md before changing PLC-linked field mappings or adding Real/String links.

HMI Advanced Object Pattern

For HMI VB scripts, cycles, text lists, graphic lists, and internal tag tables, use the bundled templates under assets/hmi-advanced-templates and the repeatable validation script:

powershell -NoProfile -ExecutionPolicy Bypass -File ".\scripts\invoke-hmi-advanced-loop.ps1"

In V17 TP1200 Comfort testing, Openness exposed Cycles, TextLists, GraphicLists, TagFolder, and VBScriptFolder, but did not expose direct collections for data records, alarm records, or scheduled tasks. For those nodes, document the boundary clearly and use GUI/manual XML samples if the user needs direct edits.

For projects where data records and audit trails are displayed by VB scripts, use references/hmi-data-record-audit-vb.md. The verified 三九-15 pattern is: configure the record row in TIA GUI, then close the loop through 变量归档 HMI display tags, ReadFile_DATA1 SmartTags, C1 screen IOFields, exported readback, and HMI compile.

For WinCC RT Professional PC-station projects, use references/wincc-rt-professional-scripts.md. The verified HMI-5X pattern is different from TP1200: Openness exposed device compile but not HmiTarget/VBScriptFolder; script artifacts were found as compiled ScriptLib/*.bmo, ScriptAct/*.bac, and Config/USEDVBSMODULES.CVB under the project folder.

For WinCC RT Professional data-record field checks, use scripts/verify-rtpro-data-record-field.ps1. It reads the .\WINCC SQL databases and confirms the archive row, LT data-logging mapping, display HMI tags, D2 screen row, and VB module list without editing compiled .bmo files.

For RT Professional VB source-level changes when Openness does not expose VBScriptFolder, do not default to automatic keyboard delete/paste. Use scripts/new-rtpro-vb-manual-fill-files.ps1 to generate a complete review file and a body_only file, then provide clickable links for manual paste into the TIA editor. Automatic editor-control scripts are experimental and should only run with single-step user confirmation.

Validation

After generation:

1. Compile FB_BagPulseDustCollector
2. Compile DB_BagPulseDustCollector
3. Compile DB_BagPulseDustCollector_IO
4. Compile FC_BagPulseDustCollector_IO
5. Compile the whole PLC software object
6. Compile the HMI target when HMI objects changed
7. Save the project

In the final report, include:

• project name
• PLC software name
• blocks created or updated
• tag table created or updated
• whether Main/OB1 changed
• compile result summary
• HMI compile result summary when HMI objects changed
• any assumptions, especially IO addresses

What To Avoid

• Do not overwrite a populated Main/OB1 without checking it first.
• Do not reuse %M0 and %M1 clock bytes for status words.
• Do not assume the project contains no existing bag pulse logic; inspect existing FB/FC/DB names first.
• Do not claim the work is complete until the PLC software compile passes.