Part Change Notification
This page describes the relevant product specifications changes between the different manufactured revisions.
Product revisions
Revision | Date | Notes |
|---|---|---|
B |
| Initial version |
C |
| Definition of the new change between Phase 1 (historical) and Phase 2 products |
All Everest S Safe Net customers currently operating with the Phase 1 safety firmware (also referred to as Safe Communications) are now eligible to upgrade to the Phase 2 safety firmware (also referred to as Safe Motion).
This document provides an overview of the changes introduced with the Phase 2 firmware, outlines the impact on the product, and describes the required procedure for performing the firmware update.
Page contents
Summary of the change
The previous firmware architecture offered a limited set of feedback‑independent safety functions, primarily oriented to basic motion inhibition and shutdown sequences. These functions ensured fundamental safety compliance but did not support motion‑dependent or feedback‑based safety features. The supported functions included:
Safe Torque Off (STO)
Safe Stop 1 time controlled (SS1-t)
Safe Input (SI)
The upgrade from Phase 1 to Phase 2 introduces a significantly expanded safety feature set, incorporating advanced, feedback‑dependent Safety Motion functions, explicitly activated via FSoE mapping. The newly supported safety functions include:
Safe Output (SOUT)
Safe Stop 1, ramp/deceleration controlled (SS1-r)
Safe Stop 2, time and ramp/deceleration controlled (SS2)
Safe Operating Stop (SOS)
Safe Speed Range (SSR)
Safely Limited Speed (SLS)
Safely Limited Position (SLP)
Safely Limited Increment (SLI)
Safely Monitored Direction (SDI)
These additional safety functions are available exclusively when a supported redundant feedback combination is implemented.
Further details regarding the individual safety functions and the applicable supported feedback combinations are provided in the Safety Manual.
The release notes provide a detailed description of the improvements and bug fixes incorporated in the new firmware release, aimed at enhancing overall system performance, robustness, and reliability.
Reason for the change
Functional Differences
These enhancements enable safer, more flexible, and more efficient machine control strategies. The safety functions include a set of feedback‑based safety mechanisms that require a redundant feedback architecture; in the absence of such redundant feedback channels, configured in the Object 0x46FA - Feedback scenario, these functions cannot be activated or used.
All safety functions, their expected behavior, configuration rules, and state transitions follow the definitions and requirements set forth in ETG.6100.
Firmware Architectural Changes
The new Safety Motion architecture incorporates a dynamic FSoE mapping that allows the system to flexibly select which safety functions are enabled at when arriving into Data State.
This mapping must strictly adhere to the FSoE frame construction rules, ensuring that each safety function is correctly positioned, encoded, and validated within the communication frame. Any mapping that fails to comply with these structural requirements will be detected as invalid, triggering an error condition that prevents the drive from exiting its Safe State. As a result, the integrity of the safety channel is maintained, and the system guarantees that only verified and correctly constructed mappings can be used during operation.
SRA Configuration CRC
The latest release of the Safety Motion Firmware introduces enhanced functionality by expanding support for Safety-Related Application (SRA) validation to a total of three dedicated slots — one more than in the previous version. Each validation slot is uniquely associated with a specific set of Safety‑Related parameters that are automatically downloaded during the boot-up sequence and subsequently used to verify and authenticate the application’s integrity before operation. This allows greater flexibility when deploying multiple validated configurations or switching between predefined safety profiles.
All available validation slots, along with their corresponding module information, can be identified in Object 0xF050 – Detected Module List, which provides a structured overview of the detected Safety‑Related components and their assigned parameter sets.
The two validation slots available in the previous firmware version comply fully with the applicable safety standards defined in ETG.5100 and ETG.5120. In contrast, the additional slot introduced in the latest release transfers the CRC value computed within the manufacturer‑specific Object 0x4400 - Safety Project CRC. The customer is responsible for calculating this CRC offline, based on all relevant safety parameters, and providing the resulting value to the master device for use during the validation process. This last slot is intended to use in FSoE masters without a native SRA CRC support or have memory constraints that prevent them from using the two standard validation slots.
As in the previous firmware version, only one validation slot can be activated at a time through Object 0xF030 - Configured Module Ident List. Switching between slots requires updating the master’s application logic accordingly. The validation through the SRA CRC is a requirement to transition into FSoE Data State, if it fails the drive will remain in its Safe State.
Expected customer actions
Customers are encouraged to review the detailed descriptions of the safety functions as outlined in the Safety Manual.
The transition to the new Safety Motion firmware requires a structured migration approach to ensure functional integrity, safety compliance, and predictable system behavior. The following steps outline the recommended strategy for upgrading existing applications to the new architecture. This migration procedure assumes that the application intends to preserve the same FSoE mapping structure used in the previous firmware version, which the new firmware maintains as the default dynamic mapping.
Upgrade firmware following the firmware installation procedure. Once the device successfully boots into the new firmware version, verify device identity and version.
Generate the new mapping for the application. The default mapping created by the new firmware is the same used in the static mapping in the previous version, so to keep the application characteristics this step can be skipped.
Configure Safety Related Application parameters from the slave side. The upgrade will return all the parameters into their default state.
Configure Safety Related Application parameters from the master side (if the mapping has been changed in step 2).
Select the slot to be used
Slot 1 or Slot 2 will follow the same steps as in the previous firmware version.
Slot 3 needs an offline calculation with all the SRA parameters.
Revalidate the Safety Application
FAQ
Do I need to update my PLC safety logic?
→ Yes, in most cases, due to dynamic FSoE mapping.
Are all previous safety functions still supported?
→ Yes, but their communication structure may differ.
Why is there now a Configuration CRC?
→ Because the new firmware includes many more safety parameters that must be validated automatically.
Does the update affect cycle times or communication behavior?
→ FSoE frame size may change depending on enabled functions.
What if I only used STO in the past?
→ Migration is simple; minimal changes are required.