Back to top
CANopen 'Target Reached' is slow to clear after target is changed
I'm using an AKD-P01206-NBCC drive via CANopen.
In profile position mode, I'm commanding the drive to various positions, and then
watching the "Target Reached" bit of the status word to see when the drive gets there.
A problem occurs when the drive is at the last targeted position (Target Reached=1), and
I command it to a new position. After writing the command word to 0x003F to tell the drive to
accept the new target _immediately_, my code expects that any status word read it makes
after the command will contain status that references the _new_ target. However, the drive
is slow to clear "Target Reached" after command 0x003F, and my code can see the stale
"Target Reached=1" status, and assume the drive is now at the new position (which it isn't).
This seems like a drive bug to me, but maybe there's something I need to do differently.
Any insight is appreciated.
Submitted by Todd Squires Mon, 11/02/2020 - 12:37
I don't have precise timing for you, but this might help.
The drive will turn off the Target Reached bit when the drive starts the Motion Task. But this may take a millisecond of so.
Here's the sequence:
Master commands start move with controlword bit 4.
Drive receives the start move command and acknowledges with statusword bit 12.
The next PDO containing the statusword indicates that the Setpoint Acknowledge bit (bit 12) is on.
Drive starts the Motion Task.
Drive turns off the Target Reached bit. (This may be a millisecond after the Motion Task is started in the drive.)
The next PDO containing the statusword indicates that the Target Reached bit is off.
So timing of the PDO is significant. If you configure the PDO to be event triggered (send on value change), make sure to configure the delay time to zero (object 180xh subindex 3). If you use the SYNC telegram to trigger the PDO, then it is based on the timing of the SYNC telegram being sent to the drive.
Using the parameter MT.TPOSMINTIME will not force the Target Reached bit to turn off any faster. But it will force it to turn off before it can turn on again. So the solution may be to use this parameter and program the PLC to look for a low to high transition after the move is started. Set it to something like 5ms. That will give the drive and CAN bus time to send the statusword with bit 10 low, and it is not likely that any move will complete and settle in less than 5ms.
Submitted by jcoleman02 Wed, 11/11/2020 - 07:15