Back to top

CANopen 'Target Reached' is slow to clear after target is changed

0 votes
+ vote
Vote up!

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.

 

Comments

Todd,
I will be handling your request in Case 1761665.

jcoleman02 - Mon, 11/02/2020 - 15:00
Log in or register to post comments

1 Answer

0 votes
+ vote
Vote up!

Todd,

 

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.

 

Comments

Hi Jim,

Thanks for the detailed reply. That's enough information for me to get my application working reliably with the AKD.

Recapping what we discussed previously in email for future folks coming to this forum with the same issue:

It would be better if the drive updated the Target Reached status _immediately_ when commanded immediately to a new set point.

The CANopen 402 V 2.0 spec says:

"If the bit ‘change set immediately’ is "1" (dashed line in Figure 17) the new target position will be active immediately... The drive readapts the actual move to the new target position immediately."

That spec doesn't go into detail about what's happening with the 'Target Reached' bit of the status word when changing the target position immediately, but many readers (myself included) would assume this means the status word also updates immediately.

Given that interpretation, if an event PDO was set on the status word, the PDO would presumably arrive even before the reply to the write of the control word which changes the set-point (since PDOs have higher CAN priorities than write reply messages). If that did indeed happen, it would transparently avoid the edge cases where the user's application code would have stale drive status just after commanding the drive to a new target, since by the time the function call which sets the new target returns, the PDO would already have been received, and the application's local copy of the status would already have been updated.

If the drive worked this way, it would make coding for this fairly common situation much simpler and less error prone. In specific, there would be no need to utilize MT.TPOSMINTIME, and there would be no need to write code which tests for the Target Reached status to go inactive and then active again to know the new move had completed.

I'm not sure if other drives have this issue (given the lack of clarity in the spec, it wouldn't surprise me), but if the Kollmorgen drives could be updated to handle this, it would likely mean fewer headaches for future customers.

I know you guys are looking into the feasibility of an update, and hope you're able to make it happen.

Todd Squires - Wed, 11/11/2020 - 08:36

BTW: What do I need to do to make this forum obey my formatting??? It seems to have a mind of its own about what to do with carriage returns. In my first post, it took each return as a paragraph break. In my last post, I formatted accordingly, but then it decided to just eliminate all the carriage returns. Ugh!

Todd Squires - Wed, 11/11/2020 - 08:43
Log in or register to post comments
ANSWER THIS QUESTION
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.

If you do not have an account, click here to register.