Real Time and Latency
- ogogon
-
Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 35
- Thank you received: 1
08 May 2025 23:35 #328035
by ogogon
Real Time and Latency was created by ogogon
Colleagues, I once selected a platform for installing LinuxCNC. I measured the time parameters of different computers. I tried several different models. The fifth one was suitable. I brought it from another city.
Later, I thought about the technical meaning of what was happening and realized that I had some misunderstanding at the general level. You could say at the philosophical level.
The EMC2 program communicates with stepper motor controllers via a discrete interface. It can transmit only one command - "Take a step!" The command has only one parameter - "Step direction", forward or backward. The straight line or curve along which the machine tool needs to be moved is approximated into separate steps, with an accuracy of up to the real linear value of the step or microstep of this axis. Commands for performing steps are given sequentially.
Thus, due to the discreteness of all these events, the time parameters do not determine anything - only the correct sequence of performing the calculated steps is important. Of course, if the commands are given too quickly, and the stepper motor with actuators will not keep up, then it is possible that some of the commands from the sequence will not be executed due to the lack of speed of the mechanical components.
If the commands are given slowly, then no negative factors should arise, except for the unproductive loss of time. Even within a week - the machine will still cut out the part described to it.
Why then, are the parameters of real time and delays given such importance? What can they affect?
I am grateful for the answers to the point.
Ogogon.
Later, I thought about the technical meaning of what was happening and realized that I had some misunderstanding at the general level. You could say at the philosophical level.
The EMC2 program communicates with stepper motor controllers via a discrete interface. It can transmit only one command - "Take a step!" The command has only one parameter - "Step direction", forward or backward. The straight line or curve along which the machine tool needs to be moved is approximated into separate steps, with an accuracy of up to the real linear value of the step or microstep of this axis. Commands for performing steps are given sequentially.
Thus, due to the discreteness of all these events, the time parameters do not determine anything - only the correct sequence of performing the calculated steps is important. Of course, if the commands are given too quickly, and the stepper motor with actuators will not keep up, then it is possible that some of the commands from the sequence will not be executed due to the lack of speed of the mechanical components.
If the commands are given slowly, then no negative factors should arise, except for the unproductive loss of time. Even within a week - the machine will still cut out the part described to it.
Why then, are the parameters of real time and delays given such importance? What can they affect?
I am grateful for the answers to the point.
Ogogon.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 20211
- Thank you received: 6877
09 May 2025 01:16 #328038
by tommylight
Replied by tommylight on topic Real Time and Latency
EMC2 was 15 years ago, i think, LinuxCNC now.
Latency is very important on machines requiring precision timing controls, that is the important part.
As for your "If the commands are given slowly, then no negative factors should arise, except for the unproductive loss of time. Even within a week - the machine will still cut out the part described to it.", that is not correct for LinuxCNC as it points to the wrong direction of the process and totally misses the point of timing, namely timing is not how long it takes to finish a part, it is how long it takes before a signal missed the correct time to be issued/executed, and this is something that can not wait as it would cause other signals to be delayed or missed completely causing as a result a machine crash.
As far as i understand your view is from the GRBL/Gcode sender point of view as they send gcode line by line, LinuxCNC will run the whole gcode as soon as you open it and will have the trajectory planner already planed and ready all the moves up front in memory, and patiently wait for the run command to start controlling the hardware.
The confusion mostly is as a result of to many "internet experts" making a big deal of latency, it is not "the big bad wolf" for sure, it just depends on what you need and finding a PC that is not terrible at it.
In general, for software stepping using parallel port, anything under 100000 in latency can be used, but might limit the top speed depending on the microstepping used on the drives. There are plenty of industrial machines using parallel port, so it is very reliable.
For use with Mesa boards, even 200000-300000 latency can be used, as long as there are no big excursions.
In, short, skip latency and start building the machine, out of over 150 PC's i have tested, probably some 4 or 5 were unusable. I mostly use old "Enterprise" PC's like Dell, HP, Fujitsu and Lenovo.
Latency is very important on machines requiring precision timing controls, that is the important part.
As for your "If the commands are given slowly, then no negative factors should arise, except for the unproductive loss of time. Even within a week - the machine will still cut out the part described to it.", that is not correct for LinuxCNC as it points to the wrong direction of the process and totally misses the point of timing, namely timing is not how long it takes to finish a part, it is how long it takes before a signal missed the correct time to be issued/executed, and this is something that can not wait as it would cause other signals to be delayed or missed completely causing as a result a machine crash.
As far as i understand your view is from the GRBL/Gcode sender point of view as they send gcode line by line, LinuxCNC will run the whole gcode as soon as you open it and will have the trajectory planner already planed and ready all the moves up front in memory, and patiently wait for the run command to start controlling the hardware.
The confusion mostly is as a result of to many "internet experts" making a big deal of latency, it is not "the big bad wolf" for sure, it just depends on what you need and finding a PC that is not terrible at it.
In general, for software stepping using parallel port, anything under 100000 in latency can be used, but might limit the top speed depending on the microstepping used on the drives. There are plenty of industrial machines using parallel port, so it is very reliable.
For use with Mesa boards, even 200000-300000 latency can be used, as long as there are no big excursions.
In, short, skip latency and start building the machine, out of over 150 PC's i have tested, probably some 4 or 5 were unusable. I mostly use old "Enterprise" PC's like Dell, HP, Fujitsu and Lenovo.
Please Log in or Create an account to join the conversation.
- ogogon
-
Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 35
- Thank you received: 1
09 May 2025 03:23 #328040
by ogogon
Replied by ogogon on topic Real Time and Latency
Thank you. You tell very interesting things.
What approximation algorithm does LinuxCNC use and what are its real advantages over step-by-step G-code processing? Is there any specific publication about this?
For example, the following question immediately arises. If the algorithm can somehow find a win by asynchronously starting the steps of the drives of different axes, then how does it do this if the settings do not have such a parameter as the step execution time? How can we synchronize actions at the level of the entire program if we know the real start time of the step, but only very approximately know its end time. And there are many such steps - a whole program. (Or did I misunderstand you?)
What approximation algorithm does LinuxCNC use and what are its real advantages over step-by-step G-code processing? Is there any specific publication about this?
For example, the following question immediately arises. If the algorithm can somehow find a win by asynchronously starting the steps of the drives of different axes, then how does it do this if the settings do not have such a parameter as the step execution time? How can we synchronize actions at the level of the entire program if we know the real start time of the step, but only very approximately know its end time. And there are many such steps - a whole program. (Or did I misunderstand you?)
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 20211
- Thank you received: 6877
09 May 2025 05:54 #328043
by tommylight
Replied by tommylight on topic Real Time and Latency
What are you trying to do, exactly?
Please Log in or Create an account to join the conversation.
- unknown
- Away
- Platinum Member
-
Less
More
- Posts: 351
- Thank you received: 134
09 May 2025 11:39 #328055
by unknown
Replied by unknown on topic Real Time and Latency
The values for step & direction are part of the ini file and can be adjusted to suit many stepper driver products.
With a 25000 ns base thread motion will be based on this.
External motion control is usually based on a 1ms update period.
Hence the reason a known & steady latency is important, regularity is an important factor, like a band if the drummer isn't regular, uhmmm like Lars from Metallica, things don't work as well as they should.
With a 25000 ns base thread motion will be based on this.
External motion control is usually based on a 1ms update period.
Hence the reason a known & steady latency is important, regularity is an important factor, like a band if the drummer isn't regular, uhmmm like Lars from Metallica, things don't work as well as they should.
Please Log in or Create an account to join the conversation.
- ogogon
-
Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 35
- Thank you received: 1
09 May 2025 15:32 #328080
by ogogon
I have dealt with several professional control stations - Fanuc, Siemens. All of them issued control commands sequentially.
From you I learned that LinuxCNC uses a more progressive algorithm. Now I want to know about it.
Replied by ogogon on topic Real Time and Latency
Einstein said that the basis of science is the flight from amaze. I am amazed and I trying to understand the meaning of what amazed me. This is important.What are you trying to do, exactly?
I have dealt with several professional control stations - Fanuc, Siemens. All of them issued control commands sequentially.
From you I learned that LinuxCNC uses a more progressive algorithm. Now I want to know about it.
Please Log in or Create an account to join the conversation.
- ogogon
-
Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 35
- Thank you received: 1
09 May 2025 15:49 #328083
by ogogon
When we start discussing milliseconds, it means that we have accepted as a given the position about the need for parallel execution of commands on different axes.
Maybe this is true, but I do not yet fully understand the wisdom of this idea.
Where can I see materials about this?
Replied by ogogon on topic Real Time and Latency
Regarding the step value and the ini file. Correct me if I'm wrong, but its linear value is specified there, not the execution time. (When I set up my CNC, there was no talk about time.)The values for step & direction are part of the ini file and can be adjusted to suit many stepper driver products.
With a 25000 ns base thread motion will be based on this.
External motion control is usually based on a 1ms update period.
Hence the reason a known & steady latency is important, regularity is an important factor, like a band if the drummer isn't regular, uhmmm like Lars from Metallica, things don't work as well as they should.
When we start discussing milliseconds, it means that we have accepted as a given the position about the need for parallel execution of commands on different axes.
Maybe this is true, but I do not yet fully understand the wisdom of this idea.
Where can I see materials about this?
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18567
- Thank you received: 5101
09 May 2025 15:53 #328084
by PCW
Replied by PCW on topic Real Time and Latency
LinuxCNC works identically to most CNC systems in that it outputs
a stream of joint/axis position coordinates (waypoints) at a fixed rate.
In LinuxCNC this rate is called the servo thread rate. This is typically
1 KHz in LinuxCNC but can be higher. In addition, either LinuxCNC or
downstream hardware interpolates between the position waypoints
so smooth motion is generated.
Simple LinuxCNC systems using a parallel port or GPIO do the interpolation
and step/dir generation with a second, faster real time thread, called the base thread.
More complex systems do the interpolation in external hardware or processors
(Mesa cards, Remora, RIO etc) or in the motor drive itself (EtherCAT) and typically
do not use a base thread.
a stream of joint/axis position coordinates (waypoints) at a fixed rate.
In LinuxCNC this rate is called the servo thread rate. This is typically
1 KHz in LinuxCNC but can be higher. In addition, either LinuxCNC or
downstream hardware interpolates between the position waypoints
so smooth motion is generated.
Simple LinuxCNC systems using a parallel port or GPIO do the interpolation
and step/dir generation with a second, faster real time thread, called the base thread.
More complex systems do the interpolation in external hardware or processors
(Mesa cards, Remora, RIO etc) or in the motor drive itself (EtherCAT) and typically
do not use a base thread.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- ogogon
-
Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 35
- Thank you received: 1
09 May 2025 18:27 - 09 May 2025 18:35 #328094
by ogogon
Let me formulate how I understood you. And please correct me if I understood something incorrectly.
1. We are discussing devices with a two-bit discrete interface for controlling stepper drives. (For example, I have a ChinaCNCzone 3040Z 500W machine)
2. The control station must issue step commands at a speed of 1000 Hz, in other words - 1000 steps per second. (As I understand it, not faster than this speed.) This is called the servo thread rate.
3. Since the controllers do not have intelligence (only microstep functionality), the interpolation is done by the program.
4. To perform the interpolation, a certain second thread is used, faster than the first, and having strict requirements for real time. It is called the "base thread".
Then, the specifics end and the fog begins to thicken again. Inevitably, well-founded questions arise.
1. What interpolation algorithm does the program use?
2. How is the second thread, the so-called "base thread", used in it?
3. Why is it faster than the first?
4. What is the reason for the relatively strict requirements for the base thread's real time and relative to what?
5. Where can I read something about this algorithm?
(The goat is cool!)
Replied by ogogon on topic Real Time and Latency
Thank you. It seems the fog is starting to clear. However, not completely yet.LinuxCNC works identically to most CNC systems in that it outputs
a stream of joint/axis position coordinates (waypoints) at a fixed rate.
In LinuxCNC this rate is called the servo thread rate. This is typically
1 KHz in LinuxCNC but can be higher. In addition, either LinuxCNC or
downstream hardware interpolates between the position waypoints
so smooth motion is generated.
Simple LinuxCNC systems using a parallel port or GPIO do the interpolation
and step/dir generation with a second, faster real time thread, called the base thread.
More complex systems do the interpolation in external hardware or processors
(Mesa cards, Remora, RIO etc) or in the motor drive itself (EtherCAT) and typically
do not use a base thread.
Let me formulate how I understood you. And please correct me if I understood something incorrectly.
1. We are discussing devices with a two-bit discrete interface for controlling stepper drives. (For example, I have a ChinaCNCzone 3040Z 500W machine)
2. The control station must issue step commands at a speed of 1000 Hz, in other words - 1000 steps per second. (As I understand it, not faster than this speed.) This is called the servo thread rate.
3. Since the controllers do not have intelligence (only microstep functionality), the interpolation is done by the program.
4. To perform the interpolation, a certain second thread is used, faster than the first, and having strict requirements for real time. It is called the "base thread".
Then, the specifics end and the fog begins to thicken again. Inevitably, well-founded questions arise.
1. What interpolation algorithm does the program use?
2. How is the second thread, the so-called "base thread", used in it?
3. Why is it faster than the first?
4. What is the reason for the relatively strict requirements for the base thread's real time and relative to what?
5. Where can I read something about this algorithm?
(The goat is cool!)
Last edit: 09 May 2025 18:35 by ogogon.
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18567
- Thank you received: 5101
09 May 2025 18:51 #328096
by PCW
Replied by PCW on topic Real Time and Latency
2. The control station must issue step commands at a speed of 1000 Hz, in other words - 1000 steps per second. (As I understand it, not faster than this speed.) This is called the servo thread rate.
No, LinuxCNCs trajectory planner provides waypoints(position vectors) at the servo thread rate.
For simple parallel port type systems these waypoints are sent to a stepgen component that runs
at a higher thread rate (the base thread) and interpolates between the waypoints. That is, the
stepgen component does the high speed step generation so as to reach the next waypoint at the next
servo thread invocation.
No, LinuxCNCs trajectory planner provides waypoints(position vectors) at the servo thread rate.
For simple parallel port type systems these waypoints are sent to a stepgen component that runs
at a higher thread rate (the base thread) and interpolates between the waypoints. That is, the
stepgen component does the high speed step generation so as to reach the next waypoint at the next
servo thread invocation.
Please Log in or Create an account to join the conversation.
Time to create page: 0.083 seconds