×
Forum Header
How are the DRO and Stepgen kept in sync?
10 Jan 2017 18:28 - 10 Jan 2017 18:29 #85578
by GaryLa
Replied by GaryLa on topic How are the DRO and Stepgen kept in sync?
If, for example, the HAL file were (psuedo-coded):
loadrt hardware_Interface_PRE_motion servo_thread
loadrt motion_controller_handler servo_thread
loadrt hardware_Interface_POST_motion servo_thread
In this example, a feedback item is updated in "pre", then the motion controller items are invoked, then the new pos_cmd/freq is pushed out to the hardware by "post".
Assuming a 1ms servo thread time, how does the hardware have any idea of how long it actually has to perform the move? The time from POST acquiring the new cmd_pos/freq and the time PRE needs to update pos_fb can vary due to execution time of motion_controller_handler.
How can it calculate items such as velocity/acceleration over time and be assured to land at the new cmd_pos before PRE requires the update info? It seems to me the 1ms frequency of the servo thread will vary and rarely be exactly 1ms.
Does this not have an effect on hardware's ability to arrive at the given location in the allotted time?
loadrt hardware_Interface_PRE_motion servo_thread
loadrt motion_controller_handler servo_thread
loadrt hardware_Interface_POST_motion servo_thread
In this example, a feedback item is updated in "pre", then the motion controller items are invoked, then the new pos_cmd/freq is pushed out to the hardware by "post".
Assuming a 1ms servo thread time, how does the hardware have any idea of how long it actually has to perform the move? The time from POST acquiring the new cmd_pos/freq and the time PRE needs to update pos_fb can vary due to execution time of motion_controller_handler.
How can it calculate items such as velocity/acceleration over time and be assured to land at the new cmd_pos before PRE requires the update info? It seems to me the 1ms frequency of the servo thread will vary and rarely be exactly 1ms.
Does this not have an effect on hardware's ability to arrive at the given location in the allotted time?
Last edit: 10 Jan 2017 18:29 by GaryLa.
Please Log in or Create an account to join the conversation.
10 Jan 2017 21:42 #85593
by PCW
Replied by PCW on topic How are the DRO and Stepgen kept in sync?
JItter in the 1 ms servo thread does cause position errors in the stepgen.
Typically they are too small to worry about unless you have a combination of high speed
and high accuracy requirements, as they are in to 50 to 100 uinch range with typical
latencies and typical machining speeds.
There are 2 main components of the error:
1. Delay from reading the position to writing the new velocity.
This only affects accelerated motion and the error is proportional
to the acceleration*delay
2. Servo thread jitter causing errors in the position feedback
This does not cause a direct error but generates an error
proportional to velocity that causes the position feedback loop to
make a incorrect adjustment in the velocity
Neither of these errors cause static position errors, but rather inject a small amount of noise
into motion profiles. In most real machines, these errors are swamped by mechanical errors.
#1 can be compensated for by adding FF2 to the control loop (FF2 = seconds between position read and velocity write)
#2 can be compensated for by lowered servo thread jitter or on Mesa hardware, by using the DPLL to sample the position.
Not sure about other hardware but the combination of the 2 remedies above with Mesa hardware reduce the errors to a few uinches at normal cutting speeds ( say to 200 IPM )
Typically they are too small to worry about unless you have a combination of high speed
and high accuracy requirements, as they are in to 50 to 100 uinch range with typical
latencies and typical machining speeds.
There are 2 main components of the error:
1. Delay from reading the position to writing the new velocity.
This only affects accelerated motion and the error is proportional
to the acceleration*delay
2. Servo thread jitter causing errors in the position feedback
This does not cause a direct error but generates an error
proportional to velocity that causes the position feedback loop to
make a incorrect adjustment in the velocity
Neither of these errors cause static position errors, but rather inject a small amount of noise
into motion profiles. In most real machines, these errors are swamped by mechanical errors.
#1 can be compensated for by adding FF2 to the control loop (FF2 = seconds between position read and velocity write)
#2 can be compensated for by lowered servo thread jitter or on Mesa hardware, by using the DPLL to sample the position.
Not sure about other hardware but the combination of the 2 remedies above with Mesa hardware reduce the errors to a few uinches at normal cutting speeds ( say to 200 IPM )
The following user(s) said Thank You: GaryLa
Please Log in or Create an account to join the conversation.
Time to create page: 0.111 seconds