Hi community,
What’s happening
Coupled Y/Z agitation via ACP10 cam automat, slave = center + norm*distance (norm -0.5..+0.5,
Polynomial5 cam). With start 25 mm, distance 25 mm, cycle 10 s, accel 50 mm/s2 the Y axis runs
into its +SW end (54 mm) and errors.
In the trace:
- “Cam automat: Set position” stays bounded (~22..38 mm).
- “CTRL Set position” DECOUPLES from it and runs up to ~54 mm (SW end).
- “CTRL Set speed” peaks at ~54 mm/s, although limit.v_pos = 10 mm/s.
- Braking distance from 54 mm/s at 50 mm/s2 = v^2/(2a) ≈ 29 mm > amplitude (±12.5 mm),
so the setpoint can’t reverse inside the figure and overshoots to the SW end.
The cam has steep endpoint slope (Dy=±10) and sharp -0.5->+0.5 transitions.
Questions:
- Why does the cam automat generate a SET velocity (~54 mm/s) far above limit.v_pos (10 mm/s)?
Are axis v/a limits not applied to cam following / the synchronization (compensation) move?
- Is CTRL set decoupling from cam automat set expected, or a config issue (compensation mode)?
- Recommended way to reject invalid distance/cycle/accel combinations BEFORE start instead of
running into the SW end?
What I’ve tested
- distance 20, accel 50: clean (±10 mm), no error.
- distance 25, accel 50: fails → +SW end.
- distance 25, accel 100: OK (braking distance ~15 mm) - but only shifts the limit.
- Traces confirm CTRL set diverges from cam automat set, and set speed ~54 mm/s >> 10 mm/s limit.
Software / hardware
- Automation Studio 4.12
- Automation Runtime J4.93
- ACP10/ARNC0 5.31.1
- mapp Services 5.24.5
- Hardware: ARsim
Error scenario:
Thank you in advance for the Help!
Hi,
I personally have no clue about drive technology at all.
Nevertheless I’ve question: you mentioned ARsim as hardware target.
May I ask, if this behavior is the same if running on a real PLC (axes still just simulated)?
I’m just asking because many many years ago (long time before mappMotion), I saw some strange behavior with axes in ARsim (it was not comparable to the behavior you described, it was more about position jumps) .
The evaluation of that issue figured out, that the non-realtime behavior of ARsim / the non-exclusive usage of ressources for ARsim caused by Windows was the cause.
The load of the Windows PC was (very) high, and so ARsim was not longer scheduled often enough by Windows (ARsim does not got enough processing time anymore from the GPOS) - but as some functions of the drive simulation were time-based, a to slow scheduling / “temporary freeze” lead to too high jumps in the internal set value generation, as the time base (“ticks”) derived from Windows still have changed even if ARsim was blocked.
Long story short:
I’ve no idea if there’s any context of my 15 years old learning to your issue, but I would at least recommend to use a real PLC with ACOPOS + drive simulation to check if the behavior changes. ARsim is just a simulation which has not the same hardware exclusive access to the processor and the priorization of tasks / functions then the real PLC, so I would at least exclude the different scheduling as cause by doing a test on a hardware PLC.
Best regards!
Hi Alexander,
thank you for your response.
Yes, the behavior is exactly the same on a setup with an X20 CPU and an ACOPOS Micro (this was also the initial setup where it occurred). I was also a bit surprised when I saw that the same behavior appears in the simulation.
Best regards,
Philipp
Okay, thanks for feedback… a pity, but it was worth a try 
So I trust on our motion specialists here in the Community!
But in addition I would propose to contact your local 1st level support with a link to this thread, as it sounds quite specific.
Best regards!
It is not clear what your automat looks like ?
Is it using compensation modes of the automat?
If so, you could look at the MC_BR_CheckAutCompensation function block, which can check compensation parameters.
Probably it is better to contact local/region support for these kind of questions.
