Complete change of axis parameters in AS6.5

[Michal_Malek]

Hello,
In ACP10, completely changing the axis settings was easy by switching between the defined “.apt” and “.ax” tables.

In mappMotion, the axis data are stored in files such as “.purevaxcfg” (I have a virtual axis), “.axis”, and “.limitset” (if used). These can be changed using the function block MC_BR_ProcessConfig, similar to how it was done in ACP10.

For three possible configurations of a single axis, it looks like this:

I tested this in last versions of AS4.12, and it worked well. Now, I am trying to use it in an application with AS6.5, but it fails at the beginning with an MC_Power timeout error on the primary axis (something I’ve never seen before + no logget input). However, it works when only a single set of configuration files is in mappMotion tree.

Is this approach correct?
Thank you
Regards
Michal Malek

[valerio.manenti]

Hi @Michal_Malek ,
yup ACP10 (legacy) and mapp Motion are different.
In your case I recommend the TM415 – Introduction to mapp Axis

Our Academy is working on updating our training modules for AS 6.x, but for the moment I see the actual release available on our website will help you a lot on understanding the new settings in mapp Motion.

When you have an error on mapp Motion, you should check Drive Log (or network command trace), mapp Cockpit and motion logger…all information stored on our System Dump.

With all respect for ACP10, now with mapp Motion we have mapp Cockpit very cool tool in my opinion, Michael posted an helpful guide at this page guide work with mapp Cockpit
Thanks
Ciao
Valerio

[Michal_Malek]

Hi Valerio,

I would like to ask what the common user approach is to this specific problem, and whether the analogous approach (taken from ACP10) is suitable in this case. I am quite sure that the training modules as well as the help documentation are too general to answer this question.

The subsequent MC_Power error appears to be clearly connected to multiple axes being configured, even though only the first axis is referenced.

So the question could be rewritten as:
Can a single-axis application have multiple configuration files and switch between them?

Thank you.

Regards,
Michal Malek

[valerio.manenti]

Please take your time on reviewing this post made by Bryan: Process config, process param and you

Ciao
Valerio

[michael.bertsch]

Hello,

@valerio.manenti
just as a hint, Reconfiguration is not part of TM415. You do not find any note about ProcessParam or ProcessConfig. So for the others TM416, 417.

@Michal_Malek
The Mapp-Configuration Files can be seen as Files on the CF-Card. So it is typicaly irrelevant how much of them you create. They just lay around, BUT:

There are Mapp-Functionalitys searching for some of this files, and these Files will be startet to interpret and actuate the Systemfunctions.

For a Axis this is the .axis File.
The System goes over each File and analyses the content.
If the Axis is not Referenced to an other Hardware-Axis Component (Acp,PureVAx,…) this message will appear in logger.

-2141192186 The Component “gAxis1” of type axis was found in the configuration but it has not been created.

You can access it in the Cockpit too, with same Information and Empty Pages.

For a PureVAx this is the .purevaxcfg File
The System goes over each File an analyses the content.
If like in this case there is no valid axis Reference, there is a logger entry and operation for this object will be shut down.

-1067448313 Value of Axis Reference in the settings is invalid.

For a LimitSet this is the .limitset File
Here it is a bit different, these Files are gathered to a limit Set List in Memory.
A sum of the contend of all these Files.
They are only used if they occure in any other element as Reference.
Limit Sets can be used via some Commands from Axes Group thats why they are hold ready even if they are not referenced.

The green Part of Configuration Files which are Referenced to each other and combined lead to a working Configuration , does not have issues with the red part of laying arround pre Prepared Files which are not Referenced.

In gerneral i would give the Advice to think about the ease of use which files you pre Prepare in AS and which Configurations you will better Reconfigure with ProcessConfig/Param during Runtime.

Usecase CNC-Machine with different Mechanics
Variant 1: XY
Variant 2: XYZ
Variant 3: XYZA

Prepare a .mechanicalsystem for each system, we can use them in the AxesGroup as Reference. So you don’t need to use ProcessConfig here…

Prepare all .axis for all Axes we can use them in the Hardware as Reference. So you don’t need to use ProcessConfig here…

For the AxesGroup itself i would only use one Configuration File, as there is only one AxesGroup. You cant prepare more of them in advance the system would just try to activate an AxesGroupInstance for each configuration File.
Here it is better to have one ConfigurationFile with minumum Inital Settings (XY)
And then use ProcessConfig to reconfigure this Configuration.

The same would apply to the PureVirtual Axis or Acopos.
Just have one for each Object you will finaly have in your machine, and then set up the nessesary Parameters via ProcessConfig.

If you want to have a Axis in some cases as ACOPOS, and in other cases as Stepper or as a VirtualAxis you have to be sure to not have the reverence active on more than one axis. Be sure you remove the Reference to the logical Axis-Object on the not active ones!

You can use “SYS_Lib - SYSreset()” to execute the required Warmrestart via Software.

---

ProcessParam can change less Settings, but does this without the need of a Warmrestart. But it is not Retained.

---

After this general descriptions, to your inital question:
If there is only one Virtual Axis you have intended to generate, i would only use one .purevaxcfg Configuration Element and not 3 of them.
Same for the .axis object.

There are possibilities were you can combine several pre Prepared Files, but its just to confusing.

Better make a Task with ProcessConfig, which you will any way need to adapt References. Just handle all Parameters there. You can Program a nice CASE routine were you select a Action which contains your Parameter set.

For Limit Sets you can use as much pre prepared Configurations as you want.
They can be Referenced to the used Axis.

The error you descriped with the PowerOn was not seen in my Tests, we have to go more in detail if this keeps happening. As File upload is limited, i would suggest to uplad just the mappMotion Config as .Zip. so we can import it in a Project. I assume you do not have jet something special in Hardware- or Logical-View. PureVAxCfg_1 is normaly not influenced by PureVAxCfg_2 it is not of interesst if the 2ten one has no AxisReference in it.

Greetings
Michael Bertsch

[valerio.manenti]

Respect Michael, no words! Thanks so much for your comment!

[Michal_Malek]

Hi Michael,

Thank you for the comprehensive explanation.

To be precise, I have one drive and three motors with quite different configurations. Switching between them must be performed within one second. My intention is to keep all three configurations within a single package, where they can be easily managed. In this case, it involves three files using the data types mcCFG_AX, mcCFG_PURE_V_AX, and mcCFG_LIMSET_ROT. I am using exclusively the mcPCM_LOAD mode.

However, in your explanation, you suggest avoiding these files. This is the point I do not fully understand, where do you suggest this configuration data should be stored instead.

MC_BR_ProcessConfig requires a configuration element (parameter “Name”), which, as I understand it, corresponds to the ‘axis’ element within the “.axis” file, etc.

Could you please explain in more detail where all the configuration data should be stored and from where it should be loaded by MC_BR_ProcessConfig?

As I mentioned, my approach worked fully in AS 4.12. In AS 6, the configuration switching itself works, but the motion does not (due to the previously mentioned timeout).

Thank you very much.

Regards,

[michael.bertsch]

Hello,

<To be precise, I have one drive and three motors with quite different configurations. Switching between them must be performed within one second.>

So you have an electeo-mechanical switch which changes UVW from first Motor to UVW of second Motor, … And Encoder aswell?

If you want to change something in Seconds you can completly skip thinking about ProcessConfig as every change is only activated via a Warmrestart or ProcessConfig (load from Config).

A ProcessConfig load command only shows the Data in the Program-Structure. I now start thinking that this is what you tried to do…

As in your Case i understood that a Restart is not a valid option.

---

You have to work with ProcessParam or ProcessParID.
To change the Settings on the Acopos during Runtime.

If you can provide a list of Parameters which have to be changed we can go more in detail.

I assume Motor-Parameter, Homing-Offset, ControllerSettings, …

It may be that you realised this, i am not sure i completly understood how far you came by your mentioning with AS4 works.

---

As descriped the Mapp-Configuration Files are not only passive files. As the System goes over these files at StartUp and Initialises some Functions. It is not only a “Recipe Storage”

---

If you only need a Data-location to load the prepared Data i would suggest to use MpRecipe. And use the DataStructures to store the data in the RecipeFile.

The Recipe-Files can be Stores on the User Partition on the CF.

Greetings
Michael

[michael.bertsch]

Hello,

If you only want to debug the differences between AS4 and AS6 you have to use the Logger and DriveLog to see if there are some hints.

Basicaly the MappMotion Sytem has not changed between AS4 and AS6 in its Concept. There were only some little tweeks or new Functions.
Maybe there has been a new Parameter been added which your Changing Algorythm is not setting … and this results in the PowerOn error.

Greetings
Michael

[Michal_Malek]

Once again, thank you, Michael, for clarifying.

It seems that I must completely change my approach and move away from ACP10 “passive file thinking.”

This solution is not intended for a single project, so it needs to be as general as possible. Therefore, virtually all parameters from the mentioned files should be changeable during “axis changing” (as was the case with ACP10).

However, MC_BR_ProcessParam does not allow changing all parameters or enumerations, for example mcCFG_PURE_V_AX_ENC_LINK.

Moreover, with this approach, the axis data must be stored in two different ways and in two different places: in the mappMotion package for the initial axis and, for all axes, in a separate data object. However, this is only a matter of practicality or a “lack of elegance.”

The inability to change certain configuration parameters is a much bigger problem.

Best regards
Mcihal Malek

[michael.bertsch]

Hello,

The ACOPOS Firmware is mostly the same for ACP10 and MappMotion. The main differences are on the PLC side API.
It is true that MC_BR_ProcessParam is realy limited. Because most Machines does not need this amount of flexibility.

In regards to changing the Parameters on an ACOPOS without a restart you will most likely have to use a huge amount of ParIDs with MC_BR_ProcessParID_AcpAx , or if the Parameters are more fix and pre Prepared MC_BR_ProcessParTab_AcpAx.

In the ACP10 Docu you can find the ParIDs to which the Parameters from the Axis-Structure were deployed to.

Sorry for the amound of work , but the Concept of MappMotion was more Configuration less Programm. Which in some cases lead to a more fixed System.

The pureVirtual Axis was not in ACP10 so i am not sure why you went to it, but if there is some function you can’t change during runtime but you need it to be changeable, you have to go away from pureVirtual Axis and find a more legacy aproach. There are still virtual Axis on the ACOPOS.

It is a rare edge case, i think, that on an Servo drive the motors are switched during runtime… I normaly would suggest the coustomer to use just a 3 Axis P3 , as it removes the issues with the electro-mechanical switching of Encoder and Motor and it is much more ease to set up. If they are not used in parallel there is no issue with the reduces simultanues Powersupply of P3, so it could be very suited for this.

Greetings
Michael Bertsch

[Michal_Malek]

Hi Michael,
In ACP10, SDC was used, and Pure Virtual Axis appears to be its successor and seem to be fully operational. Therefore, there is no legacy approach in place (SDC is not available in mappMotion).

Ultimately, it does not matter how the data are managed (although a simpler approach is preferable). What matters is that if each element of mcCFG_PURE_V_AX_ENC_LINK has its corresponding counterpart within the parIDs, then I have a workable solution.

For example, in ACP10 there is parID 109 – SCALE_ENCOD_INCR, which corresponds to EncoderLink.IncrementPerRevolution in mappMotion. However, I am concerned that these variables may not actually be equivalent.

One of B&R’s major strengths is that configuration and physical view data are typically accessible within the application, and motion data are far too important to be excluded.

Thank you.

Best regards,
Michal Malek

[michael.bertsch]

Hello,

Yes the PureVirtual Axis with enabled General Axis Purpose Interface is the successor of SDC, but not fully compatible in its function Set.
And in difference to the SDC the PureVirtualAxis does not have ParIDs to get a deep access.

For a PureVirtual Axis you have to reley on MC_BR_ProcessParam/MC_BR_ProcessConfig for reconfiguration.

If you miss a feature there you have to get in contact with your local sales contact to discuss possible solutions.

---

Just as an idea for Brainstorming:
For a short term workaround, you may define a virtual Encoder Interface via Task-Variables and then use an Application to switch your Encoders via this Virtual Interface without reconfiguring the PureVirtual Axis.

Greetings
Michael

[michael.bertsch]

Hello,

Are your 3 Motors connected to a Pure Virtual Axis or to an real ACOPOS?
I think i still do not oversee your requirement in full.

Because if it is connected to a Pure Virtual Axis why do you switch at all, why not enable 3 Pure Virtual Axis?

Greetings
Michael

[Michal_Malek]

Hi Michael,
In my current pilot mappMotion application, I have three motors (and potentially more in the future) connected to a single drive (P77 or another type). This configuration results in a single Pure Virtual Axis.

In my previous SDC applications, a single drive contained three ncAxis_HW instances (of type SdcHwCfg_typ), as shown below:

All of this runs on very low-cost hardware (ARM-based PLC), so I prefer to operate only a single axis to keep the system as lightweight as possible.

Could you please explain your idea of a virtual encoder interface in more detail? I’m not sure I fully understand what you mean.

Thank you.

Regards,
Michal Malek

[michael.bertsch]

Hello,

The Encoder Interface of the PureVirtual Axis is generated by Variables which are typicaly directly connected to Hardware. If you would instead use a set of Variables in PLC-Task you have the possibility to Manipulate or Switch between different Hardware locations without switching the IO-Mapping on the PureVirtual Axis. I have no idea if this is a solution but was an idea.

I know that with new MappMotion Version there is a special Library for P77 comming, but i think this Library will also be restrictive in what Parameters can be changed. But i could be interessting to have a look into, in the future.

Greetings
Michael

[Michal_Malek]

Hi,
Thank you for the clarification.

Yes, this is my preferred way of managing the unmanageable :-).

I’ve heard about McAcpInvAx, but this particular application has been running reliably for years and only requires the mappMotion connector. However, who knows—perhaps it will surprise me with some interesting features. I don’t have any details yet.

Thank you.

Best regards,
Michal Malek

[michael.bertsch]

Hello,

Sorry for having a lot of text here, but not the best solution right now.
I hope we had at least clarifyed the functionality of the Mapp-Configuration Files which was initial discussion.

Just as a sum up:
I think you should use a external data storage to store your different parameter sets. As mentioned MpRecipe can be used to do this.

Then use this Parameters in your application to change Parameters during Runtime, to act on the Parameters which are set by the default Mapp-Configuration File (set up a minimum default setting) needed for your Software-Objects to get alive.

---

If you found a good solution feel free to share it here or post more detailed questions.

Greetings
Michael

[kovarj (Jaroslav Kovar)]

Thanks @michael.bertsch for the summary, I marked it as a solution. @Michal_Malek feel free to change it or update us. All together great discussion and nice example of how experts can help other experts. You made my day

[Michal_Malek]

Hi Michael,
If I may, I have one additional question related to the original one.

I have three independent referenced axes (as depicted in the first picture of this thread).
SW_EK700x_ZK_v2_0_0_46.zip (488.8 KB)

The logger suggests that all axes are initialized without any errors.

Please find attached:
Logger_23_02_2026_02logpkg.logpkg (644.8 KB)

NetworkCommandTrace_01.txt (8.4 KB)
However, when the power command is issued, the drive goes into a timeout error:

When only one axis is initialized, the power can be switched on without any error.
I don’t see any connection that would explain how the axes could affect each other.
Do you see any problem with this configuration?

Thank you.

Regards,

Regards,