EtherCAT Axis Feedback Resolution Configuration Questions

Hey Guys,
I am trying to get a new machine up and running, its the first high resolution system I've tried to setup with LinuxCNC.
It's an XXYZ gantry configuration, but the gantry is being handled by hardware, so the CNC just sees XYZ.


Drives:
Kollmorgen AKD2G (X and X' gantry)
Kollmorgen AKD (Y Axis)
Kollmorgen AKD (Z Axis)

Motors:
Kollmorgen ICD05030 Linear Coil (all axes)

Feedbacks:
Renishaw LM10 1VPP Magnetic

I have played with EtherCAT with LinuxCNC a bit and have a lot of experience in industrial applications but this is the first time I'm trying to maximize performance out of LinuxCNC with EtherCAT.

The build is using linear motors, 32mm motor pitch, a relatively coarse 2mm pitch magnetic sin/cos feedback. (so 16 counts / motor cycle = 4 bits) - but its connected to a servo drive with 24bits of sin/cos interpolation - so including the noise floor, i have 28 bits of resolution per electrical cycle (~268e6 counts/motor pitch).

I have had a hard time "realizing" this resolution at the controller level going over the fieldbus, and I feel like I'm doing the resolution conversion between the trajectory planner and the ethercat layer in a silly way.

I am defining Scaling and Inverse scaling params (see INI file, PSCALE and PSCALE_INV), then using those in the HAL layer to setup scaling objects from floating point to U32 so i can link them up to the PDOs going to my servo drives.

It all works right now, however ive found that as soon as i overflow the floating point conversion number, the position feedback overflows and i get a position error fault.

Is there a better way to handle this?
I have left a few alternative configurations in my ethercat config file, at 10,000 counts, 100,000 counts and 1,000,000 counts per electrical cycle. and I just change the INI scaling values mentioned above according to what i set the fieldbus scaling at.

I'm interested to hear how others have handled this kind of configuration.

Best Regards,
Paul

Hello,

there is an an type conflict in your ethercat-config.

PDO 6062 Feedback is an S32 (signed integer), in your config you have setup it as float.

With an quick look i think, you will have to insert an scale / encoder handling between your feedback value and joint.x.motor-pos-fb.

Take a look at the implementation of the feedback/encoder handling from AX Servo Drives. (ethercat/src).

regards

Thanks for looking at my config!

After re-visiting the ethercat PDO config, I remember why I did that - I agree, I shouldn't be doing this, but follow my logic and I'm hoping you can explain what I'm doing wrong.

So if i configure the Position Feedback as an S32 or U32 as I would normally, if i connect it to the joint.#.motor-pos-fb, then each count from the U32 on the PDO is equal to 1.0 mm - which would severely limit the resolution of my machine.

So when I saw this behavior, I started screwing around with the configuration and found the HAL scale object and noticed that the input had to be a float - so i either needed to convert the U32 PDO (Axis1RxPositionFeedback in my ethercat config) to a float using the HAL object "conv_u32_float" - OR - I could just create the PDO as a float directly - and that happened to work, so i chose that. Either way, i was going to need an object to convert from the PDO value to a float so i could connect it to the HAL "scale" object.

I continued down this path of taking my position feedback PDO and scaling it before connecting it to the joint.#.motor-pos-fb using the "scale" object because i couldnt find any other ways of scaling the value.

This is the root of my question (especially after running into the 32bit rollover condition with the float variable) - I feel like I'm missing some fundamental concept around the ethercat position scaling.

Best Regards,
Paul

Hi,

the normal concept would be to implement an ethercat driver for your servo drive, instead of the generic driver. In this ethercat driver is some logic implemented, like the can state machine or encoder handling. the interface from the driver will be "linuxcnc standard" Enable, Error Pin, Encoder Handling, Scaling for drive and encoder homing, Enc zero enable etc. ...

The Problem at the moment is that your encoder PDO are raw increments an you need some Counter and Scaling code.

quick look at src, the omron g5 driver is very near to that what you need...

How are your programming, linux, github skills ?

I can help, but have not enough time at the moment for doing the whole thing alone.
i think my rusted english writing is the biggest problem....

Another Solution would be to write an 4 line comp to only do the scaling with S32 Input and float output. But this would be proof of concept like the whole thing with the generic driver....

Ahh, ok, so for other drives the scaling is happening in the lcec driver.

Ok, let me review the Omron G5 driver and see if I can hack something together. Regardless it gives me a starting point. Thank you!
I'm very green to the linux environment. Using LinuxCNC has really been my first foray - so it has felt a bit like jumping in the deep end without knowing how to swim, but I'm slogging through it. I have enjoyed the flexibility of LinuxCNC so far.

I'll check back in when i get stuck

If you know of any guides to create a new servo driver that would help. I had looked into it a while back before I figured out how to use the generic driver, but didn't get very far.

Best Regards,
Paul

Hi to all.
I may be able to help or is this already solved ?

best regards

Hi udoS,
thanks for the offer, I think this confusion stemmed from me not understanding that most (if not all) fieldbusses are operating on a 32bit position range. So while the drive was internally 64bit, I am not able to fully expose that range. even on the product I am using, the fieldbus access is still only 32bit, so nothing on the LinuxCNC side of things would have made this work how I had originally attempted.

My solution was to set fieldbus scaling in such a way that for the total travel, I stay below 32 bit and maximize resolution that way.

All that being said, using LinuxCNC EtherCAT has been one of the most pleasant EtherCAT experiences across quite a few ECAT platforms I've used.

I really hope this makes it's way into the standard release in the future. It was a real struggle to get the EtherLab module working. Grotius' ISO that he posted a while back was really a life saver - made it super easy to get up and running on new computers.

@Sockheaven
Have you posted some vid/clip about your machine now as it is running ?

Best rgds

udo

Unfortunately I don't. Most of the videos I took were just getting things running with the Spindle and then a small 15W Laser, but not making anything. Once that machine was up and running I moved it to one of our offices so others could start learning more about how customers use our products.I will try to do better next time. I'm working on our second machine now, this time with ball screws instead of linear motors: 
 

I'll try to be better this time and post some videos once I get everything up and running. (and actually make something before I give the machine to another group).