Adapting a B&R-provided AxCon cyclic current reference structure to Automation Studio 6.3+

[omer.alumur (Ömer Sezai Alumur)]

Hello everyone,

We have an existing B&R Automation Studio project that was originally built with AS 4.12.6.106, mapp/ACP10 5.23.1. In this project, we are using a B&R-provided/custom AxCon structure together with MpAxisBasic to command the drive with a cyclic current reference instead of the more common cyclic torque reference approach.

The system has 6 axes. For each axis, the application initializes an AxCon instance in axCon_MODE_CYCLIC_CURRENT mode and connects it to the related MpAxisBasic instance. The calculated current reference from our controller is written into axconBuffer.Buffer[0].

The important part of the structure is roughly this:

Controller calculates actual current reference [A]
    -> SetRefCurrentForAllActuator()
    -> axconBuffer.Buffer[0]
    -> MC_BR_CyclicWrite
    -> ParID 4128 / VAR_R4_0
    -> ICTRL_ADD_SET_PARID, ParID 325, points to 4128
    -> additive current setpoint of the current controller

During initialization the AxCon code also writes/uses these ParIDs:

PCTRL_ENABLE_PARID = 231
ICTRL_ADD_SET_PARID = 325
VAR_R4_0 = 4128

The current project also contains .apt files where ICTRL_ADD_SET_PARID is set to 4128, and VAR_R4_0 is used as the cyclic write target. The AxCon code configures MC_BR_CyclicWrite with DataType = REAL, Mode = mcEVERY_RECORD, and ParID = ACP10PAR_VAR_R4_0.

My question is about migration to Automation Studio 6.3 or newer, with mapp Motion 6.x / current ACP10 versions:

1. Is this ParID-based cyclic current reference method still supported/recommended in AS 6.3+?
2. Are ParIDs 325 / ICTRL_ADD_SET_PARID and 4128 / VAR_R4_0 still valid for this use case on current ACOPOS / ACOPOS P3 systems?
3. Is there now a standard mapp Motion / MpAxis way to command a current reference directly, or is the recommended solution still to use MC_BR_CyclicWrite with drive ParIDs?
4. Are there any migration risks when importing this older AxCon/CycAxCon structure into AS 6.3+, especially around MpAxisBasic, MC_BR_CyclicWrite, MC_BR_WriteParID, and controller enable/disable behavior?
5. If this approach is no longer recommended, what would be the correct AS 6.3+ architecture for a current-controlled axis?
6. From B&R’s point of view, should cyclic torque reference and cyclic current reference behave equivalently after applying the motor torque constant, or are there internal control-loop / scaling / filtering / limitation differences that can explain a different dynamic response?

We also tested the standard cyclic torque reference approach. However, the system response was unfortunately not the same as with the current-reference method. With the current-reference structure, we get noticeably better behavior and can control the system more precisely/stably. This is the main reason why we would like to keep using this method if it is still supported.

At the same time, we would also like to understand whether there is a real technical difference between commanding torque through the standard mapp Motion torque interface and commanding current through the additive current setpoint ParID. In theory these are related through the motor torque constant, but in our application the dynamic response is not identical. We would appreciate comments on why this difference may occur.
For context, the standard MpAxisCyclicSet interface seems to provide cyclic position, velocity and torque setpoints, but our application requires current reference in amperes because our own controller calculates motor current directly. Converting to torque reference is possible in theory using motor torque constant, but the existing B&R-provided solution was intentionally built around current reference.

Any guidance, migration notes, or examples for AS 6.3+ would be appreciated.

Best regards.

[valerio.manenti]

Hi @omer.alumur ,

a lot of questions…hehe
Please first review the information we have in the Help:
Migrating from ACP10_MC to mapp Axis

mapp Axis

Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio,

thank you for the links. I reviewed the ACP10_MC to mapp Axis migration information. It is helpful for the general migration, but I still need confirmation for the ACOPOS drive-level current reference path.

Our current AS4 project does not only use a standard cyclic torque setpoint. It writes a REAL value cyclically to VAR_R4_0 and sets ICTRL_ADD_SET_PARID / ParID 325 to this REAL ParID, so the value is used as an additive current-controller setpoint.

For AS 6.3+ / mapp Motion 6.x / ACOPOS P3, could you please confirm the following specific points?

1. Is using ICTRL_ADD_SET_PARID pointing to a cyclic REAL ParID still supported for cyclic current reference?
2. If yes, should the old MC_BR_CyclicWrite implementation be migrated to MC_BR_CyclicProcessParID_AcpAx with cyclic write mode?
3. Are ParID 325 and the VAR_R4_x / user REAL ParIDs still valid on current ACOPOS / ACOPOS P3 systems for this use case?
4. Is there any standard mapp Axis / MpAxis interface for commanding current directly in amperes, or is ParID-based cyclic write still the intended solution?
5. From the drive-control point of view, does the mapp cyclic torque interface pass through the same internal path as the additive current-controller setpoint, or can scaling, filtering, torque limiting, current limiting, or control-loop placement explain a different dynamic response?

We already tested the standard cyclic torque setpoint approach, but the measured system response is not equivalent to the existing current-reference implementation. Therefore we would like to know whether keeping the current-reference architecture is supported and what the correct AS6.3+ migration path is.

[valerio.manenti]

Hi @omer.alumur ,

Ok I have one ACOPOS P3 and I have 2 options to control that: one with Legacy ACP10 and the second one with new mapp Motion, but if at low level the Drive functions are the same where do you see the problem?

ICTRL_ADD_SET_PARID is part of current control, current control is implemented in the same way in the both systems (legacy ACP10 and mapp Motion)

Is using ICTRL_ADD_SET_PARID pointing to a cyclic REAL ParID still supported for cyclic current reference?

yes

If yes, should the old MC_BR_CyclicWrite implementation be migrated to MC_BR_CyclicProcessParID_AcpAx with cyclic write mode?

I did that normally when I converted few prj from ACP to mapp Motion

Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

Hi @Valerio,

thank you, this is helpful.

I understand your point that the low-level ACOPOS drive functions are the same and that ICTRL_ADD_SET_PARID belongs to the current-control part of the drive. That answers an important part of my question.

The point I would still like to clarify is the correct AS6 / mapp Motion implementation path.

In the old AS4 / ACP10 project, the B&R-provided AxCon structure uses MC_BR_CyclicWrite to write a REAL value cyclically to VAR_R4_0. ICTRL_ADD_SET_PARID is then set to this ParID, so our value is used as additive current setpoint of the current controller.

For AS 6.3+ / mapp Motion 6.x / ACOPOS P3, should this be migrated to MC_BR_CyclicProcessParID_AcpAx from McAcpAx, using cyclic write to the same VAR_R4_x parameter?

Could you please confirm these points?

1. Is the concept “ICTRL_ADD_SET_PARID points to a cyclic REAL ParID such as VAR_R4_x” still a supported ACOPOS/P3 method for cyclic current reference in mapp Motion?

2. Can VAR_R4_0 / ParID 4128 still be used for this purpose, or is another user REAL ParID recommended in AS6/mapp Motion?

3. Are there any special migration notes regarding enable/disable behavior, PCTRL_ENABLE_PARID, cyclic timing, current limits, or reset behavior when moving this structure from ACP10_MC to mapp Motion/McAcpAx?

4. Regarding the standard mapp Motion cyclic torque interface: does it internally pass through exactly the same current setpoint path as ICTRL_ADD_SET_PARID after applying the motor torque constant, or can there be additional scaling, filtering, torque limiting, current limiting, set-current adaptation, or loop-placement differences?

The reason for the question is that we tested the standard cyclic torque setpoint approach, but the measured system response is not equivalent to the existing current-reference implementation. The current-reference path gives noticeably better dynamic behavior in our application.

So my main concern is not whether the current controller exists in both systems, but whether keeping this current-reference architecture is supported and what the recommended AS6/mapp Motion function block architecture is.

Best regards.

[valerio.manenti]

Hi @omer.alumur ,

The reason for the question is that we tested the standard cyclic torque setpoint approach, but the measured system response is not equivalent to the existing current-reference implementation. The current-reference path gives noticeably better dynamic behavior in our application.

This is very interesting…We should see the different behavior on the axis trace.

Our key ParID is 325: ICTRL_ADD_SET_PARID

Are we 100% sure we have that parID implemented on mapp Motion?
Let’s have a look on the library:

Yes we are.

Let’s look at the diagrams:

As you see below, your ICTRL_ADD_SET_PARID is one input of our ICTRL_ISQ_REF (CTRL Current: Set stator current quadrature component [A]), but there are others:

If you see differences on the output (ICTRL_ISQ_REF) on 2 systems (ACP10 and mappMotion) we should see them on the traces.
it’s possible some other parameters are configured in different way.

=================

Is the concept “ICTRL_ADD_SET_PARID points to a cyclic REAL ParID such as VAR_R4_x” still a supported ACOPOS/P3 method for cyclic current reference in mapp Motion?

There is no change on mapp Motion for ICTRL_ADD_SET_PARID, there is the same access RD/WR and the same value, a ParID.

Can VAR_R4_0 / ParID 4128 still be used for this purpose, or is another user REAL ParID recommended in AS6/mapp Motion?

yes you can use VAR_R4_0 parID for that purpose on mapp Motion too

I see it’s defined on mapp Motion too

Are there any special migration notes regarding enable/disable behavior, PCTRL_ENABLE_PARID, cyclic timing, current limits, or reset behavior when moving this structure from ACP10_MC to mapp Motion/McAcpAx?

no particular note related to mapp Motion:

I see it’s defined on mapp Motion too

>Regarding the standard mapp Motion cyclic torque interface: does it internally pass through exactly the same current setpoint path as ICTRL_ADD_SET_PARID after applying the motor torque constant, or can there be additional scaling, filtering, torque limiting, current limiting, set-current adaptation, or loop-placement differences?

not sure which standard mapp Motion cyclic torque interface you are referring to. Could you give me more details about that?

Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio,

thank you very much for the detailed answer and for checking the library and diagrams.

This is very helpful for us. I now understand that ICTRL_ADD_SET_PARID is still available in mapp Motion, that there is no change regarding its access/value, and that VAR_R4_0 / ParID 4128 can still be used for this purpose. This answers the most important migration question for our existing current-reference architecture.

Regarding your question:

not sure which standard mapp Motion cyclic torque interface you are referring to. Could you give me more details about that?

I am referring to the cyclic torque setpoint path provided by the mapp Axis / MpAxis cyclic set interface. In our tests, instead of writing current [A] cyclically to VAR_R4_0 and using ICTRL_ADD_SET_PARID, we converted our controller output from current to torque using the motor torque constant and commanded this value through the standard cyclic torque setpoint interface of mapp Motion / MpAxisCyclicSet.

So the two tested variants were:

Variant 1, existing current-reference path:
Application controller current reference [A]
→ cyclic write to VAR_R4_0 / ParID 4128
→ ICTRL_ADD_SET_PARID / ParID 325 points to VAR_R4_0
→ additive current setpoint
→ ICTRL_ISQ_REF / current controller

Variant 2, standard cyclic torque path:
Application controller current reference [A]
→ converted to torque using motor torque constant
→ cyclic torque setpoint through mapp Motion / MpAxisCyclicSet
→ drive/mapp Motion internal torque-to-current path
→ current controller

With Variant 2, the measured mechanical response was not equivalent to Variant 1. Variant 1 gives noticeably better dynamic behavior and stability in our application.

Based on your diagram, I understand that ICTRL_ADD_SET_PARID is one input into the current setpoint path and that there are other inputs, limiters and filters before ICTRL_ISQ_REF. This could explain why the two approaches are not identical.

Would it be possible to clarify where the mapp Motion cyclic torque setpoint enters this internal structure?

More specifically:

1. Does the cyclic torque setpoint from MpAxisCyclicSet finally contribute to ICTRL_ISQ_REF through the same path as ICTRL_ADD_SET_PARID, or does it pass through additional torque/current conversion, filtering, limiting or set-current adaptation before reaching ICTRL_ISQ_REF?

2. Which internal signals / ParIDs would you recommend tracing in both variants to compare the behavior properly?

We are planning to trace at least:

• our application current reference
• VAR_R4_0 / ParID 4128
• ICTRL_ISQ_REF
• ICTRL_ISQ_ACT
• SCTRL_SPEED_ACT
• relevant current/torque limits if available

If there are specific ParIDs or trace variables that would make the comparison between the cyclic torque path and the ICTRL_ADD_SET_PARID path clearer, please let us know.

Also, for the AS6 / mapp Motion implementation, we assume that the old ACP10 MC_BR_CyclicWrite should be migrated to the mapp Motion / McAcpAx cyclic ParID mechanism, for example MC_BR_CyclicProcessParID_AcpAx with cyclic write mode. Is this the recommended function block path for writing VAR_R4_0 cyclically in AS6?

Best regards,
Omer

[valerio.manenti]

Hi @omer.alumur ,
Variant 1: no issue, you can migrate your logic from [AS 4 + Legacy ACP10] to [AS 6 + mapp Motion]. For cyclic read/write ParID you can use MC_BR_CyclicProcessParID_AcpAx on mapp Motion.

Variant 2: When you call MpAxisCyclicSet (AS Help: Services → Legacy → MpAxisCyclicSet):

Which is your TorqueSetup on MpAxisCyclicSetParType? In particular which mode are you using?

Example: if your mode is mpAXIS_TORQUE_MODE_LIMIT:

it’s clear if the Variant2 is implemented in this way, it works in different way than Variant 1.

Ciao
Valerio

[michael_w]

Hi there,

disclaimer: I don’t know the motor and the exact details of the implementation of the torque limiter, but I can take a guess why you might experience differences:
Torque is, as you are aware and use properly, a direct relation to current. What the drive knows, though, is that the torque constant is… /not/ constant on a synchronous motor, depending on where it is operating. Up until the rated current, one can assume a constant value, but after that, the torque constant changes - and the drive takes that into account. You can easily check that: T_Stall / I_Stall = kT (roughly, on B&R motors with electronic nameplate the value is measured and stored and might differ slightly), T_Max / I_Max is different. The drive will interpolate the value between I_Rated and I_Max. Depending on where on the current graph you are operating, that might explain differences.

Example: 8LSA25.D8060S000-3 | B&R Industrial Automation (the first motor in the list, just a random choice, but the same goes for any other motor there)

kT = 0.73 Nm/A

Stall Torque = 0.6 Nm	Stall Current = 0.82 A	kT = 0.73 Nm/A
Rated Torque = 0.52 Nm	Rated Current = 0.71 A	kT = 0.73 Nm/A
Max Torque = 2.4 Nm	Max Current = 3.7 A	kt = 0.65 Nm/A

Maybe that helps a little

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio, hi Michael,

thank you both, this is very helpful.

Valerio, your answer regarding Variant 1 clarifies the most important point for us. We now understand that our existing AS4 + legacy ACP10 current-reference logic can be migrated to AS6 + mapp Motion, and that the recommended mapp Motion implementation path for cyclic ParID access is MC_BR_CyclicProcessParID_AcpAx. This answers our main migration concern.

Regarding Variant 2 and MpAxisCyclicSet:

You are right, the exact TorqueSetup.Mode is very important here. I will check the test project again and confirm which mode was used. It may be that our first comparison was not a true 1:1 comparison with the current-reference path, especially if the mode was mpAXIS_TORQUE_MODE_LIMIT or another mode where the torque input is not used as a direct torque/current reference.

My understanding from your screenshots is:

• mpAXIS_TORQUE_MODE_LIMIT behaves as a torque limiter, so it is clearly not equivalent to writing an additive current reference through ICTRL_ADD_SET_PARID.
• mpAXIS_TORQUE_MODE_FF and mpAXIS_TORQUE_MODE_RAMPED_CTRL may also have different internal behavior compared to the additive current path, depending on speed controller involvement, ramping, filtering and limit handling.

Could you please confirm which TorqueSetup.Mode would be the closest possible comparison to our Variant 1 current-reference method?

Variant 1:
Application current reference [A]
→ VAR_R4_0 / ParID 4128
→ ICTRL_ADD_SET_PARID / ParID 325
→ ICTRL_ISQ_REF

Variant 2:
Application current reference [A]
→ conversion to torque
→ MpAxisCyclicSet.Torque / CyclicTorque
→ internal torque/current handling
→ ICTRL_ISQ_REF

For the comparison, we plan to trace the following signals in both variants:

• application current reference
• VAR_R4_0 / ParID 4128
• MpAxisCyclicSet torque command
• ICTRL_ISQ_REF
• ICTRL_ISQ_ACT
• SCTRL_SPEED_ACT
• relevant torque/current limits
• possibly the selected TorqueSetup.Mode and related ramp/speed-controller parameters

Michael, thank you for the explanation regarding the motor torque constant. This is a very good point. In our initial torque test we converted current to torque using a constant motor torque constant. We will check whether our operating range is close to or above rated current, because in that region the drive’s internal torque-to-current conversion may use a different effective kT than our simple constant conversion. That could definitely explain part of the difference between the two variants.

So our next step will be:

1. Confirm the exact TorqueSetup.Mode used in the MpAxisCyclicSet test.
2. Repeat the test with the mode that B&R recommends as the closest equivalent to direct torque/current reference.
3. Compare ICTRL_ISQ_REF and ICTRL_ISQ_ACT between the current-reference and torque-reference variants.
4. Check whether the difference comes from torque mode behavior, current/torque limits, filtering/ramping, or nonlinear torque constant handling.

If ICTRL_ISQ_REF is identical in both variants but the mechanical response is still different, then we will look elsewhere in the application. If ICTRL_ISQ_REF is different, then the difference is clearly introduced before the current controller by the torque interface, scaling, mode behavior or limits.

Best regards,
Omer

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio, Hi Michael,

Regarding our current project setup: We are not using MpAxisCyclicSet in the legacy project yet. Instead, we are using a custom library called CycAxCon that implements the cyclic current reference by directly interacting with ACP10 ParIDs (Variant 1). Specifically, when we enable the cyclic current mode, the library performs the following sequence:

1. Disables the position controller (PCTRL_ENABLE_PARID / ParID 231 = 0).
2. Maps the additive current setpoint (ICTRL_ADD_SET_PARID / ParID 325) to VAR_R4_0 (ParID 4128).
3. Enables cyclic writing to VAR_R4_0 (ParID 4128).
4. Disables the speed controller by resetting its controller parameters. This completely bypasses both the position and speed loops, giving us a direct path to the current controller loop (ICTRL_ISQ_REF).

Regarding Valerio’s question on TorqueSetup.Mode (Variant 2): You are absolutely right. If we used mpAXIS_TORQUE_MODE_LIMIT during our initial tests, the speed/position controllers would still be active, meaning it was not a true equivalent to our current direct current path (Variant 1). We will check the configuration and make sure to test with mpAXIS_TORQUE_MODE_FF while keeping the speed loop disabled/inactive to perform a proper 1:1 comparison.

Regarding Michael’s point on the motor torque constant (kTkT​): This is an excellent explanation for the difference in dynamic response. In Variant 1, we write the current reference directly. In Variant 2, we convert the current to torque in the PLC using a constant kTkT​ factor, but the drive converts it back to current using its internal, non-linear kTkT​ interpolation (taking magnetic saturation into account at higher currents).

Since our application operates near/above the rated current region, this non-linear interpolation by the drive will result in different effective current references (ICTRL_ISQ_REF) compared to our direct current write method.

As a next step, we will trace both ICTRL_ISQ_REF and ICTRL_ISQ_ACT in both variants to verify if the difference indeed stems from this torque-to-current conversion discrepancy or the selected torque mode configuration.

Best regards, Omer

[omer.alumur (Ömer Sezai Alumur)]

@omer.alumur

CycAxCon

CycAxCon.zip (3.1 KB)

I’m sharing the CycAxcon structure with you. A B&R support representative actually put this together back in the day, but since that was years ago and I can’t reach them now, I’m sharing it so you can get an idea of what it’s like.

[valerio.manenti]

Hi @omer.alumur ,
I think will be helpful for us having some basic information about what is doing your motor/axis that required a not usual configuration.
In other words few words about the application.

Regarding a possible alternative implementation, for your test (Legacy ACP10 and AS4) on the existing current control made with SPT, I would recommend MC_BR_TorqueControl:

Plus you can define Max velocity in both directions:

Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio,

Thank you for the suggestion regarding MC_BR_TorqueControl and for asking about the application. Here are some details about our project and why we require this control logic:

**1. The Application:**

We are controlling a **6-DOF Stewart Platform (Motion Simulator)**. We run a custom Disturbance Observer and Terminal Sliding Mode controller in C-code on the PLC at **2500 Hz (400 μs)**. We need to bypass the drive’s speed and position loops and write the current/torque reference directly to prevent cascade loop interference and minimize phase lag.

2. Transition to mapp Motion (AS6)

For our AS6 migration, we have transitioned to using MpAxisCyclicSet in Torque Control Mode (TorqueControl = true and UseVelocityLimits = true), just as you suggested.

Since MpAxisCyclicSet expects torque reference (Nm), we convert our DOB controller’s current output (Amperes) to torque using the motor’s torque constant (Kt = 2.22 Nm/A for our 8LSA84 synchronous motor):

CyclicTorque = I_desired * Kt

This matches your recommended approach of using torque control with velocity limits, and it fits perfectly with our migrated structure under mapp Motion.

I’d also like to point out that, in order to understand the difference between the two control methods, I’m not assigning you any records because we tested both methods on the system. As I mentioned, after converting the product that was experiencing the issue I described to the method where we provide a current reference, we sent it to the customer. However, I’ll check my records to see if I can find anything.

Thanks again for your guidance!

[valerio.manenti]

@omer.alumur

6-DOF Stewart Platform (Motion Simulator)

6-DOF Stewart Platform (Motion Simulator)

Super cool application!
Thanks for your feedback
Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

Hello Valeria,

Following up on the discussion about adapting a cyclic current reference structure to Automation Studio 6.3+ using mapp-motion, I have successfully implemented and compiled a solution to drive our 6-DOF motion platform actuators via direct cyclic current injection (Iref​ in Amperes), bypassing the drive’s internal torque-to-current conversion block.

Here is the exact architecture and implementation workflow we followed. We would appreciate any feedback or comments on this approach:

---

1. ACOPOS Parameter Table Configuration (.apt)

To inject the additive current reference directly into the current controller loop, we mapped the pointer parameter ICTRL_ADD_SET_PARID to point to the user-writable REAL register VAR_R4_0.

In the parameter table (.apt) assigned to the axis features:

xml

<Parameter Name="ICTRL_ADD_SET_PARID" ID="325" Value="4128" Description="Additive current setpoint ParID points to VAR_R4_0" />

---

2. Header and Data Structure Setup (C / ST equivalent)

Instead of the legacy ACP10 library (CycAxCon / MC_BR_CyclicWrite), we use MC_BR_CyclicProcessParID_AcpAx and McAcpAxCycParIDType from the McAcpAx library.

Variable Definitions:

• cyclicWrite : MC_BR_CyclicProcessParID_AcpAx (Function Block)
• cycParIDWrite : McAcpAxCycParIDType (Configuration Structure)
• refCurrent : REAL (PLC variable holding the calculated current reference in Amperes)

---

3. Initialization (_INIT / Driver Startup)

We initialize the ParID writing structure to register our cyclic variable:

c

// Configure the cyclic ParID write destination structure

cycParIDWrite.ParID            = 4128;                       // VAR_R4_0 (ParID 4128)

cycParIDWrite.VariableAddress  = (UDINT)&refCurrent;         // Pointer to the REAL current reference

cycParIDWrite.DataType         = mcACPAX_PARTYPE_REAL;       // REAL data type (11)

cycParIDWrite.RefreshMode      = mcACPAX_CYCLIC_EVERY_RECORD;// Update every cycle (1)

// Configure the Cyclic Process ParID function block

cyclicWrite.Axis               = (struct McAxisType*)gAxis;  // McAxis reference link

cyclicWrite.DataAddress        = (UDINT)&cycParIDWrite;

cyclicWrite.NumberOfParIDs     = 1;

cyclicWrite.Mode               = mcACPAX_CYCLIC_PARID_WRITE; // Write mode (1)

cyclicWrite.Enable             = false;                      // Enabled cyclically when torque loop goes active

---

4. Cyclic Logic (_CYCLIC task in Task Class 1)

To ensure the drive is in torque control mode (disabling internal position/velocity loop outputs) but receives our current setpoint instead of torque:

1. We set the standard cyclic torque reference (MpAxisCyclicSet.CyclicTorque) to 0.0.
2. We perform saturation/clamping directly in Amperes on the PLC controller side between minCurrent and maxCurrent.
3. We write the saturated current reference into refCurrent.
4. We call MC_BR_CyclicProcessParID_AcpAx cyclic function block.

c

// 1. Keep the standard cyclic torque setpoint at 0.0 to disable internal loop contributions

torqueModeDrive.CyclicTorque = 0.0f; 

// 2. Calculate, saturate and assign current reference (Amperes) on PLC side

refCurrent = (float)Saturation(pAct.controller.current.actual.current, 

                                pAct.controller.dob.parameter.minCurrent, 

                                pAct.controller.dob.parameter.maxCurrent);

// 3. Cyclically process the ParID write block

// We enable the block only when Torque Control is active on the drive

cyclicWrite.Enable = torqueModeDrive.TorqueControlActive;

// Call the function blocks

MpAxisCyclicSet(&torqueModeDrive);

MC_BR_CyclicProcessParID_AcpAx(&cyclicWrite);

---

5. Timing and Synchronization

To ensure minimum jitter and synchronized transmission over the POWERLINK network:

• The PLC task is assigned to Task Class 1 running at a cycle time of 400 µs.
• The CPU cycle is synchronized to the POWERLINK SoC interrupt (IPLK).
• OutputJustInTime is enabled (on) in the POWERLINK configuration, ensuring that the written VAR_R4_0 value is pushed onto the network immediately after Task Class 1 completes execution, reaching the ACOPOS drive in the very next network cycle.

Questions for the community:

1. Are there any known caveats when combining MpAxisCyclicSet with zero torque reference and cyclic ParID writing using MC_BR_CyclicProcessParID_AcpAx?

Thanks in advance for your inputs!

[valerio.manenti]

@omer.alumur

1. Are there any known caveats when combining MpAxisCyclicSet with zero torque reference and cyclic ParID writing using MC_BR_CyclicProcessParID_AcpAx?

I have to check with Support your interesting point.

For what we see from the documentation, MC_BR_TorqueControl does not use ICTRL_ADD_SET_PARID, so it should still be accessible by the application program, but before to make mistakes and damage something…I would like to clarify with Support how the drive firmware behaves if a torque control is active and an additive current is set via ICTRL_ADD_SET_PARID.

Ciao
Valerio

[omer.alumur (Ömer Sezai Alumur)]

@valerio.manenti

I have to check with Support your interesting point.

Hi Valerio,

Thank you for checking this with Support. I agree that it is better to clarify the drive firmware behavior before testing this on hardware.

I’ll wait for your feedback regarding the interaction between active torque control and additive current via ICTRL_ADD_SET_PARID.

Best regards,

[omer.alumur (Ömer Sezai Alumur)]

Hi Valerio,

Here is an update on what we have tested on the hardware, the challenges we faced, and the current status of our implementation.

To recap, we are migrating a 6-DOF Stewart Platform from AS4 + Legacy ACP10 to AS6 + mapp Motion, requiring us to dynamically map the cyclic current reference to VAR_R4_0 (ParID 4128) and feed it into the current controller loop via the additive current channel ICTRL_ADD_SET_PARID (ParID 325).

Here is the step-by-step process of what we implemented, the issues we encountered, and what we have tried so far:

---

Step 1: Dynamic Parameter Mapping (Write-Only Parameter Fix)

Initially, during drive startup, we encountered a PLCopen error: Read access for a write-only parameter; ParID: 777

• Reason: FUNCTION_BLOCK_CREATE (ParID 777) is a write-only register. In our initial dynamic initialization code, we tried to verify its mapping status using a GET command, which caused the drive to error out.
• Solution: We redesigned the initialization state machine in C to execute sequential, write-only (SET) commands without reading back.
  • First, we write 4096 to ParID 777 (which allocates FB0 dynamically).
  • Once completed (processParID.Done == true), we configure processParID to write 4128 (mapping VAR_R4_0) to ICTRL_ADD_SET_PARID (ParID 325) and execute.
  • This resolved the startup faults, and the drives now power on successfully with sptInitState == 3 (Ready).

---

Step 2: The Platform Sagging / Slipping Issue

Once the drives powered on successfully, we commanded the system to the INITIALIZING state. However, during the buzzer timer phase (when the brakes release but before movement starts), the platform immediately fell under its own weight.

• Reason: In our initial cyclic logic, we tied the cyclic write enablement to the torque control loop status:

  c
  

  cyclicWrite.Enable = torqueModeDrive.TorqueControlActive && (sptInitState == 3);

  During the buzzer phase, the axis is controlled in closed-loop velocity control (VELOCITY_CONTROL with 0.0 reference speed) via MpAxisBasic to hold its position. Because the drive is not in cyclic torque mode, TorqueControlActive is FALSE. Consequently, cyclicWrite remained disabled, and the computed holding current (gravity compensation) was not written to VAR_R4_0, resulting in a zero holding current setpoint.

---

Step 3: Attempted Fix (Enabling Cyclic Write on Power-On)

To ensure the gravity compensation reference is written before the brakes release and during the velocity control phase, we updated the enablement interlock of MC_BR_CyclicProcessParID_AcpAx to be active as soon as the drive is energized/powered (module.Power is TRUE):

c

cyclicWrite.Enable = pAct->units.driver.externalVariable.module.Power && (pAct->units.driver.externalVariable.sptInitState == 3);

Since the C-code calculation computes the holding current (refCurrent) continuously during this state, we expected that enabling cyclicWrite here would update VAR_R4_0 on the drive while it is still in velocity control.

---

Current Problem

Unfortunately, the platform still falls/sags under its own weight during the buzzer phase, even with cyclicWrite.Enable set to TRUE as soon as the drive powers on.

It seems the drive is not applying the additive current setpoint while it is in velocity control mode under MpAxisBasic.

Questions for the community / Support:

1. Does the ACOPOS drive firmware process the additive current ICTRL_ADD_SET (ParID 325) when the axis is powered and controlled in velocity control mode via MpAxisBasic?
2. If yes, is there an additional parameter or configuration (e.g. enabling the additive current channel in the speed controller parameters) that we need to define to make sure the speed loop includes this offset?
3. In the legacy CycAxCon library (ACP10), the cyclic current reference was fed immediately upon power-on. Under mapp Motion, what is the recommended way to apply a gravity compensation current before or during the transition from velocity-controlled brake release to cyclic torque control?

We would appreciate any insights or suggestions.

Best regards,
Ömer

[valerio.manenti]

Hi @omer.alumur ,

I’ll wait for your feedback regarding the interaction between active torque control and additive current via ICTRL_ADD_SET_PARID.

I got a feedback from L2: “It seems that this isn’t as easily answered as we hoped. We need to get this checked in detail by our firmware team. For that we need a CASE though.”
I’m going to create a CASE so R&D can review the interaction between active torque control and active torque control.

Issue with VAR_R4_0

Can you login to our website?
We have a training module, TM471 for ACOPOS function blocks very helpful. Download that when you have time.

You can add 2 lines in your ACOPOS parameters table too, so you can simplify the code in your prj

With AS6 we have a graphical SPT editor: SptChartEditor. In your case you have only one ACOPOS function block VAR_R4_0, so no complex logic, but who knows in the future, maybe you have new challenge…

In the legacy CycAxCon library (ACP10), the cyclic current reference was fed immediately upon power-on. Under mapp Motion, what is the recommended way to apply a gravity compensation current before or during the transition from velocity-controlled brake release to cyclic torque control?

CycAxCon is not a standard B&R library but a user library developed, for what I have understood, from one B&R application engineer in the past.
We need more information about the implementation, but unfortunately this is out of scope of community.
I recommend to call our B&R Support in your region so they can have a look of the prj.

Ciao
Valerio