Hi Nathan,

there is a lot to cover here ... first, let's address the low-hanging fruits.

Your problemstatements in your last posts:

1). Problemstatement: "Is it possible to ship src-libraries and trying to debug them in a consuming-project directly?".

We highly recommend shipping bin libraries (precompiled libraries) for the time being. So debugging only works in the respective lib-development project.

Why is that you may ask : Well, thats simply because SIMATIC AX officially do not support such a design, although it is technically possible (and you can make it work). If doing so it is on your own risk and you may or may not run into compile errors, with error messages such as you wrote . This is caused by the fact that mixed content within your depenceny-chain (libs with src, and other libs with bin) could create duplicate keys/symbols using the st-compiler.

On the other hand : Please do not change/ edit any content you see within the .apax folder. (where the unfolded packages can been seen). The content there are sym-links which redirect to a system-folder. Thus being said: Changing the lib there causes that lib to be changed in all other applications as well, which my not be desired. (not recommended)

2.) Problemstatement: "When using preprocessor directives you always have to adjust the apax.yml".

There are possibilities to tune the scripts to your liking for example to work with passing parameters. To give you an idea : (build+load with preprocessor args)

  blsw:
    - export DEFINED_PREPROCESSOR_SYMBOLS="[\"$1\"]"
    - echo used sw-config:$DEFINED_PREPROCESSOR_SYMBOLS
    - apax build
    - export TARGET_IP_VAR="IP_$1"
    - export IP_ADDRESS="${!TARGET_IP_VAR}"
    - export EXPORT_CERT_VAR="$1_TLS_CONNECT_CERTFILE"
    - export TLS_CONNECT_CERTFILE="${!EXPORT_CERT_VAR}"
    - echo using sw-config:$DEFINED_PREPROCESSOR_SYMBOLS -load-ip:"$IP_ADDRESS" -cert:"$TLS_CONNECT_CERTFILE"
    - 'read -p "Continue loading? (j/n): " r && [ "$r" = "j" ] || exit 0'
    - apax load

with that script it is possible to enter the following bash command for example :

apax blsw PLC_LEFT

... which is using the PLC_LEFT as DEFINED_PREPROCESSOR_SYMBOLS argument the PLC_LEFT_IP_ADDRESS varibale for the loading script and so on.

You get the idea hopefully ... .

Regarding the design approach you are messing with ...

"Say my company makes two machines: an A-type and a B-type (say that each system has 2 PLCs). They share most of their code but also each have a fair amount of unique code."

There are for sure a lot of solutions :

• You can make it work with everthing within one apax app-project using preprocessor directives and scripts which will blow up your apax.yml for sure.
• On the other hand you can seperate everything having 1 apax workspace proj, 4 app-projetcs (each plc within one app) and 1 or more library projects.
  
• Recommended is something in between ... probably needs more insights of your real scope/content but I would draw something like that :

my-apax-ws/
|
|--- machinetype-a/
|    |--packages/shared-lib
|    |--src/config-plc-1
|    |--src/config-plc-2
|    |--apax.yml        ← type-a: preproc.direct. for plc1/2 diff, common lib deps
|
|--- machinetype-b/
|    |--packages/shared-lib
|    |--src/config-plc-1-2
|    |--apax.yml         ← type-b: preproc.direct. for plc1/2 diff, common lib deps
|
|--- shared-lib/
|    |--src/lib-blocks.st
|
|- apax.yaml             ← root: declares apax-workspaces, no deps

With the help of apax workspaces you can have the lib within the workspace which can be consumed by apps directly without the need to publish the lib in the first place. Read more here.

Hope that helps / shed some light into all the possibilities we have with SIMATIC AX.

Keep going & happy coding ...

🐱‍💻 BEEP, BOOP, BEEP, BEEP, BOOP 🐱‍🏍

Hi Nathan,

that's a very good question!

Generally speaking, there's nothing stopping you from creating multiple hardware configurations within one repository, as they are somewhat independent of the software. With the hwc (and hwl) arguments, you decide which folders (containing hwl.yml files) will be taken into consideration for compiling (and loading) the hardware configuration.

For the software, it's technically the same – you customize the build and load script arguments of the stc (and sld). However, since the stc defaults to the 'src' folder, you might consider using preprocessor directives for different variants of your source file contents. Preprocessor directives introduce ::ifdef definitions/pragmas within your ST code that ultimately allow the compiler to compile subsets of the code. You can read more about them here.

On the other hand, you can certainly have multiple single projects and/or introduce multi-root workspace files.

At some point in the future, we may or may not have a more streamlined solution for APAX to better support these kinds of setups. Stay tuned!

Greetings,

Stefan

Hi Stefan,

Thanks for your answer, very clear! I'm still struggling a bit with the multiple-PLC configuration, so maybe you can shed some light on the following.

Say my company makes two machines: an A-type and a B-type (say that each system has 2 PLCs). They share most of their code but also each have a fair amount of unique code. I see two approaches, but neither feels ideal:

- Preprocessor directives to switch behaviour per machine. The downside is that every engineer who wants to download code first has to edit apax.yaml to suit the machine in front of them.

- A library for everything common. But my understanding is that imported blocks from such a library become know-how protected, which I'd prefer to avoid.

My understanding is also that AX merges all configuration at the repo level, which is really what's pushing me toward the structure below rather than just keeping multiple configs side by side. Is that correct, or is there a workspace mechanism I'm missing?

The structure I had in mind:

repo/
  apax.yaml                 ← root: declares workspaces, dependencies
  packages/
    common/                 ← shared code that all systems use
    a-type/                 ← system type A
      apax.yaml             ← its own config: PLC name(s), IP address(es), etc.
      src/
        configuration.st
    b-type/                 ← system type B
      apax.yaml             ← its own config: PLC name(s), IP address(es), etc.
      src/
        configuration.st

The idea is that each machine type is its own buildable unit with its own config, all pulling from a shared common package in the same repo. From the example, I think right now it would not be possible for code in a-type/src to access the common folder, right?

Does this approach resonate with you? is such a model something on the roadmap, or is there a different path you'd steer people toward for the multi-machine, shared-code case?

Thanks!

Kind regards,

Nathan

The more I'm looking into this, the more I'm wondering if it is possible to import a library/package and being able to monitor/trace/debug code in said package. I just tried to make my own library in AX and also add the src folder to the stuff that's being packaged, but when I tried to build a project that uses said package, it threw an error that there was duplicate code (probably the src folder and some binaries conflicting?)