Cinématique avec axes "redondants" (+présentation)

More
29 Oct 2014 23:01 #52544 by vincentECN
Ok ! Thx !

I'll try ASAP and tell you if it's work ! ;)
More
12 Dec 2014 23:13 #53965 by vincentECN
Hello,

Some news about my problem.

So, I've tried first on sim config.
I succeed to add a sum on the feedback position (only on X), like we can see under :
loadrt sum2 count=2

addf sum2.0 servo-thread
addf sum2.1 servo-thread

newsig Ufic float
net Ufic => sum2.0.in1
net Ufic => sum2.1.in1
sets Ufic 0
newsig zero float
net zero => sum2.1.in0
sets zero 0

net Xpos joint.0.motor-pos-cmd => sum2.0.in0
net XUpos sum2.0.out
#net Xpos joint.0.motor-pos-cmd => joint.0.motor-pos-fb ddt.0.in
net XUpos => joint.0.motor-pos-fb ddt.0.in
net Ypos joint.1.motor-pos-cmd => joint.1.motor-pos-fb ddt.2.in
net Zpos joint.2.motor-pos-cmd => joint.2.motor-pos-fb ddt.4.in

(NB : sum.2.1 was created only to have a pin for sampler.)

During the execution of a trajectory, i can modify the shift Ufic (for exemple "sets Ufic 1").
And i can see that the X on preview (AXIS) is modify in 1 (from 0). But i have the feeling that is only a superflu change.
If I want a line on X from 0 to 100 (G1 X0 / G1 X100), the tools go from 1 to 101.
And when i have the preview with X 1.000, and a command of G1 X0, nothing move.

I wanted that when i add a shift, the movement of the machine will compensate.

Maybe i don't modify the good feedback ?
net XUpos => joint.0.motor-pos-fb ddt.0.in

Can i have some help ?

I hope it's clear. If you need some details, don't hesitate.

Thx in advance,

PS : in attachement, the old hal config, the new one and a screenshot of the display.
Attachments:
More
16 Dec 2014 07:58 #54049 by andypugh

vincentECN wrote: newsig zero float
net zero => sum2.1.in0
sets zero 0


This works, but "setp sum2.1.in0 0" has the same effect and is simpler.

I wanted that when i add a shift, the movement of the machine will compensate.


I have forgotten where we got to on this. Have you looked at tool offsets and the "offset" HAL component?
More
16 Dec 2014 20:04 #54060 by vincentECN

andypugh wrote:

vincentECN wrote: newsig zero float
net zero => sum2.1.in0
sets zero 0


This works, but "setp sum2.1.in0 0" has the same effect and is simpler.


Ok !

andypugh wrote:

I wanted that when i add a shift, the movement of the machine will compensate.


I have forgotten where we got to on this. Have you looked at tool offsets and the "offset" HAL component?


At the beginning, i wanted to modify the cinematics of the machine to add some fictive axis (not controllable) in the goal to modify the feedback position of the workpiece, in the goal that the machine will compensate.

And after, you say it's more easy to modifiy the hal file, where we cand add a sum on the feedback position.

I've already thought about tool offset, but it will not work when i will want to compensate a error of rotation position of the work piece...
I prefere to modifiy directly the position, but now, i have the impression that i have only a modification of the "display" feedback. The behaviour of the machine don't change. :/
(see files in attachement.)
More
18 Dec 2014 23:32 #54132 by vincentECN
See in attachement, an exemple of sampler* plot.

For the G-code :
G1 X-10
G1 X10

I modify the shift on hal configuration (from 0 to 1) during the process.
And i expected to have a final position at X10, but finally it's X9...
I don't understand...

*net samp0 motion.current-vel => sampler.0.pin.0
net samp1 joint.0.pos-fb => sampler.0.pin.1
net samp2 joint.0.vel-cmd => sampler.0.pin.2
net samp3 sum2.1.out => sampler.0.pin.3
Attachments:
More
19 Dec 2014 00:12 #54134 by andypugh

vincentECN wrote: And i expected to have a final position at X10, but finally it's X9...
I don't understand...


You need to be very clear about the distinction between joint positions (in absolute machine units), the on-screen reported position (in workpiece coordinates, unaware of anything happening in HAL, and following the XYZ commands exactly), and the actual physical position of the tool.

What you are seeing _might_ be correct. I can't tell exactly how you have things set up.

You probably need to pass the command to the offset through a limit3 component to remain within machine limits.

In your example you have an offset of -1, the joint is at 9, and the commanded position is 10. That is correct for some definitions of the offset.
In this scenario, if the "extra" axis offset was 1, then the X-joint at 9 would put the tool at 10 on the workpiece. You might need to switch some signs if it doesn't make sense like this.
The following user(s) said Thank You: vincentECN
More
19 Dec 2014 20:39 #54161 by vincentECN

andypugh wrote: You need to be very clear about the distinction between joint positions (in absolute machine units), the on-screen reported position (in workpiece coordinates, unaware of anything happening in HAL, and following the XYZ commands exactly), and the actual physical position of the tool.


Yes. It's on these distinctions that i begin to be confused.
In my head, the logical is : I modifiy the feedback, so the machine adapts the position of the tools.

The most easy to understand is (see attachement) :
I want a line from 0 to 10 on X (with Y =0) on a workpiece.
If there is no problem, i will have this line with the Gcode G00 X0 Y0 / G01 X10 Y0.
Now, we can imagine that the workpiece have a disturbance on Y during the process (like a displacement due to positionning system or vibration etc...). For exemple a displacement of 1mm on Y.
With the same code, i will have a wrong line, wrong workpiece.
So, i want to take in account this disturbance (in my experiment, i will controlate this disturbance, link to an encoder) : in feedback position ?
So, normally, instead of have this behaviour (X0 1 2 3 .... 9 10, and Y 0 0 0 0... 0 0 0), i want to have X0 1 2 3 .... 9 10 and Y 0 0 0 ... 1 /!\ 0,5 0 0 ... 0 0) but actually, i will stay at Y = 1... (Y 0 0 0 0 ... 1 1 .... 1)

I want to disturbe the feedback position and always respect the G code. (have Y = 0 at the end).

So, maybe i'm wrong in the choice of the feedback position ? (wich other i can use ??) Maybe i'm wrong on the sampler ? Maybe it's a wrong behaviour on simulation ?

I hope it's more clear... ^^"
Attachments:
More
28 Dec 2014 19:29 #54334 by andypugh
In the situation you describe there are two things to control. You need the tool in the correct physical position, and you need the LinuxCNC system to know that the tool is in the correct position.

The first part would be rather easy if it were not for the second part.

Imagine a system where the Y-axis command signal has the "disturbance" subtracted from it before it goes in to the PID command input. Then the tool position would be automatically compensated in the way that you describe. Unfortunately the _feedback_ to LinuxCNC would then not match the command signal, and the system would stop with a following-error.

So, one solution to this problem is to use the "offset" HAL component, which only really adds one signal to another, but is clever enough to subtract the difference on way back so that the following-error fault is not tripped.
www.linuxcnc.org/docs/html/man/man9/offset.9.html

Putting this between the LinuxCNC joint command pin and the PID input might do what you want.

There are other possibilities: Perhaps you want to have a second PID component to control the "disturbance' correction. You could add the output of the two PID components together to get a combined motor speed command. This might work better, but it it then rather more difficult to "fiddle" the feedback pin into LinuxCNC.

Of course there is a much simpler way to "fiddle" the LinuxCNC position feedback and avoid setting the following-error: You can simply short-circuit that loop in HAL:
net axis.1.motor-position-cmd => axis.1.motor-position-fb . But then you have no following-error tracking.

Or you can stretch the f-error limits in the INI to encompass the likely size of the "disturbance" so that the system only errors when the disturbance is too big.
More
05 Jan 2015 22:23 #54576 by vincentECN
Thank you for your answer (and happy new year !).

I will try what you suggest very soon.
More
04 Feb 2015 22:39 #55686 by vincentECN
Hi,

I have again some questions...

andypugh wrote: So, one solution to this problem is to use the "offset" HAL component, which only really adds one signal to another, but is clever enough to subtract the difference on way back so that the following-error fault is not tripped.
www.linuxcnc.org/docs/html/man/man9/offset.9.html

Putting this between the LinuxCNC joint command pin and the PID input might do what you want.


About this sentence, i tried to use the components offset, but i don't understand how to use all pins and i'm note sure if i have understood.
You can see in attachment, what i have at the beginning, and how i put my offset. But you will see that this do nothing (because after add and substract my offset, finnally i return to my initial value.

This is what i added on hal :
loadrt offset count=1

addf offset.0.update-output servo-thread
addf offset.0.update-feedback servo-thread

net Ufic => offset.0.offset

net Xpos joint.0.motor-pos-cmd => offset.0.in
net Xposm offset.0.fb-out => joint.0.motor-pos-fb
net Xposp offset.0.out => offset.0.fb-in ddt.0.in
net Ypos joint.1.motor-pos-cmd => joint.1.motor-pos-fb ddt.2.in
net Zpos joint.2.motor-pos-cmd => joint.2.motor-pos-fb ddt.4.in

(Of course, this work, but do nothing special.)

Do i have to delete the PID ? To modifiy the component Motmod to interact with signal connected to joint.0-motor-pos-fb ?

I need some help. Maybe i just don't understood how to use offset components.... :S

Thank you for your response.
You are a big help for me !
Attachments:
Moderators: darty367
Time to create page: 0.252 seconds
Powered by Kunena Forum