Ethercat HAL driver

Hello, I think I just made some progress,

actualy my xml had this:
<syncManager idx="2" dir="out">
<pdo idx="1600">
<!--<pdoEntry idx="6040" subIdx="0" bitLen="16" halPin="control-word" halType="u32"/>-->
<pdoEntry idx="6040" subIdx="0" bitLen="16" halType="complex">
<complexEntry bitLen="1" halPin="X-cmd-SwitchOn" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-EnableVoltage" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-/QuickStop" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-EnableOperation" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OPmodeRel1" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OPmodeRel2" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OpmodeRel3" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-FaultReset" halType="bit"/>
<complexEntry bitLen="1" halPin="XcTimeOut" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OpmodeRel4" halType="bit"/>
<complexEntry bitLen="6"/>
</pdoEntry>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="bit"/>
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscmd" halType="float" scale="1"/>
</pdo>
</syncManager>
so I checked and indeed 0x6061 was always reading 0x08
because that is what is saved in the drive from before I enable and OP the drive.
but in OP 0x6060 is reading 0x00...
because I didn't do anything special in linuxcnc the halconfig related to 0x6060 stayed at 0x00
so what I did is add this to postgui.hal:
setp lcec.0.0.opmode-3 true

which actually writes the 3rd bit in 0x6060 and now when I read registers with
ethercat -p0 upload 0x6060 0
I get 0x08
and same for 0x6061

finally after looking for something logical and mucho tweaking: I changed the scales to 1000 and 0.0001:
<masters>
<master idx="0" appTimePeriod="1000000" refClockSyncCycles="1000">
<!-- ECT60 slave -->
<slave idx="0" type="generic" vid="00000A88" pid="0a880002" configPdos="true">
<!-- <initCmds filename="ECT60.xml"/> -->
<!--<dcConf assignActivate="300" sync0Cycle="10000000" sync0Shift="0"/>-->
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
<!-- <sdoConfig idx="6060" subIdx="0"><sdoDataRaw data="08"/></sdoConfig>-->
<syncManager idx="0" dir="out">
</syncManager>
<syncManager idx="1" dir="in">
</syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<!--<pdoEntry idx="6040" subIdx="0" bitLen="16" halPin="control-word" halType="u32"/>-->
<pdoEntry idx="6040" subIdx="0" bitLen="16" halType="complex">
<complexEntry bitLen="1" halPin="X-cmd-SwitchOn" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-EnableVoltage" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-/QuickStop" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-EnableOperation" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OPmodeRel1" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OPmodeRel2" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OpmodeRel3" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-FaultReset" halType="bit"/>
<complexEntry bitLen="1" halPin="XcTimeOut" halType="bit"/>
<complexEntry bitLen="1" halPin="X-cmd-OpmodeRel4" halType="bit"/>
<complexEntry bitLen="6"/>
</pdoEntry>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="bit"/>
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscmd" halType="float" scale="1000"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<!--<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="status-word" halType="u32"/>-->
<pdoEntry idx="6041" subIdx="0" bitLen="16" halType="complex">
<complexEntry bitLen="1" halPin="X-stat-ReadyToSwitchOn" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-SwitchOn" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-OperationEnable" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-Fault" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-VoltageEnabled" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-QuickStop" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-SwitchOnDisable" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-Warning" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-Keep" halType="bit"/>
<complexEntry bitLen="1" halPin="X-stat-Remote" halType="bit"/>
<complexEntry bitLen="5"/>
</pdoEntry>
<pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode_fb" halType="bit"/>
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actpos" halType="float" scale=".001"/>
<pdoEntry idx="60FD" subIdx="00" bitLen="32" halPin="digital_inputs" halType="bit"/>
</pdo>
</syncManager>
</slave>
</master>
</masters>


AND NOW I CAN JOG!!!!! 1 axis... now I have a whole cnc to build but it seems so easy in comparison !!!

THANK YOU CHIMENO I owe you one...

Hi all,

I know I've overlooked something simple but I cannot get my Delta ASDA-A2E amps to switch the default direction they travel i.e. I send a positive move and the carriage move's towards the negative direction. The machine is a slant bed lathe (back tool) and I have the limits as x min=0.0 x max=250.0mm, z min=0.0 and z max= 521.0mm. Home=+250,521.

I have tried setting P1-01 = 0x010C which should change the default rotation of the motor. I am running in CSP mode but I though this was the parameter for all modes. Any suggestions?

Thanks,
Dan

it might just be simpler to revers the direction within Linuxcnc by making the output scale negative.

Dear All,

Since Friday I am playing with a raspberry 4 with preempt RT controlling a close loop x axis stepper motor through an ECT60 ethercat drive.

I decided to spend some time configuring and adjusting the scale so that the mm scale on screen would match the screw in my gantry which seems like a good idea.
Also I was curious to see what speed I could achieve in displacement (no load or screw yet)
Well it so happens that I found the max speed to be about 3500 mm/minute. Higher than that and the motor would stop complaining about an error on the Joint . I understand that this is due to delta between the cmd position and the actual position returned by the motor.
I do believe this "max" speed to be adequate for my application and I am fairly happy with it, stil I would like to know what position lag this implies and if building the CNC based on this hardware is realistic or if I need to tweek it..
Also I believe it is linuxcnc that raises the alarm before the closed loop in the driver complains (is that desired behaviour at least it doesn't seem that I have to clear the driver error)?
Also what I a don't know yet is if the position lag or error is acceptable and since I believe my loop ethercat loop is 1ms I wanted to know if that was the cause of the whole lag.
So I fired the latency test histogram and plots as well as plotted actual position and cmd position in HAL scope (which I am not sure to fully master yet btw) to see how things fitted together.
the latency seems to be generally under the 1ms and I believe that although I use the "generic" driver it is not a bottle neck...???
But on the halscope,
I observed a 15 ms delay in time for the actual position to reach the cmd position at full speed of about 3000 mm/min = 50mm/s
on the graph the position lag is just under 1 halscope unit... which I suppose is mm

Doing some simple math 1 ms at that speed is a move of 50 um and 15 ms corresponds to 750 um which is about right.

So my question would be ... is that expected normal behavior for a closed loop stepper drive and motor?
Ethercat doesn't seem to be the bottle neck here (1 ms vs 15 ms) and I suppose the lag must thus be from the PID regulator in the driver.
And can linuxcnc successfully work with such a lag?
I suppose that I will never mill at that speed (probably only up to one third of that 1m/min) but that would already represent 250um lag... so is it acceptable?
Sorry if those general considerations are expected knowledge, but I don't know what is the correct strategy to reduce this error.

I believe this is usually solved using feedforward in a PID loop. So I found at least 2 registers in the driver which might be of interest:
Object dictionary Name Property Type Range The default value Note
0x2023:04 PosLoop_Kvff R/W/S UINT 0 to100 30 Speed compensation
and this one

Object dictionary Name Property Type Range The default value Note
0x2009 Filter Time R/W/S UINT 0~25600 6400 us
ECT60 has a built-in moving average filter. This object is used to set the time of moving average
filter. The greater the filtering time, the smoother the start and stop of the motor, but the greater
the response lag of the motor.
Lag time = filter time

There is also 0x2025 "speed filter" with some frequency parameters and also there is servo mode 2 parameter set (Kp,Ki,Kv1,Kv2,Kvf) to play with at 0x2026 to use for vector control algorithm

So what is a good strategy or guide to set up those parameters?

update: so I played a bit with parameter 0x2009 trying to half the time constant and indeed it does reduce the the lag between actpos and poscmd... but at the cost of the drive being "sometimes" unstable when I move the jog back and forth. It makes noises and strange steps .. I can feel it's not "happy"...

photos.app.goo.gl/PoLrSQ2Csg674BmY6

@ Todd,

Thanks! That does solve the issue when LinuxCNC is in control. However, I am also trying to get the internal homing routine of the servos to work, Similar to Roschi's example from way back except with incremental encoders.

My thinking is that if I can change the default rotation of the of the motor during the homing routine then both LinuxCNC and the amplifiers will define positive movements in the same direction.

Having LinuxCNC control the homing routine is also a possible option but I am hoping not to have to use that method.

Kind regards,
Dan

@ theshade,

For a stepper based system I doubt that the ethercat bus is the bottleneck as well. What is your position command acceleration set at?

If you bought the driver and the stepper as a matched set than I would guess that the PID loop of the driver is optimized for that motor. So I would try to set the acceleration value of linuxcnc position command equal to or slightly less than that of the driver's max acceleration value. Once you get everything
assembled these values will probably change slightly. Otherwise start with slow speeds and then "tune" the system so that it follows within the position error. From there you can begin to increase to 3500mm/min...seems pretty fast for a stepper system. What's the PPR of the encoder?

Kind regards,
Dan

Dear Dan,

Thank you for your reply.

I agree with you:
1. ethercat is certainly not the limiting factor as 1 ms delay seems fine
2. yes I bought them matched and the vendor (rtelligent) seems serious and mentioned they did the required tuning (PID etc)
3. yes I have set the acceleration in linuxcnc just below the drivers
4. I understand loading the axis will have some impact.
5. I will probably reduce the target max speed to 1000mm/min or lower once I see the whole thing moving and start being scared !!!

Now after some playing, I also understand there is a moving average filter inside the driver (lowpass filter with selectable time constant). It makes all the movements smoother and does prevent instability at any speed up to 3000 mm/min = (600rpm) the encoder resolution is specified as 1000 / turn (so that's 10kHz) . It also introduces some lag ~20ms.

I tried to change the filter time constant from its default (lower it) but it results in instabilities at intermediate to high speeds (and some times at low speeds too)

Essentially I don't know what to think about this lag between the cmd-pos and the actpos ( I wouldn't care for 1 axis) but for 3D trajectories I'd rather not have a velocity dependent 1mm lag.

I am reading more and more in the forums here and on the HAL pid comand doc and I am still not sure if i am supposed to do:
1. linuxcnc (when it is not in a per step controlling role) should "just" send position commands in "open" loop to the closed loop stepper and leave it at that and let the error be as it is? (just relying on the driver to rise an alarm in case of a problem)
2. or if there would be some benefits in closing + tuning a second loop around the stepper closed loop (with some FF1?? to compensate for that speed dependent lag error). Would that be helpful in syncing multiple axis movements?

What do people usually do? and what is considered acceptable lag error for a CNC? (lets pretend I want ~1/10 of a mm resolution on my parts) or is that not even a real problem because the trajectory computer only issues straight in-sync segments?

Thanks,
Shady

Hi,

Just some info about ethercat speeds.

Attached some old config files of a 3 axis plasma cnc. While using this config some time ago i spotted a time bug in the X2 motor.
I solved this bug by increasing a time parameter somewhere, but not in this attachement. Just for info. I see i have no backup of the latest config.

The machine run's 18000mm/sec for users. Top speed is around 20m/sec. One step is 0.2mm for the machine displacement. The machine is fitted with standard steppers and drives, powered at 80v, tuned back to around 2-3 amps to reduce noise. And is fitted with a 2x 4channel 1ms 5v beckhoff pulse output.

Don't order the orginal beckhoff stepper drives. I tested the 2 versions. It's crap. Only usable for 3d printing. Very light jobs.

@Grotius,

Hello Grotius, when you stated:

"Don't order the original beckhoff stepper drives. I tested the 2 versions. It's crap. Only usable for 3d printing. Very light jobs".

Are you referring to the EL7041 and 7031? Just curious as I have a few of the 7041's that I hae not tried yet.

Thanks,
Robert

Hello, everyone . I bought EtherCAT servo drivers brand Adatech model QXEH10NE



Manual : drive.google.com/file/d/14cinYiQ4-0qYuw5...Znf/view?usp=sharing

Does anyone have experience with these drivers and LinuxCNC?