Hello, I would like to start a broad discussion about Application Modules because they are interesting to me. How have community members used them and what’s the best way to be successful? What are some tricky details or pitfalls to be aware of?
I will start! AppModules seem powerful to me but are definitely an advanced user feature. Once set up, they are not too bad to use but there are still some tricky PV identifier and memory management details that can’t quite ever be ignored.
Personally, I have used an AppModule in one customer application where I was contributing a subsystem to the main project as a solo developer. It worked very well for me as a layer of abstraction providing a clear interface to design my subsystem around - this abstraction I think is the main benefit. There’s the possibility that this subsystem will be introduced on other machines by that customer, at which point I will see how easily the module exports and can be integrated somewhere else. I managed to package everything for the subsystem (Logical, configuration and physical view!) up into a Git Submodule and it was quite time-consuming to do that, but worth it.
I am excited to hear others’ thoughts on this matter!
We actually use them extensively in Canada. It started out as an attempt to get multi-programmer simultaneous uploading to a machine working for big projects (E.G. AcoposTrak), but really their true helpfulness came from code organization.
They’re now integrated into our framework and we use them on a lot of projects.
A few key points:
We divide our application into modules based on hardware components.
We use mapp PackML in sync mode to synchronise them with the main master, this makes using them a heck of a lot easier.
We use a few big structures shared via pointers for things that need to be shared to a lot of modules.
We set up mapp AlarmX’s escalation concept to feed the alarms from the sub modules to the main module.
We use a global mapp Recipe in the main module but have separate mpRecipeRegPar blocks in each app module to handle data handling.
This was originally spearheaded by Francis but I can also talk about it, if you ever want to chat.
Advanced User Barrier: Application Modules are considered an “advanced user feature”. They require careful handling of PV (Process Variable) identifiers and memory management that cannot be fully automated.
Development Overhead: Packaging subsystems into modules (especially when using Git Submodules) is noted to be “quite time-consuming” compared to standard project structures.
Visualization Limitations: The legacy visualization tools are often described as outdated; while the newer mapp View is an improvement, it can still face conflicts when combined with other OPC UA modules.
There was a webinar “Modular applications in automation studio 4“ available in the past on Academy > Knowledge resource (but I don’t see that anymore, for sure Huber is key reference for that)
an “advanced user feature”. They require careful handling of PV (Process Variable) identifiers and memory management
I couldn’t have stated that better myself!
With regards to VC4 and ACP10, I think it is fair to say that VC4 and ACP10 projects are non-starters for AppModules. I have not tried using ACP10, but VC4 was very difficult for me because my vises depend heavily on some “bidirectional” variables in toggle buttons. I suppose it could be done if planned around, but not ideal for sure
That’s exciting, @Jonathan.Robillard! How many modules do you usually have in a project?
And how extensively do you reuse full modules between projects? It sounds like you have a robust framework that you start with, but are the “guts” of your AppModules shared across projects at all?
I should do some learning with mappPackML, I’ve never actually used it before and that sounds clean…
Now this right here is something that I take issue with:
ACP10 is not supported by App Modules, there’s still a few pages in the help lying around reminding you of that (If you see it say motion is not supported, they mean ACP10)
We have about 20-30 modules in the main projects we’re working on right now.
Reusing full modules accross project hasn’t been done from our end yet, but shouldn’t be too bad to do. Will have to study when it does.
We do sometimes where we have multiple modules that run the same code. When that happens we just declare the individual modules but have them call different instances of the same program, and use a bit of code to figure out which instance it is.
mapp PackML is great once you get the hang of it, I do recommend it.
Application modules are the best thing that B&R has available.
Each application module is a completely separate machine with its own memory and management. This is truly structured programming.
With an application module, you only change what is needed. All the examples that B&R shows are exactly how it should be done correctly. Unfortunately, a large part of application engineers do not get it right and do not understand the concept at all. It is the same struggle as the imperative vs. declarative approach
The application module must be treated as a separate machine with which you communicate via the IO system, whether it is a fieldbus or physical signals. Variable mapping is a very powerful tool for this, which does exactly this.
You do not need to use pointers to access the application module from elsewhere. Either you put the entire structure in the variable mapping, or there is a UDINt variable in the variable mapping, where you put the address. It’s exactly the same as if you were working with classic FUBs.
In fact, all mappComponents are great in that you can find out all the information in each application module via the mappCom interface.
mappView, mappCockpit, mappMotion and others support the application modules without any problems. It’s just necessary to RTFM even in this day and age when everyone is asking about Gemini. What AI wrote in those three points at @valerio.manenti post is complete nonsense.
ACP10 and VC did not count on application modules. That’s true. However, it’s irrelevant
with mappView you can use application modules just fine. What is the logical problem is the need to have visualization in the mappView folder in Logical and mappView in Physical. However, there is such a nice hack - you can also put references to these components in the .pkg file (although it is not possible via the wizard, but in text mode yes), so I currently have visualization (content, pages and binding and event bindings) in the project folder /Logical/moduleA/vis/pages/ , /Logical/moduleA/vis/binding/ , /Logical/moduleA/vis/Dialogs/ etc. and the script during the rebuild generates links to /Logical/mappView and to /Physical/configX/mappView
Same type of workaround I do with OPC files, generating *.vis file, mpAlarmsX and all others.
It’s such a workaround.
The simple plain text form of the project in AS is brilliant. God bless the SW architect at B&R.
This is only true from the Configuration View standpoint! It’s great how they modularize memory and mapp components, but .HW files and Logical View source code are not directly included. (.sw files can name source code files, but don’t contain the programs)
For this reason, AppModules are still only configuration tools and are not “swiss army knifes” to put together entire machines. For that, they would need to include Source Code Files and HW trees directly.
. Let’s just say he was many years ahead of his time.