03-12-2019, 04:34 AM (This post was last modified: 03-12-2019, 04:45 AM by 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
03-12-2019, 04:38 AM (This post was last modified: 03-12-2019, 04:40 AM by 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.
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.
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
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.
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.
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.
03-18-2019, 11:21 AM (This post was last modified: 03-18-2019, 11:23 AM by 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.
03-19-2019, 07:30 AM (This post was last modified: 03-19-2019, 07:35 AM by 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.
(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"?
03-19-2019, 11:55 PM (This post was last modified: 03-19-2019, 11:57 PM by 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]
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?
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
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.
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.
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.