tecnico

Hi all, was wondering about the "best" way to supply a PowerBrick LV. Required voltage 60V, the model has 4 * 5/15Amp amplifiers. (but 3 channels with max 3Arms each will be used) Switching power supplies are cheap, lightweight and regulated but don't like regenerating current. "Passive" supplies (Transformer+Rectifier and caps) can take current back but are not regulated. Transformers might be bulky. 3-phase have lower ripple. How much does the ripple affect the performance when you want the maximun precision? Programmable laboratory labs are regulated, precise, low noise, some can even take some current back but are very expensive and normally are not made to be fitted inside a cabinet. Is the extra performance worth the extra expense? Any guideline on actual choice? Or even some brand/model suggestion?

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.

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

After some help from european technical support the problem was identified (there were some kinematic variables definitions using reserved names) and fixed.

Hi all, I have a problem with the tune tool. As soon as I open it I get no values in the gains and an error in the error window saying "Exception Input string was not in a correct format." I tried changing different things and also disabling all the motors but it looks like the tool is asking for some non-motor related parameters that give a imporperly formatted reply. If I make $$$*** I see gains again Tried some compare with other projects but no luck in understanding. What could be wrong?

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

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

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]

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.

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. EthercatConfig23.zip

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.

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.

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

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.

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 //------------------------------------------------------------------------------ // // 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. // //------------------------------------------------------------------------------ #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

Today I was able to implement the modification. Curt, you were right on the mark, the values I found are very close to the ones you suggested. One thing is still unclear: to plot a "corrected" Lissajous figure do I need to manually combine the Adc and the offset? In the pictures the position ramp response before and after offset trimming. Maybe not perfect but much better!

Thanks for all the useful replies. The oscillating frequency - too precise not to be deterministic- was determined using a position ramp signal, so constant velocity. In this condition FFT shows a sharp peak both for FE and velocity. Since inserting other hardware or messing with the current loop is not an option for the moment (btw in a previous unrelated check the current loop response was looking alright) I think I will try inserting a compensating offset first. Do you think this offset is an "electric" offset or also a mechanical misalignment could be its cause?

Attached the requested plots. I stretched the images to have the same horizontal and vertical resolution Both seem circular but not really centered around zero. Do you think this can cause the previous issue? If so, how can I solve it? Maybe a ADC offset?

Hi all, a customer called complaining about a X-Y cartesian plane with linear motors. They added some mass after the initial tuning and now they hear a vibration. So far I could only do remote tests, and while following error remains very small its plot shows a high frequency pitch. I also took some plots showing velocity and I see the same phenomenon. What is really strange is that the "oscillation" (o whatever it is) is exactly at a frequency that is proportional to the movement speed. Looking better at the system specs: 20kHz Phase, 10kHz servo. Commutated motor. XY use linear motors with 30mm magnetic pitch and sinusoidal encoder (MicroEpsilon Veratus) ,1Vpp and 20um pitch. Doing some basic math I found that the frequency (the shape is roughly sinusoidal) is the exact ratio between the speed and the encoder pitch. a. Vel = 4mm/sec oscillation = 200Hz b. Vel= 6mm/sec oscillation = 300Hz c. Vel= 8mm/sec oscillation = 400Hz Do you have an idea on what can cause this phenomenon?

Then Modbus TCP is the way

Ok, done it. But I think that sharing this info on the forum wold be the best way to help people handling the Gate3 bugs. A even better way would be to fix them as soon as possible...

Richard, I couldn't find any application note regarding this issue. Could you please point me to the right one?

Hi Eric, the pointer has this address: M10271->Acc72EX[0].Udata16[3261] And this is the screenshot

Hi, none of the suggestions is working. Any other ideas?

Sycon doesn't talk to ACC72Ex but only to the module mounted on the ACC72Ex (Hilscher COM-C or COM-X) vua the micro usb port in the front panel of the ACC72EX. On the PMAC side there is a example PLC in the manual that enables data communication between the module and the host system (PMAC)