OpenClaw modifies AS project: ST/mappView works fine, but Physical View (MPAlarmXCore) doesn’t reflect changes correctly

Ask Questions B&R Software & Runtime
, ,
1

Hi everyone,

I’ve been experimenting with OpenClaw to automate modifications in Automation Studio (AS) projects. It does a great job handling structured text (ST) logic and even creating/editing mappView pages and contents by learning from existing patterns in my project. :+1:

:white_check_mark: What works well:

  • Modifying ST code in the logical view

  • Adding/editing pages and contents in mappView (visual part)

:cross_mark: The issue I’m facing:
When I try to modify elements in the Physical View, for example — adding a Group ID to an existing MPAlarmXCore alarm configuration — the changes don’t seem to be recognized correctly after reopening the project in AS.

:magnifying_glass_tilted_left: More details:

  • I can see the modified XML structure when checking the underlying files.

  • But after reloading the project in Automation Studio, the Group ID field is not displayed correctly in the Physical View editor (it may be missing, reset, or not visible).

  • No build errors, but the configuration doesn’t behave as expected.

:brain: What I suspect:

  • Possibly AS caches some physical configuration data elsewhere?

  • Or the schema validation expects certain references or dependencies that OpenClaw isn’t replicating yet?

  • Maybe there’s a difference between what’s stored in the XML and what AS reads into the UI model?

Has anyone here worked with OpenClaw for modifying Physical View elements, especially MPAlarmXCore settings? Any insight into why AS might not display the changes properly, even though the underlying files seem correct?

Any help or pointers would be much appreciated! :folded_hands:

Thanks in advance!

2

I understand your question, but on the other hand, it is important to point out that you are touching a field (project configuration file modification by an external tool) that is not officially supported.

What you can do is use the reverse approach: use the repository, modify the parameter in AS, check where the modification is done and stored, and adapt your automated modification. BUT—and I will return again to my first sentence—each new version of mapp/AS can apply changes without warning, so it will not work then.

1 Like
3

I do agree with Jaroslav, using external tools is not officially supported, and should be done with caution.

However, due to mapp Services configuration files being XML, it is possible to modify them (something we, within mapp Services, use quite often), as long as the structure defined by mapp Services is followed. Especially the ID attributes are dangerous to modify, because these are the way the individual groups and properties are identified. Any invalid or faulty modification/structure (like a missed array index value, typo, …) may cause loss of information, or unexpected behavior during runtime or even within Automation Studio, as only known elements will be considered by Automation Studio during the build (or when displaying the configuration).

But, regardless of which tool you use, keep in mind that while the XML structure usually does not change (for compatibility reasons), it is not guaranteed!

In case you do want to try it (and want to deal with possible future changes), the best approach (as Jaroslav mentioned) would be to change values in AS, and observe how the XML contents behave. For the MpAlarmXList you could (for example) define 5-6 dummy alarms with different values, and compare how they look inside the XML structure. A “Persistent Alarm” may for example look like this (note: this is just a small excerpt and will not work directly):

<Group ID="[5]"> <!-- Index of the alarm and the most likely cause of issues. Starts with "[0]". The list will be seen "complete" with the first missed index. -->
  <Property ID="Name" Value="ModuleAlarm" />
  <Property ID="Message" Value="{$IAT/AlarmModule}" />
  <Selector ID="Behavior" Value="PersistentAlarm" />
</Group>
2 Likes
6

I see what you mean. That’s a great idea. I’ll test it that way. Thanks!

Thank you very much for your quick response. I’ll go ahead and test it out.

After testing, I was able to modify it in the background. But as for why it didn’t work yesterday — I apologize for not diving deeper into it at the time and not being able to reproduce the situation. Still, this is definitely moving us forward step by step toward achieving autonomous programming.

Moderator: Please use one post to reply, not multiple

1 Like