Couple questions about RT systems and LinuxCNC in general

Hello,
I have couple of questions about LinuxCNC. I have been studying source code for some time now and have some assumptions I would like to either verify or correct. (As I come from higher language background and Windows, it was deep dive to the centre of the lake.)

I have been testing my whole setup on RT-Preempt kernel and as a hardware I was using Mesa 7I92 an 7I77 so my conclusions are probably biased by that. I also don't have formal CS education (everything I know I studied on my own from internet and books) so I might ask about something trivial. (And I also could study it a lot more.)

So:

• What is the line between C and C++? In the source somewhere there is used C and else there is C++. If I take it that files with .c and .h extensions are written in C and files with .hh and .cc are C++. Many C++ code also uses the extern "C" syntax. Given that modern C++17 is a lot more readable to me if I wanted to change something where I could use it?
• Is real-time thread created by HAL API only one factual thread which gets created by HAL init and destroyed in HAL exit? So in this thread periodically runs some exact code or probably this thread gets periodically scheduled with the same exact code?
• The periode of RT thread, for example 1ms in servo thread, is the smallest unit in which the system can react to changes. For example if I have connected to system ADC which commands servo drive with analogue signal, for the duration of this one ms the state of the ADC will stay the same? The for software created pulses on parallel port. Using shorter thread is only for clock signal purpose (to actually generate the pulse train), but the frequency of the pulses will be the same for whole 1ms? Or another example with e-stop. If the e-stop is activated after the status is polled in the beginning of the thread in the time of executing thread code, the change will be reflected only in the next thread run and not in the current thread run when the actual e-stop was raised because there is no interrupt in RT thread?
• The RT threads should be created from shortest to longest in multiples of the shortest. Is that because the free time between when thread ends its work and time when deterministic constraints would expire is used to schedule and execute another RT thread? The thing I don't really understand is that if some thread is running perpetually and deterministically if there is no downtime it really should fill the whole processor core up, right? But I really want the servo thread to run (or to start) every 1ms, even if it only runs for 0,3ms.

That seems enough so far.

Thank you.

I can attempt to answer a few:

The periode of RT thread, for example 1ms in servo thread, is the smallest unit in which the system can react to changes. For example if I have connected to system ADC which commands servo drive with analogue signal, for the duration of this one ms the state of the ADC will stay the same? The for software created pulses on parallel port. Using shorter thread is only for clock signal purpose (to actually generate the pulse train), but the frequency of the pulses will be the same for whole 1ms? Or another example with e-stop. If the e-stop is activated after the status is polled in the beginning of the thread in the time of executing thread code, the change will be reflected only in the next thread run and not in the current thread run when the actual e-stop was raised because there is no interrupt in RT thread?

Yes, the typical minimum response time is one thread period. In systems with hardware beyond just a parallel port that have only a servo thread, the servo thread period will determine the response time to external events. I'm not sure about the software stepgen,
but the hardware stepgens I'm aware of do not implement acceleration so the pulse rate will be the same between updates. Note that
at 1 KHz, the actual chord error between the piecewise linear motion and actual profile caused by this stepped velocity is unimportant (in the 1 u region) unless you have a combined need for high accuracy and very high acceleration (laser plotters for example) This also applies to analog outputs. Things that require faster reaction can be done in the base thread on parallel port/GPIO systems
or in hardware on systems with smart interface hardware.

The RT threads should be created from shortest to longest in multiples of the shortest. Is that because the free time between when thread ends its work and time when deterministic constraints would expire is used to schedule and execute another RT thread? The thing I don't really understand is that if some thread is running perpetually and deterministically if there is no downtime it really should fill the whole processor core up, right? But I really want the servo thread to run (or to start) every 1ms, even if it only runs for 0,3ms.

AFAIK this is because the slower threads are dispatched by dividing the faster threads, so they are always run at multiples
of the faster thread period.

Threads are scheduled at particular times and run to completion. Once all threads are done running hal functions,
LinuxCNCs real time portion is idle until the next scheduled thread invocation. So if you have a 1 ms servo thread
seup, it will run to completion and then the real time portion of LinuxCNC will be idle until the next thread invocation (1 ms after the previous one)

the System itself is Designed to go for BIG BIG Servo mashines
with up to 50000 Steps or Pulses per mm at very high speed
so not considering a low level like Windoes Mach3 uses 6Milion Jitter per step

a Realtime kernal is the only way to get full controll acces without woriing

OLD IBM DOS like Heidenhein TNC <250 have a 8Mhz chip only diong realtine no grapgics at all

Thank you for responses.

Yes, the typical minimum response time is one thread period. In systems with hardware beyond just a parallel port that have only a servo thread, the servo thread period will determine the response time to external events. I'm not sure about the software stepgen,
but the hardware stepgens I'm aware of do not implement acceleration so the pulse rate will be the same between updates. Note that
at 1 KHz, the actual chord error between the piecewise linear motion and actual profile caused by this stepped velocity is unimportant (in the 1 u region) unless you have a combined need for high accuracy and very high acceleration (laser plotters for example) This also applies to analog outputs. Things that require faster reaction can be done in the base thread on parallel port/GPIO systems
or in hardware on systems with smart interface hardware.

So, if I understand correctly there is no guarantee that the actual output value (for example voltage from DAC or pulse train) will actually run for 1 ms, i.e. thread run code will query the inputs (counter register and so on), do the math and then write outputs (write to other registers for example in remote hardware) but the code itself is not (cannot be) periodical (in harmonic sense)? There will always be some kind of error between computed command and command which is actually needed because there can be action (motion) which happened in the time of computing.

the System itself is Designed to go for BIG BIG Servo mashines
with up to 50000 Steps or Pulses per mm at very high speed
so not considering a low level like Windoes Mach3 uses 6Milion Jitter per step

a Realtime kernal is the only way to get full controll acces without woriing

OLD IBM DOS like Heidenhein TNC <250 have a 8Mhz chip only diong realtine no grapgics at all

I have to say that I have no idea what you are talking about. As I see no pertinence didn't you post to the wrong thread by mistake?

Historically (with RTAI) all the real-time modules ran as kernel modules. Linux kernel modules can only be written in C, so the real-time parts of LinuxCNC are written in C.

I don't know if this limitation exists with preempt-rt.

Ah, OK. Guess I will have to try it. I have been extra cautious when playing to use C when everything in the vicinity looked like C and it has been painful for me.

So, if I understand correctly there is no guarantee that the actual output value (for example voltage from DAC or pulse train) will actually run for 1 ms, i.e. thread run code will query the inputs (counter register and so on), do the math and then write outputs (write to other registers for example in remote hardware) but the code itself is not (cannot be) periodical (in harmonic sense)? There will always be some kind of error between computed command and command which is actually needed because there can be action (motion) which happened in the time of computing.

The code _is_ run periodically to completion, It will exhibit jitter on both the read and write parts. Typically the jitter on read and writes is less than 100 usec so times from read-read and write-write might be from 900 to 1100 usec. Some hardware (At least Mesa and Ethercat) can implement a DPLL to re-time critical operations like reading encoders or stepgen position counts to reduce sampling jitter to the 10s to 100s of ns.