Closed Loop Issue

Thanks for taking a look at this issue we are having, any help is greatly appreciated.

We are attempting to close the feedback loop between LinuxCNC and our real-world arm/motors. Attached is the HAL file showing the connection of the position feedback from the drives to the axis.n.motor-pos-fb pins.
With this configuration, our motors do not move when jogged in Axis. A following error pops up and the machine power forces itself off.

LinuxCNC 2.7.5

Are you using Ethercat? Is there any evidence that that is working?

If you make the following error very big do any motors move?

We are using Ethercat.
We can jog all axes with the default feedback loop (where LinuxCNC is not aware of the physical position of the motors).

I changed the following error from the default of 2 to 10 and then jogged axis 0, 4, 3 in turn.
Errors:
joint 0 following error
emc/task/taskintf.cc 617: Error on axis 0, command number 143
joint 4 following error
emc/task/taskintf.cc 617: Error on axis 4, command number 176
joint 3 following error
emc/task/taskintf.cc 617: Error on axis 3, command number 211

Did anything move?

Perhaps the feedback is backwards or not scaled the same as the command?

There was no movement.

Is there any better approach to scaling than what we are currently doing?

To convert LinuxCNC units (degrees) to drive/motor units (steps) we are performing a scaling operation and converting the value from float to s32.

net pos0_unscaled axis.0.joint-pos-cmd => mult2.0.in1
setp mult2.0.in0 18203.7 #scaling factor for degrees to steps for axis 0
net pos0_scaled mult2.0.out conv-float-s32.0.in
net pos0_s32 conv-float-s32.0.out => lcec.0.0.poscommand

We then have to do the inverse for the feedback scaling

net J0s32 lcec.0.0.pos conv-s32-float.0.in
setp mult2.6.in0 0.00005493 #(1/18203.7)
net J0Uns conv-s32-float.0.out mult2.6.in1
net J0f mult2.6.out axis.0.motor-pos-fb

Cpk_Rbt wrote: T
Is there any better approach to scaling than what we are currently doing?

It seems that the EtherCAT driver could usefully have backwards and forwards scaling parameters.

However, EtherCAT isn't actually part of the LinuxCNC project, so I don't know what it would take to achieve that.
You could try raising an issue asking for scaling to be added on the linuxcnc-ethercat GitHub.
github.com/sittner/linuxcnc-ethercat/issues

Cpk_Rbt wrote: There was no movement.

Is there any better approach to scaling than what we are currently doing?

Do not know if this helps you much, but have a look at github.com/sittner/linuxcnc-ethercat/blo...c_conf.c#L1106-L1118 , float has a scale and and offset XML attribute.

If you add your EtherCAT read and write functions like this: then it means that lcec.write-all is called right after lcec.read-all .
If and how any scale function ( attached to a different thread/ servo thread)
would work there is unpredictable for me.

If I had you task, I'd write a simple scaling component and add its function like Then I'd be sure that scaling always takes place after EtherCAT read and before EtherCAT write.

The XML float and offset look like the thing to try.

Is there any benefit in running anything in the servo-thread if all the IO happens in the test-thread? I think it just means that everything is calculated twice with the same input data.

andypugh wrote: Is there any benefit in running anything in the servo-thread if all the IO happens in the test-thread? I think it just means that everything is calculated twice with the same input data.

My point is that when scaling or any other calculation happens on the other thread ( servo thread),
then it is unpredictable ( for me ) how the EtherCAT read/write are synchronized to these calculations/scaling.

So, yes, rather run everything on one thread and add functions to the thread following the rule "first added - first served".

Thank you both for your suggestions!
Some of those things had not occurred to me, like how important the order the functions are added to the thread. I never considered that was their execution order. It makes sense now that you explained it.
I'm going to move everything to the test-thread and rearrange them to try to get some meaningful results.
Thanks again!