TMC5031 DATASHEET (Rev. 1.11 / 2016-APR-28)
47
by the read and clear (R+C) function, be sure to execute step 5 within the time range set by
TZEROWAIT.
5. Switch the ramp generator to hold mode and calculate the difference between the latched
position and the actual position. For stallGuard based homing or when using hard stop, XACTUAL
stops exactly at the home position, so there is no difference (0).
6. Write the calculated difference into the actual position register. Now, homing is finished. A move
to position 0 will bring back the motor exactly to the switching point. In case stallGuard was
used for homing, a read access to RAMP_STAT clears the stallGuard stop event event_stop_sg and
releases the motor from the stop condition.
9.6 Restrictions of Ramp Generator (Errata)
When the TMC5031 becomes stopped in velocity mode, there is an irregularity of the position counter
failing and counting continuously with clock frequency until the next move is commanded.
Failure condition:
1. Motor is moving in velocity mode
2. Master sets VMAX=0 to stop the motion
3. Upon reaching of VACTUAL=0, the position counter may start counting with clock frequency
(The deterministically probability for this behavior occurring is about 1/16 Million.)
In this situation the motor is correctly in standstill and also the ramp state reports the motor to be
stopped. When starting the motor again, the position counter continues from the new (wrong)
position. This behavior leads to a loss of the synchronization between the position counter and the
motor position.
Background:
The restriction is caused by a failure state, which involves the state of the internal velocity pulse
generator and the actual point of time, when the velocity becomes zero. When the velocity VACTUAL
becomes decreased from one to zero with the 24 bit ramp generator register in a certain state, the
XACTUAL position counter gets to a state where it counts up despite the velocity now being zero. This
can occur in velocity mode only, because in this mode the internal change of the velocity register is
not coupled to an advance in the actual position. The statistical probability for the occurrence of the
failure is given by the combination of 2^24 (i.e. 16M) possible states of the accumulation register, with
one of the states leading to a fail. If the one state of the accumulation register, which leads to an
overflow of the register in case of an accumulation of the last velocity value (1) before reaching zero
occurs at exactly the same moment where the velocity actually goes to zero, the XACTUAL counter
gets caught in an endless loop.
9.6.1 Velocity Mode Workaround
There are two alternatives for a workaround. The first workaround is recommended for most
applications which require the use of velocity mode. Therefore the application software must allow
polling a register on a deterministic, regular time interval. The second workaround has less real time
relevance, as it just requires a read-modify-write instruction to execute within limited time.
First Software Workaround for Applications Using Velocity Mode Intensively
The velocity mode can be used, but in order to stop the motor, do not directly set VMAX=0.
Workaround for stopping the motor:
1. Set VMAX to a low velocity, in the range 1 to 2000 (e.g. 100). Even if VMAX has been lower
before, this ensures a quick termination of the stop procedure. Exit the stop procedure, in
case VMAX already had been set to 0 before (motor is stopped).
2. Check the velocity_reached flag to become active. Alternatively, check if the absolute value of
VACTUAL is at or below the value selected for step 1.
3. Poll XACTUAL until a new step has been executed (i.e. XACTUAL has changed)
(with VMAX=100 this will need at maximum about 10ms, with VMAX=1000, about 1ms) (*)
www.trinamic.com