synchronize motion

Would you mind explaining the sequence and why you wish to change the speed...

As you coordinating with the press itself, the conveyors or something else ?

Hmm. About 15 years ago, I worked on a system that had this issue. It was KUKAs, not ABBs, but the basic principle should still be applicable. In this case, instead of syncing the robot speed to the encoder value, the robot's background task was constantly monitoring the distance from the TCP to the "final clear point" before the press (this point was different per program, as we had many different-sized parts, dies, and robot tools).

As long as the press encoder was not within the robot's "clear to enter" range (this also changed, depending on the size of the die), the background task would begin reducing the robot's playback speed on an square-root curve -- basically, as the distance was halved, the speed would be reduced to 1/4. The curve was set so that the robot would achieve 0% speed before it hit the "final clear point" and the Wait-for-Input command that followed it.

The final result was that, when the line was running smoothly, the robots' on-the-fly speed alterations would be minor, and almost invisible, but still keep the robots from ever actually stopping. And when the line sequence was disrupted (backed up, starved, E-Stops, etc), the entire line of presses and robots would come to a smooth halt and be able to recover as soon as the line was clear to move again.

The difficulty with the S4C+ will be that Speedrefresh is not available as in the IRC5. There is the velset instruction, but it does not affect the ongoing motion, only subsequent move instructions.

With S4c+ it would be very difficult, at best. IRC5 should give you the Speedrefresh instruction that can slow the robot in an ongoing movement. Keep in mind that there is a standard servo lag time, 0.3s, I think.