Problems with CK3E and Kollmorgen AKD

[tecnico]

Hi all, I am experiencing some weird problems trying to use Kollmorgen AKD drives with CK3E (Acontis Ethercat stack)

When I download the PDOs the generated .pmh files have multiple duplicates of the same #defines and, worst of all, I am not able to move the motor.
I mean, I can activate the ethercat network, can even enable the motor (I can see that the drive is being enabled) but any movement results in a corresponding following error. The motor is "still", if I externally apply torque it does not move - like it's being controlled to do so

This is the auto-generated definition file

//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by PowerPMAC IDE.
// Date: 12/03/2019, Time: 12:22
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[0].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[1].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4096].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4097].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4098].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4099].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4100].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4101].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4102].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4103].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4104].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4105].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4106].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4107].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4108].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4109].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4110].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4111].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4112].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4113].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4114].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4115].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4116].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4117].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4118].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4119].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4120].Data

[tecnico]

I have tried changing many things, including ESI files and IDE version (3 or 4 does not make any difference)
The only different behaviour was obtained using a ESI file from DT Europe. In this case the standard mapping was CST, got no duplicates and with some work I was able to move the motor. Selecting a different PDO set causes the behaviour of all the others (duplicates and no movement).
I also tried defining a "custom" PDO mapping, but in this case the network does not get enabled at all.

In the past I've been using AKDs with Etherlab master with no problems.

[Tony]

Your addressing looks wrong. Position Actual should be in 6064 and Target Position (assuming you are using CSP mode) should be 607A. Do you see those addresses in the list?

I seem to remember having to set some scaling parameters in the AKD drives to get them working correctly.

[tecnico]

Kollmorgen looks a bit different on this side

I think they use the same "setpoint" address for all the modes and switch it internally.
In some ESI files some mappings are dedicated to a single operating mode so you can find the PDOs you cited

Here is a working mapping I'm using with Etherlab

#define Slave_23_6063_0_PositionActualIn ECAT[0].IO[474].Data
#define Slave_23_2050_0_SecondPositionFe ECAT[0].IO[475].Data
#define Slave_23_606C_0_Velocityactualval ECAT[0].IO[476].Data
#define Slave_23_60FD_0_DigitalInputs ECAT[0].IO[477].Data
#define Slave_23_60F4_0_FollowingErrorAc ECAT[0].IO[478].Data
#define Slave_23_20A0_0_Latch1P ECAT[0].IO[479].Data
#define Slave_23_6041_0_Statusword ECAT[0].IO[480].Data
#define Slave_23_6077_0_TorqueActualValu ECAT[0].IO[481].Data
#define Slave_23_20A5_0_LatchStatus ECAT[0].IO[482].Data
#define Slave_23_3470_4_AINVALUE ECAT[0].IO[483].Data
#define Slave_23_6040_0_Controlword ECAT[0].IO[484].Data
#define Slave_23_60C1_1_1stsetpoint ECAT[0].IO[485].Data
#define Slave_23_20A4_0_LatchControlword ECAT[0].IO[486].Data
#define Slave_23_60B2_0_TorqueFeedForwar ECAT[0].IO[487].Data
#define Slave_23_60FE_1_DigitalOutputs ECAT[0].IO[488].Data
#define Slave_23_6072_0_MaxTorque ECAT[0].IO[489].Data

[Tony]

The attached image is a screenshot of EC-Engineer for an AKD-N drive. As you can see, it has the standard addresses. I don't have a drive here to test it any further.

Which Kollmorgen drives do you have?

[tecnico]

Hi,
drive is AKD-P02407-NBCC-I00

With ESI from Brad (AKD-P-17-00-000.xml) the standard mapping is in torque mode.
With this mapping (but only this one) I don't have any duplicates and I can get the motor to move.

However I want CSP.

[tecnico]

With the ESI file downloaded form Kollmorgen website I get this standard mappings:

AKD Servo Drive Firmware and EtherCAT Device Description and CANopen EDS (AKD-P-NBCC-01-17-00-000)-->AKD EtherCAT Device Description.xml

Using the default mapping I can enable the ethercat network and the drive but I am not able to move it.
Evey movement results in a following error. I can see the setpoint word changing but the actual target does not change in the drive.

Apparent resolution, as you noted, is different from CST mode (much higher in CST). Don't know what this means but might be worth mentioning.

[tecnico]

In a effort to document my struggles I mapped, with the same ESI file, this configuration.

As sometimes already happened before now I am able to move the motor in CST mode. Still have plenty of duplicates, which is really odd.

I saved the ESI file for safety.

So technically I *should* have a working configuration.
I Issue a "save" and then $$$ and all is gone.

I am really puzzled.

[Eric Hotchkiss]

Typically when a PDO name shows up repeatedly within the ecat map, that indicates the ESI file had non-unique PDO names. In some cases I've seen ignoring the problem lead to strange behavior, like torque mode motors not being able to end open loop commands.

The fix for this is to add enough to the names of the PDOs you use to make them unique. I am attaching pages from a PDF explaining how to set up a specific elmo drive. Take a look at page 4 where step 6 begins. This shows exactly how to add a "1" to every PDO name in the mappings you are using, after clicking "Edit" on the correct PDO mapping.

[tecnico]

HI,
changing the PDO names prevents the PDO entry from being repeated.
It is a bit uncomfortable to do - especially if I have to do it for multiple drives - but works.

After a call with Kollmorgen's technicians it looks like the real problem of not being able to move the motor is that the "default" operation mode for the drive is not CSP.
To get it to work you have to manually set the operation mode writing in the $6060 SDO or modifying the startup sequence as shown in the picture (by default I had "7" here).
With Etherlab I never had to do this, so I needed someone to tell me.


So far so good, but I still have one problem: with Etherlab I could disable and re-enable Ethercat almost at will, but now if I disable Ethercat I can't re-enable it unless I make a reboot. Is this an expected behaviour?

ECAT[0].MasterState stays at 2 but most of the times the Ethercat does not re-enable.

[Eric Hotchkiss]

(03-19-2019, 07:30 AM)tecnico Wrote: HI,
changing the PDO names prevents the PDO entry from being repeated.
It is a bit uncomfortable to do - especially if I have to do it for multiple drives - but works.

If you have more than a couple identical slaves, it is possible to delete slave 2 and then copy slave 1 to slave 2.

(03-19-2019, 07:30 AM)tecnico Wrote: After a call with Kollmorgen's technicians it looks like the real problem of not being able to move the motor is that the "default" operation mode for the drive is not CSP.
To get it to work you have to manually set the operation mode writing in the $6060 SDO or modifying the startup sequence as shown in the picture (by default I had "7" here).
With Etherlab I never had to do this, so I needed someone to tell me.

This was specified with names of move modes instead of values of $6060 in etherlab. The defaults could be different between modes.

(03-19-2019, 07:30 AM)tecnico Wrote: So far so good, but I still have one problem: with Etherlab I could disable and re-enable Ethercat almost at will, but now if I disable Ethercat I can't re-enable it unless I make a reboot. Is this an expected behaviour?

ECAT[0].MasterState stays at 2 but most of the times the Ethercat does not re-enable.

This is not expected behavior. How are you checking if EtherCAT re-enables? If you are checking ECAT[0].MasterState, then you may need to have ECAT[0].RTStateCheck=1, depending on firmware version. When it fails to change, what is the response to "ecat slaves"?

[tecnico]

Hi,
I look at MasterState (8 when ECAT is enabled, 2 when not) and at the update of motor position.
ECAT[0].Enable does not go to 1 when it refuses to enable
I have CK3E Fw. 2.3.2.5

This is what I get form terminal
SSH communication to PowerPMAC at 192.168.0.200 successful
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_001 *first boot*
ecat[0].enable = 1
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 OP + Slave_1001 [AKD] *ecat enabled (Masterstate = 2)*
ecat[0].enable = 0
ecat[0].enable = 1 *this time 1st time re-enable worked*
ecat[0].enable = 0
ecat[0].enable = 1 *not working this time*
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_1001 [AKD]
ECAT[0].RTStateCheck
ECAT[0].RTStateCheck=0
ECAT[0].RTStateCheck=1 *tried suggestion*
ecat[0].enable = 1
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_1001 [AKD]

[AAnikstein]

(03-19-2019, 11:55 PM)tecnico Wrote: 0 VID=$0000006A PC=$00414B44 0:0 OP + Slave_1001 [AKD] *ecat enabled (Masterstate = 2)*

Can you confirm--does Masterstate ever go to 8 at this point if you let the system sit long enough? I've seen it go to 2 at first, but then goes to 8, which is the correct status when the system is in OP mode.


Additionally, can you try to issue an "ecat reset" after it gets in the state where it doesn't work to see if that changes anything?

[tecnico]

I found the problem to be related to the DC Sync mode.

Previously I was in Bus Shift mode; moving to Master Shift mode seems to solve the problem

[Eric Hotchkiss]

This makes sense. Some ethercat slaves do no support bus shift.

[tecnico]

Any idea about when the "duplicates" issue will be fixed ?

[tecnico]

Still getting the duplicates issue but with different servo

This time Mitsubishi MRJ4-TM-ECT.

The inputs are duplicated (only one time but still annoying)

#define Slave_4_6061_0_Modesofoperationd ECAT[0].IO[4122].Data
#define Slave_4_6041_0_Statusword ECAT[0].IO[4123].Data
#define Slave_4_2D11_0_StatusDO1 ECAT[0].IO[4124].Data
#define Slave_4_2D12_0_StatusDO2 ECAT[0].IO[4125].Data
#define Slave_4_2D13_0_StatusDO3 ECAT[0].IO[4126].Data
#define Slave_4_6064_0_Positionactualval ECAT[0].IO[4127].Data
#define Slave_4_606C_0_Velocityactualval ECAT[0].IO[4128].Data
#define Slave_4_60F4_0_Followingerroract ECAT[0].IO[4129].Data
#define Slave_4_6077_0_Torqueactualvalue ECAT[0].IO[4130].Data
#define Slave_4_60B9_0_Touchprobestatus ECAT[0].IO[4131].Data
#define Slave_4_60BA_0_Touchprobepos1pos ECAT[0].IO[4132].Data
#define Slave_4_60BB_0_Touchprobepos1neg ECAT[0].IO[4133].Data
#define Slave_4_60BC_0_Touchprobepos2pos ECAT[0].IO[4134].Data
#define Slave_4_60BD_0_Touchprobepos2neg ECAT[0].IO[4135].Data

#define Slave_4_6061_0_Modesofoperationd ECAT[0].IO[4136].Data
#define Slave_4_6041_0_Statusword ECAT[0].IO[4137].Data
#define Slave_4_2D11_0_StatusDO1 ECAT[0].IO[4138].Data
#define Slave_4_2D12_0_StatusDO2 ECAT[0].IO[4139].Data
#define Slave_4_2D13_0_StatusDO3 ECAT[0].IO[4140].Data
#define Slave_4_6064_0_Positionactualval ECAT[0].IO[4141].Data
#define Slave_4_606C_0_Velocityactualval ECAT[0].IO[4142].Data
#define Slave_4_60F4_0_Followingerroract ECAT[0].IO[4143].Data
#define Slave_4_6077_0_Torqueactualvalue ECAT[0].IO[4144].Data
#define Slave_4_60B9_0_Touchprobestatus ECAT[0].IO[4145].Data
#define Slave_4_60BA_0_Touchprobepos1pos ECAT[0].IO[4146].Data
#define Slave_4_60BB_0_Touchprobepos1neg ECAT[0].IO[4147].Data
#define Slave_4_60BC_0_Touchprobepos2pos ECAT[0].IO[4148].Data
#define Slave_4_60BD_0_Touchprobepos2neg ECAT[0].IO[4149].Data

I thought it was a Kollmorgen-related problem but now it looks more likely to be a problem of the Acontis master.
Any chance that using a newer firmware (actual is 2.4.1.2) can help in this regard?

I can add more details: the proposed input mappings are 0x1A00 and 0x1A01
The duplicated names are the PDOs that exist in both the mappings
Editing the XML changing just the name prevents the PDOs from being duplicated.

of course it's not normal to have to edit a OEM XML descriptor, because each time the manufacturer releases a new version you have to redo the work.

I can provide original and edited xml on request. Can't seem to be able to attach xml or zipped xml

[steve.milici]

(06-06-2019, 05:10 AM)tecnico Wrote: Still getting the duplicates issue but with different servo

This time Mitsubishi MRJ4-TM-ECT.

The inputs are duplicated (only one time but still annoying)

#define Slave_4_6061_0_Modesofoperationd ECAT[0].IO[4122].Data
#define Slave_4_6041_0_Statusword ECAT[0].IO[4123].Data
#define Slave_4_2D11_0_StatusDO1 ECAT[0].IO[4124].Data
#define Slave_4_2D12_0_StatusDO2 ECAT[0].IO[4125].Data
#define Slave_4_2D13_0_StatusDO3 ECAT[0].IO[4126].Data
#define Slave_4_6064_0_Positionactualval ECAT[0].IO[4127].Data
#define Slave_4_606C_0_Velocityactualval ECAT[0].IO[4128].Data
#define Slave_4_60F4_0_Followingerroract ECAT[0].IO[4129].Data
#define Slave_4_6077_0_Torqueactualvalue ECAT[0].IO[4130].Data
#define Slave_4_60B9_0_Touchprobestatus ECAT[0].IO[4131].Data
#define Slave_4_60BA_0_Touchprobepos1pos ECAT[0].IO[4132].Data
#define Slave_4_60BB_0_Touchprobepos1neg ECAT[0].IO[4133].Data
#define Slave_4_60BC_0_Touchprobepos2pos ECAT[0].IO[4134].Data
#define Slave_4_60BD_0_Touchprobepos2neg ECAT[0].IO[4135].Data

#define Slave_4_6061_0_Modesofoperationd ECAT[0].IO[4136].Data
#define Slave_4_6041_0_Statusword ECAT[0].IO[4137].Data
#define Slave_4_2D11_0_StatusDO1 ECAT[0].IO[4138].Data
#define Slave_4_2D12_0_StatusDO2 ECAT[0].IO[4139].Data
#define Slave_4_2D13_0_StatusDO3 ECAT[0].IO[4140].Data
#define Slave_4_6064_0_Positionactualval ECAT[0].IO[4141].Data
#define Slave_4_606C_0_Velocityactualval ECAT[0].IO[4142].Data
#define Slave_4_60F4_0_Followingerroract ECAT[0].IO[4143].Data
#define Slave_4_6077_0_Torqueactualvalue ECAT[0].IO[4144].Data
#define Slave_4_60B9_0_Touchprobestatus ECAT[0].IO[4145].Data
#define Slave_4_60BA_0_Touchprobepos1pos ECAT[0].IO[4146].Data
#define Slave_4_60BB_0_Touchprobepos1neg ECAT[0].IO[4147].Data
#define Slave_4_60BC_0_Touchprobepos2pos ECAT[0].IO[4148].Data
#define Slave_4_60BD_0_Touchprobepos2neg ECAT[0].IO[4149].Data

I thought it was a Kollmorgen-related problem but now it looks more likely to be a problem of the Acontis master.
Any chance that using a newer firmware (actual is 2.4.1.2) can help in this regard?

I can add more details: the proposed input mappings are 0x1A00 and 0x1A01
The duplicated names are the PDOs that exist in both the mappings
Editing the XML changing just the name prevents the PDOs from being duplicated.

of course it's not normal to have to edit a OEM XML descriptor, because each time the manufacturer releases a new version you have to redo the work.

I can provide original and edited xml on request. Can't seem to be able to attach xml or zipped xml

This is a result of the PDO naming in the manufacturers ESI file. I have attached an application note describing how to correct this.

[tecnico]

I understand and appreciate the suggestion, however I don't find it normal to have to fix these things manually.
I find it very strange that both Kollmorgen AND Mitsubishi (and probably many others I am not aware of) are doing the same mistake.

I tend to think that the ESI parsing method has something that needs a fix, that's why I asked if this issue was going to be addressed anytime soon.
If not it is going to make life difficult to people using the Acontis stack - and since it looks like that the 46x products with Etherlab are going to be phased out sooner than later- this is going to affect more and more PMAC users.

[DaveBarnett]

I must whole-heartedly agree with tecnico on this matter. I have struggled with the same problem...yet with another mfg's drives. This needs to be fixed.

[Eric Hotchkiss]

Good news. This will be fixed in the next IDE release. I already tried it.

For clarity, this should be fixed in IDE 4.3.x.x