Remedied from?
ESP-SPAC-CAM1 — Software Package Cam V1.5 (cam template)
Behaviour of the new version?
Due to the additional reset mode of the main integrator in the
L_CamControl function block the cam profile position
g_dnCamPositionSet_p can now be set in a defined way to 0 This is required whenever the cam profile position
g_dnCamPositionSet_p does not directly correspond to the current x-value
g_dnVertShaftPosAct_p = 0 (e.g. non-synchronised y-stretching). As a result, the assignment between x- and y-values in the currently selected cam profile function can be re-established.
Which products are affected?
ESP-SPAC-CAM1 – Software Package Cam 1.4 (cam template)
What happens?
The cam profile position
g_dnCamPositionSet_p indicates a value which does not correspond to the current x-value
g_dnVertShaftPosAct_p. The assignment between x- and y-value in the currently selected cam profile function gets lost.
When does the problem occur?
The behaviour occurs if the following conditions are complied with at the same time:
- the x-axis makes a position jump to or exceeding the zero crossing (x = 0) (also resetting the x-axis to 0) and
- the synchronised y-stretching/compression is selected (g_bYSyncEnable = TRUE) and
- compared to the last valid y-stretching/compression factor in the current clock pulse the y-stretching/compression factor has been changed
The position loss occurs because the x-axis can directly jump to x = 0 since the x-value is selected as position value (template variable
g_dnVertShaftPosAct_p). However, since on the y-side a phase difference value is indicated (function block output
L_CamData.nNOut_v) this value may not be able to jump to the y-position assigned to the x-position within one task cycle but it may only be adjusted in steps of +/-16384 [Inc/ms]. This stepwise adjustment requires several task cycles in case of large position jumps on the y-side.
However, in case of a synchronised y-stretching/compression the new y-stretching/compression factor has already been adapted with the x-zero crossing although the y-position jump has not yet been processed completely. Thus the y-position to be compensated will already be evaluated by the new y-stretching/compression factor.
Possible diagnostics?
The drive is not on the correct y-position after the x-axis has been reset and the y-stretching/compression factor has been changed at the same time while the synchronised y-stretching/compression was active. During the active position compensation the cam data status
g_nCamDataState (signal source:
L_CamData.nState) will show a value not equal zero.
Short-term measures/recommendations?
While the synchronised y-stretching/compression is active, the x-value must not be changed suddenly when changing the y-stretching/compression factor.
Evaluation:
The behaviour only occurs if the x-value has been adjusted suddenly when simultaneously changing the y-stretching/compression factor while the synchronised stretching/compression factor is active.
