Real Time and Latency

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.

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.

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 are you trying to do, exactly?

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.

tommylight wrote:

What are you trying to do, exactly?

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.
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.