Since RobotWare 8, safety regulations/behaviors seem to have changed: rather than directly triggering a Motor On, resetting the safety signals automatically engages Motor On.
The problem is that without communication-based safety solutions—such as CIP Scalable I/O devices, EtherNet/IP CIP Safety, or PROFIsafe—there is currently no way to trigger a safety signal reset via external PLC signals. As a result, operators are forced to walk around a line tens of meters long to manually press the physical reset/enabling button on the FlexPendant (TPU).
This change completely disregards practical field operations. Is there any method or workaround to execute a safety signal reset using an external signal? Local ABB support is also currently looking into this issue.
1 Like
Based on what I’ve found so far, performing an External Safety Reset on ABB OmniCore controllers strictly requires either a DSQC 1042 CIP Safety device or a network-based Safety Option.
If your robot order does not include a network-based safety option, you must order the DSQC 1042 device together with the controller. You then need to hardwire the physical reset signal to this device and map it in RobotStudio as follows:
- Visual SafeMove → Safe I/O → Function Mapping → Assign the hardwired input signal to ExtReset.
Hope this helps anyone setting up safety reset hardware on OmniCore!
Please note that standard (non-safety) I/O signals cannot be used to perform the reset function under any circumstances. It must strictly be a safety-rated signal mapped through the Safe I/O configuration.
It’s deeply frustrating that a basic function that used to work natively now strictly requires a DSQC 1042 device just for a single signal. This is because the OmniCore Main Computer Unit has zero onboard terminals to receive safety reset inputs.
1 Like
As long as you do not need to comply with the latest ISO safety standard ISO 10218-1:2025 you should be able to downgrade your RW to RW7.x where this is not a requirement.
1 Like
There is an issue where the downgrade process cannot be performed directly in a single step.
We currently have RobotWare 8.1 installed, but when we attempted to downgrade it to 7.21, a system fault occurred.
We barely managed to restore the system using automatic recovery.
We were advised to first downgrade to version 8.0 and then step down to version 7.
However, on an active mass-production line, we simply do not have the time to go through a multi-step downgrade.
As an urgent workaround, we sourced a DSQC1042 CIP adapter device and hardwired it to perform a safety reset, which resolved the issue for now.
If this device is mandatory for such scenarios going forward, this information should have been properly communicated and shared in advance.
Unfortunately, that was not done either, ABB.
You’ve got it all covered. The 1042 is the simplest and most cost effective way to get around this.
