Axis modulo 360 (not about wrapped_rotary)

More
29 May 2023 09:33 #272411 by am-i-go
Hello everyone!

I need your help, gentlemen!
There is a servo and a Leadshine motor with an absolute multi-turn encoder. They work on the axis of rotation A, and the axis should be in coordinates modulo 360 degrees.

Now , to simplify the ratio of motor speed and axis one to one - for one rotation of the motor , the axis coordinate changes to 359.999 degrees . At the same time, the value of increments per motor revolution in the drive is 10000 by default, the position-scale parameter 27.7751 is set in the linuxcnc hal file, then the maximum coordinate is recalculated from 10000 to 359.999.

Then I set the wrapped_rotary parameter in the ini file to 1 and when the axis passes through 0 degrees, the error "joint 3 following error" occurs. At low speeds, this error occurs at the 359.2 coordinate and zero crossing does not occur yet, but the axis does not rotate further.

If the encoder is configured as an absolute linear and the axis is wrapped, then I saw how the axis rotates in one direction modulo 360 degrees without errors, but only until the value of the encoder buffer overflows (at 10000 increments per motor revolution it will be 214748 turns) and after that the coordinate jump again leads to the error "joint 3 following error". If I apply the reduction coefficient, then the number of revolutions of the axis without an error in one direction will become much less.

I attach the settings files. Please indicate in which direction to dig.
Attachments:

Please Log in or Create an account to join the conversation.

More
31 May 2023 11:55 #272553 by andypugh
If it is a _multi_ turn encoder this should not happen. Unless the single and multi turn data are on separate HAL pins?

Can you add the partial and full turns together in HAL before calculating the position?
You might end up needing a custom component.
The following user(s) said Thank You: am-i-go

Please Log in or Create an account to join the conversation.

More
31 May 2023 12:50 #272556 by am-i-go

Unless the single and multi turn data are on separate HAL pins?

Only multi-turn spin data is read.

The "following error" no longer appears, when I changed the parameter in the ini file:
[AXIS_A] => FERROR = 1e99
But it is not clear to me whether I did the right thing by changing the parameter in this way...

Thank you Andy for your help!

Please Log in or Create an account to join the conversation.

More
31 May 2023 13:03 #272558 by andypugh
Well, you have set up the system to _never_ flag a following error. At that point you might as well not bother with the encoder feedback.

Please Log in or Create an account to join the conversation.

More
23 Jun 2023 12:42 - 27 Jun 2023 09:45 #274134 by am-i-go
I incorrectly described the essence of the problem.

It is necessary to be able to make an indefinitely large (infinite) number of revolutions in any direction and track the angle of the rotating globe table in the value of the coordinate modulo 360 degrees.

1) As I understand it, in this case the axis must necessarily be configured as wrapped . Is that so, there are no other options?

To interaction of linuxcnc with servos, I use a ready-made Hal component cia402 . This component recalculates the values in the following way to get the current position of the servo on the pos_scale (float) scale:

// read position feedback (float pos_fb)
pos_fb = ((double)drv_actual_position) * pos_scale_rcpt;
pin in signed drv_actual_position "Drives actual Position, index 0x6064"
pos_scale_rcpt = 1.0 / pos_scale;


In the case of servos that I use, the value of the current position in the EtherCAT register (6064) is of type int32 (a number in the range of 2147483648 ~ 2147483647 encoder increments). In this case, the pin takes the value of the signed data type (meaning int32), but the HAL documentation specifies the values -2147483647 to +2147483647 , i.e. a negative minimum is 1 more than what is commonly assumed for this type of data. It looks like an error in the documentation, probably this can be ignored ...? It turns out, even though pos_fb has the float type, but we cannot get a value beyond the int32 range of values, because the servo can only transmit int32.
Next, the cia402 Hal component recalculates the position values on the pos_scale scale for the servo movement command:

// write position command (out pin signed drv_target_position)
drv_target_position = (int32_t) (pos_cmd * pos_scale);
pin in float pos_cmd "target Position, from Motion or PID";

Everything is fine here, the command with the int32 data type goes to the servo, as expected.

In my case, with a scale of 23138.953 ... increments by one degree, it turns out to move from the zero value of the current position to the stop of the servo 92808 degrees in both directions. After reaching the value of 2147483647 (or -2147483648) increments, the motor stops without errors on the servo and in linuxcnc, and the coordinate of the rotation angle of the A axis in linuxcnc jumps from 288 to 71 degrees. It is not possible to continue moving in the same direction, the feed rate appears in the interface, but the motor stands still.

2) Explain to me what could be the reason for this behavior?
Attachments:
Last edit: 27 Jun 2023 09:45 by am-i-go.

Please Log in or Create an account to join the conversation.

More
11 Jul 2023 13:17 #275208 by andypugh

2) Explain to me what could be the reason for this behavior?

This sounds like a simple 32-bit wrap. 
Ideally the EtherCAT driver would store internal position in a 64-bit integer, which would move the problem into the far, far distant future. 

Do you know what data is sent in the actual EtherCAT packet? 
 

Please Log in or Create an account to join the conversation.

More
12 Jul 2023 01:51 #275249 by rodw

Ideally the EtherCAT driver would store internal position in a 64-bit integer, which would move the problem into the far, far distant future. 

 


It may not be simple. The data from ethercat is mapped to hal pins in an XML file and Hal does not have an int64_t data type.
Perhps the encoder value could be defined in the XML as being 2 x  S32's (low byte and high byte) which are then combined in the cia402.comp to create the int64_t. But how can that value be used in HAL?

It seems like an additional S64 data type needs to be added to Hal.to solve these kinds of issues

Please Log in or Create an account to join the conversation.

More
12 Jul 2023 08:52 #275261 by andypugh

It may not be simple. The data from ethercat is mapped to hal pins in an XML file and Hal does not have an int64_t data type.


Some encoders and stepgens are internally 64 bits currently. The floating-point position can be calculated from an internal 64-bit buffer. (There are problems presenting the counts / steps, but generally it is the position that is used)

The development version of LinuxCNC does now include 64-bit HAL pin types: github.com/LinuxCNC/linuxcnc/pull/2034

I plan to make the counters which are _not_ 64 bits internally 64 bits: github.com/LinuxCNC/linuxcnc/issues/2331
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
12 Jul 2023 21:39 #275303 by rodw
Very cool Andy. The halcompile docs need updating for the new type (yes I looked before posting)
linuxcnc.org/docs/devel/html/hal/comp.html

So the issue now for EtherCAT will be that the EtherCAT hal driver is unaware of the new pin type.
A component something like conv_U32hilo_U64.comp would be a handy addition and would allow a workaround to instances like this.
This mythical comp would take the hi and lo 32 bit words (inhi and inlo), shift the hi word and output the sum as a U64 (out64)

Please Log in or Create an account to join the conversation.

More
12 Jul 2023 22:05 #275306 by andypugh
Actually, I think that your mythical comp is a great idea, as long as it's more like my idea that yours prompted.

wrap_32_64.comp

Takes a 32-bit signed input, and converts to a signed 64 output.

If the 32-bit input changes by more than 30 bits in a single thread cycle, the component assumes a wrap and outputs a wrapped value.

It's simple and solves a bunch of potential use-cases.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

Time to create page: 0.637 seconds
Powered by Kunena Forum