I have an SDC-based stepper application that synchronizes POWERLINK, X2X Link, and TC#1 at 800 µs cycle time. After the application upgraded from mapp Motion 5.26 to mapp Motion 6.5, I’ve seen sporadic cycle time violations even though TC#1 (which runs 14 stepper tasks and 5 virtual axes in synchronized motion) was assigned to its own core on an APC 4100.
We are considering moving some coupled stepper tasks and virtual axis tasks from TC#1 to TC#2 and assigning TC#2 to its own core on the APC 4100. But TC#2 only allows output to delay to the middle of the cycle. How does running TC#2 on its own core affect the accuracy and determinism of stepper control?
(In a broader picture, if TC#2 has the same cycle time as PLK and X2X, is there still any behavior difference between delaying output to the middle of the cycle and not delaying output?)
SDC axis are always based on ACP10 and not compatible with mappMotion. So could you plese check this and tell us a bit more about the application? Which Stepper-modules are used and how are they connected to the used motion system?
SDC: Always used datapoints from the IO-mapping of the X20 stepper modules
mappMotion: Directly connected to the motion system
Beside that: In the past I had also bigger applications with a lot (up to 23) of SDC-axes in ACP10 and later also with mappMotion stepper axes. I know that it needs some CPU power. From my feeling, 14+5 axes in TC#1 with 800µs could be hard to realize - of course depending on a lot of settings and the used PLC. I often used 1.2 or 1.4 ms which were accurate enough for the used applications.
I conflated the term SDC and mapp Motion’s way of controlling stepper axes. I will be more mindful of the terms I use. Here this application has always used mapp Motion.
This application has fourteen (14) X20SM1426 modules. Twelve of the 14 steppers have external encoder feedbacks that go into X20DC1176 modules. The 12 steppers with external encoders are in the same processing unit so their X20SM1426 and X20DC1176 are installed together behind one X20BC0083. The last two steppers are in a different processing unit and installed behind another X20BC0083.
The unit with 12 steppers is made up of 4 identical subsystems. Every subsystem has a virtual axis and its 3 steppers gear in to that virtual axis. The four subsystems do not need to synchronize with each other, so I want to put the virtual axis tasks and stepper tasks for two subsystems (total 6 stepper axes and 2 virtual axes) in TC#1 and assign to Core#1, and the virtual axis tasks and stepper tasks for the other two subsystems in TC#2 and assign to Core#2. (Core#0 runs everything else in this application.)
The unit with 2 steppers similarly gears its two steppers to a virtual axis for that unit. Since the mappMotion processing task class is set to TC#1, I would put this unit’s virtual axis and stepper axes in TC#2 to help balancing the CPU load between the two cores.
The application’s customer insisted on running steppers at 800 µs cycle time. We are trying to understand the reason behind that 800 µs demand (this application ran steppers at 800 µs perfectly fine before upgrading to the multi-core APC, but I don’t think that’s a sufficient reason to hold the cycle time at 800 µs). In the meantime, I want to know if it’s possible to run stepper control in parallel using two cores and, if it’s not possible, what the limiting factors are.
my experience is based on ACP10 with SDC, unfortunately only a bit with mappMotion and Stepper Axis. And with MultiCore I have no experience. So I can’t answer your questions. Hopefully someone else has more experience and can give you more information.
But again: Beside all this, Multicore or not, 14 Stepper axis and some (Pure)Virtual Axis take an amount of CPU Power, especially in 800µs. From all my experience with Stepper axis, normally it’s not necessary to drive this all in 800µs. You will only notice some performance losses in extremely fast applications (high acceleration/deceleration). As long as the topic with MultiCore is not solved, just use 1.2ms. I expect your customer won’t notice it. And 1.2 ms is not only 50% more, its more than 50% because of the overhead stays the same.
I had also some cycle time issues in TC#1, because of ArEventLog functions in combination with mappMotion. Also there is one issue with ReadParId which is solved in mappMotion 6.8.
Otherwise I would move everything else from TC#1 and only keep only the motion tasks in TC#1.
When cycle time violation first appeared after the upgrade, Svc#1.001 seemed to be the culprit that prevented TC#1 tasks from completing in time (usually shortly after the CPU enters run mode following each project transfer):
This, combined with updating to AR 6.7.6 and mapp Motion 6.8.0, seems to allow TC#1 to continue running at 0.8 ms and not triggering cycle time violation after a project transfer!
But I’ve discovered a new form of cycle time violation in which my TC#1 tasks suddenly take 2-3 times longer than usual to complete… (APC 4100 running Hypervisor) That is going to be another story.
>Also there is one issue with ReadParId which is solved in mappMotion 6.8.
Yes Corne, mappMotion 6.8 is a key factor in the improvements we are seeing on the machine; for example, we no longer experience cycle time violations during transfers. The second main improvement, as Gene described, is the way we organized the task classes and cores. The customer is currently running more tests, and once we have final positive feedback, we will share some graphs showing CPU usage across the cores.
At the moment, we don’t have many guidelines in the AS help on how to configure task classes and cores for complex machines. However, on multi-core systems, I see value in dedicating a specific core solely to internal motion system tasks, keeping user tasks off of it entirely.
======
Now we have data:
CPU:
First test 5 cores, but actually we configured task classes for 3 of them, we see some load on core 4 and 5 and they are related to OPC UA (+ stepper controls are running 800 µs):
Going back in time for a bit, after we resolved the cycle time violations that were happening shortly after PLC restart, we discovered this type of cycle time violation repeatedly within 24 hours (often much less than 12 hours) of entering run mode: Many Cyclic #1 tasks (as shown below) suddenly took much longer than they normally needed to complete.
After doing that (plus all the other changes we’ve made), we’ve not seen any more instance of cycle time violation in 3 straight days.
To summarize all the changes that we believe made the greatest difference and allowed us to keep all 14 stepper tasks, 5 virtual axis tasks, and a handful of axis synchronization tasks running in 0.8 ms cycle time:
Upgrade to mapp Motion 6.8
Add the -ansic flag to the IEC build options
Put all of the above axis tasks in Cyclic #1 with 0 tolerance in one CPU core
Put mapp Motion processing task in Cyclic #2 and run it using the same cycle time setting as Cyclic #1 with 0 tolerance in a separate CPU core
