Closed Loop Issue
01 Aug 2016 19:08 #78251
by Cpk_Rbt
Closed Loop Issue was created by Cpk_Rbt
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
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
Please Log in or Create an account to join the conversation.
02 Aug 2016 23:15 #78310
by andypugh
Replied by andypugh on topic Closed Loop Issue
Are you using Ethercat? Is there any evidence that that is working?
If you make the following error very big do any motors move?
If you make the following error very big do any motors move?
Please Log in or Create an account to join the conversation.
03 Aug 2016 12:37 #78322
by Cpk_Rbt
Replied by Cpk_Rbt on topic Closed Loop Issue
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
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
Please Log in or Create an account to join the conversation.
03 Aug 2016 13:34 #78324
by andypugh
Replied by andypugh on topic Closed Loop Issue
Did anything move?
Perhaps the feedback is backwards or not scaled the same as the command?
Perhaps the feedback is backwards or not scaled the same as the command?
Please Log in or Create an account to join the conversation.
03 Aug 2016 13:42 - 03 Aug 2016 13:43 #78326
by Cpk_Rbt
Replied by Cpk_Rbt on topic Closed Loop Issue
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
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
Last edit: 03 Aug 2016 13:43 by Cpk_Rbt.
Please Log in or Create an account to join the conversation.
03 Aug 2016 14:44 #78328
by andypugh
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
Replied by andypugh on topic Closed Loop Issue
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
Please Log in or Create an account to join the conversation.
04 Aug 2016 10:29 - 04 Aug 2016 10:30 #78348
by sirop
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 likeThen I'd be sure that scaling always takes place after EtherCAT read and before EtherCAT write.
Replied by sirop on topic Closed Loop Issue
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:
loadrt threads name1=test-thread period1=2000000
addf lcec.read-all test-thread
addf lcec.write-all test-thread
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
loadrt threads name1=test-thread period1=2000000
addf lcec.read-all test-thread
addf ScalingComponentFunction test-thread
addf lcec.write-all test-thread
Last edit: 04 Aug 2016 10:30 by sirop. Reason: typo
The following user(s) said Thank You: Cpk_Rbt
Please Log in or Create an account to join the conversation.
04 Aug 2016 11:17 #78350
by andypugh
Replied by andypugh on topic Closed Loop Issue
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.
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.
The following user(s) said Thank You: Cpk_Rbt
Please Log in or Create an account to join the conversation.
04 Aug 2016 11:26 #78351
by sirop
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".
Replied by sirop on topic Closed Loop Issue
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".
The following user(s) said Thank You: Cpk_Rbt
Please Log in or Create an account to join the conversation.
04 Aug 2016 12:16 #78353
by Cpk_Rbt
Replied by Cpk_Rbt on topic Closed Loop Issue
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!
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!
Please Log in or Create an account to join the conversation.
Time to create page: 0.176 seconds