Power-Loss Retention and Synchronous Refresh on Fieldbus Types

Power-loss retention on a fieldbus magnetostrictive sensor has to be looked at as two things: the position value is not lost because absolute position is determined by the physical position of the magnet, independent of electronic memory; configuration parameters are not lost only if they have been written to non-volatile storage. The former is a physical property and is inherently reliable; the latter is an operational issue — skip the store and the next power-up reverts to the original. Synchronous refresh is a different dimension: the synchronisation mechanisms provided by the protocols (SYNC / DC / IRT) can only align the sample instant; they cannot break through the lower bound of the sensor's own update rate. This article makes both sets of mechanisms clear; for the principle of absolute position see Absolute vs. Incremental Position.

Position value: recovered from physical position, not from memory

Magnetostriction measures the distance from the magnet to the fixed end, converted directly from the travel time of the torsional wave. Wherever the magnet stopped during the power loss, after power-up the electronics head issues one interrogation pulse, measures one echo time, and obtains the same position. The whole process needs no homing, no reference-point switch, and does not depend on any data stored before the power loss.

The direct benefit of this property in a fieldbus application is: after an unexpected power loss and power-up, each axis position can be confirmed at once, and the controller can judge whether the present state is safe without running a homing sequence. On hydraulic presses and multi-cylinder synchronous mechanisms this can save a complete motion beat and also avoid the mechanical risk of the homing move itself. For overall configuration of multi-axis systems see Multi-Axis Synchronization: How Many Axes Can One Fieldbus Carry Reliably?.

The bound must be clear: absolute position solves "position not lost on power loss"; it does not equal "no calibration". Mechanical zero offset still has to be set once at installation and then held stable; after a sensor swap it must be rewritten.

Configuration parameters: they must be stored explicitly

Unlike the position value, node address, baud rate, resolution step, zero offset, PDO mapping and transmission type are all electronic parameters, and there are two possibilities: written only to run-time memory, or already written to non-volatile storage. On CANopen, parameters written by SDO need a store command; user parameters on Profibus and PROFINET are downloaded by the master when the connection is established (so they inherently have "rebuild on power-up" capability); CoE parameters on EtherCAT depend on how they were configured.

This table reveals a difference that is often overlooked: Profibus / PROFINET / EtherCAT have the master re-download parameters each time a connection is made, so "lost parameters" are inherently rarer; CANopen depends on the device storing them itself, and skipping the store command produces the typical "it was fine during commissioning, and it would not talk the next morning" symptom. For CANopen configuration see CANopen Node Address and Baud Rate Configuration in Practice; for the division of labour of the parameter channel see CANopen Basics: The Object Dictionary and the PDO/SDO Division of Labour.

Power-up order: why the master coming up first is more trouble

Power-up timing is often underestimated on site. A typical problem is the master starting faster than the slaves: during the scan the master does not find sensors still in self-test, declares a station fault and enters an alarm state; even if the sensor then comes up normally, a manual reset or a wait for retry is needed.

There are three remedies: give the master's initial scan enough wait time or retry count; treat "station faults in the start-up phase" more leniently in the control program; where conditions allow, power the sensors before the master. Conversely, if a slave loses power while the master is still running, the protocols behave differently — CANopen judges a dropped station by heartbeat timeout, PROFINET/EtherCAT report a link interrupt at once, and Profibus reports a station fault after polling with no reply. The control program must handle these states explicitly and must not assume that the position value it reads is always valid, otherwise it will read a stale value cached in the master.

Synchronous refresh: aligning the instant, not raising the speed

The synchronisation mechanisms of the protocols have the same role: make several slaves sample at the same instant, avoiding a time offset caused by the order in which telegrams arrive. CANopen uses a SYNC telegram to trigger TPDOs to be sent together; EtherCAT uses distributed clocks (DC) to align each station's local clock; PROFINET uses the reserved time slots of IRT to achieve isochronous communication.

All three are constrained by the same physical lower bound: a magnetostrictive measurement must wait for the torsional wave to travel from the magnet back to the electronics head, and the longer the measuring range the longer it takes (of the order of 0.5 ms on shorter ranges, and several milliseconds on very long ranges). Therefore:

• The synchronisation cycle must not be shorter than the sensor update rate, otherwise repeated values will be read and the controller's derivative term will compute a false velocity step;
• Synchronised axes should as far as possible use the same measuring range; the difference in measurement time from unequal measuring ranges cannot be recovered by SYNC / DC / IRT;
• If the mechanics force unequal measuring ranges, delay compensation by each axis's update rate is needed on the control side.

For the complete method of matching the cycle see Matching Response Time and Refresh Rate to the Control Cycle; for the DC synchronisation mechanism and sources of jitter see EtherCAT Real-Time Performance Uncovered. Where synchronisation demand is high, prefer the 197 EtherCAT series; under a CAN master system use the SYNC-triggered 194 CANopen series. For general fieldbus connection practice see A Practical CANopen and EtherCAT Guide.