Real Time Windows - How is it done? C#/C++

Question

5.00/5 (1 vote)

See more:

Generally searching for information on how to obtain real time or near real time control generally is dismissed as not possible using Windows.

However over the years I have run into a few examples that contradict this viewpoint:
GMFC Foam Cutting Software[^]

And more recently:
http://www.tenasys.com/tenasys-products/intime-rtos-family/intime-for-windows[^]

I am sure from what I have read that doing something similar to the above is not possible with C# but I believe the above (at least GMFC) is written in C/C++

In C# I have tried to set the thread priority to the highest I can and from testing on my rig I end up with 200-300ms delays that I can somewhat reliably reproduce.

For C++ it looks like the thread priority can be so high that it will start to interfere with the internal OS operation and hard drive reads/writes may not be performed.

Is there any examples on programming tasks in windows that require sub ms (Or even 1ms) control while still allowing for error free operation (allocating some time slices as required so the OS can do its necessary background tasks)?

For example how would you write software in Windows to control a stepper motor using a parallel port in a similar fashion to GMFC? From what I can remember while it was running a cut the computer would be unusable. The GMFC dialog would update statistics but you would not be able to use any keyboard or mouse to do anyhthing.

Not looking for specific source code examples (unless this is available in OSS or exmaples) but more for what the strategy would be (IE is it just a C++ application with thread priority on highest setting manually releasing time slices back to the OS for housekeeping?)

Posted 12-Jan-15 6:18am

GPIB1

Add a Solution

4 solutions

Solution 1

Once and for all: Windows isnt a real time operating system. ;-)

A good overlook about timers on Windows. Some new on Timers on Windows 8.1. (even for me)

A fine tutorial. I suggest you stick to High-Resolution Timer.

Posted 12-Jan-15 6:27am

KarstenK

Comments

Sergey Alexandrovich Kryukov 12-Jan-15 14:45pm

Agree, 5ed. There is a bit more to it: please see my Solution 4.
—SA

GPIB1 12-Jan-15 16:28pm

I agree with the statement, was looking for as real time as possible. I was basing the question on observation of a "real-time" stepper motor control software that was appearing to actually send signals in a very deterministic way with very short periods between signals (0.5ms as I now found out)

GPIB1 12-Jan-15 17:23pm

What about the InTime link, it says it is a full RTOS for windows and is "hard real-time"

The mechanism they are using to do that is what is interesting, but should be impossible from what I am reading otherwise.

Aescleal 12-Jan-15 23:07pm

intime is apparently pretty good - the company I work for used it but wrote their own solution for a limited subset of hardware to cut out the licensing fees. Caveat: I don't have any experience of it, just the code that replaced it!

GPIB1 13-Jan-15 9:13am

Thanks for the insight, so from your responses it sounds like your replacement used the device driver route, and intime uses the same mechanism? It sounds like even though the driver does the real time stuff that there is always uncertainty as soon as you cross back over into the windows OS, there is no guarantee that the decisions made and batched in the application will make it to the driver in a deterministic time (or will it, audio and video applications would have to have ways to mitigate this or there would be chop)

Aescleal 13-Jan-15 9:37am

We batch a large chunk of commands and then (a bit naughtily) do almost everything in the device driver's interrupt handler in page-locked memory. The turn around is very quick and we've never lost data because of it.

Video and audio drivers work batch a large chunk of data to be rendered and do the display/playback by passing the data off to dedicated co-processors so they don't have to quite as cavalier with windows architecture.

Solution 4

In addition to other answers:

In addition to the statement of Solution 3 (about not having "hard" real time): Windows does not even provide "soft" real-time. It's not real-time at all. I would formulate it in the following way: for each fixed latency value, there is some non-zero probability of getting slower response. No matter that this probability can be very low for long latency values, it still contradicts to the real-time requirements. Note that there are many other pieced of technology with the same property contradicting to real-time: one well-known element is Ethernet.

Years ago, I saw some information on real-time Windows version, or specification for such project, but presently I cannot see a trace of it.

I must note that much of controversy here stems from different and inconsistent use of the term "real-time" in different field of knowledge. For example, the ability to show video without pauses often also called "real time", as well as, almost ridiculously, the interactive operation over internet, such as in chats with server push or peer-to-peer. All those terms are no fundamental; and I would advise to avoid them to prevent confusions.

—SA

Posted 12-Jan-15 8:40am

Sergey Alexandrovich Kryukov

Updated 12-Jan-15 8:44am

v2

Comments

GPIB1 12-Jan-15 16:40pm

Agree about the controversy, but not sure what better phrase describes "real time as in decode video, synthesize audio, or control as in GMFC stepper motors without any skipping, jitter, etc"

There may not be real-time in Windows by definition but there is a way to write software as observed, it ran for hours without missing a beat or being able to notice any adverse/jittery operation. IIRC it did load the CPU/Windows to the point where the UI was not responsive, but it did still allow you to escape out with a key press.

Sergey Alexandrovich Kryukov 12-Jan-15 16:46pm

Well, it depends on what you are doing. If windows handling is inside the feedback loop, you always have a chance, maybe a little change, to miss something. The problem is typically solved by having a separate real-time device. For example, servo systems are such devices. The biggest problem is that industrial hardware manufacturers lost the skills of working with interrupts since NT (not just protected mode, but also page virtual memory and process isolation); and it provokes the use of pull technology (instead of push), which translates into waste of performance, at best.
—SA

Solution 2

Found this in addition:
http://www.windowstimestamp.com/[^]

"Windows isnt a real time operating system" is the default, by-the-book, spec response. I know, we know, most every question repsonse just says this and then it is left as is.

I know windows isn't capable of real-hard-time scheduling like is found in a RTOS running on a micro.

However, the GMFC linked above is able to run on my 5+ year old Windows XP laptop and run in a sufficiently real time manner to accurately control stepper motors in a smooth way. (This is required since if the control signals between steps varied by a large amount there would be defects in the cut foam line as the heated wire lingers longer on some areas more than others, and this there is not) When microstepping and requiring hundreds if not thousands of steps to move an inch you need to have a very short time interval between steps.

So my question is more how would you achieve the above performance similar to GMFC given that:
- It is possible to be able to achieve highly repeatable sub ms / ms time intervals, see example software

Posted 12-Jan-15 6:43am

GPIB1

Comments

Sergey Alexandrovich Kryukov 12-Jan-15 14:49pm

Well, this high-resolution time stamping has nothing to do with real time. Generally, "real-time" and different flavors of the original notion, is not about any particular time resolution and not even about particular time of response of the system. It's about the level of guarantees of the maximum time of the response. In essence, it is about the probability of missing some external asynchronous events (or guarantees not to miss them). Can you see the difference? (Your CodeProject ID suggests that you have some reasons to be familiar with this stuff, colleague. :-)
See also Solution 4.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Aescleal · Accepted Answer · 2015-01-12T06:58:00

Solution 3

For hard real-time or near hard real-time control you'll probably have to write a device driver to get the response you want. Your driver will take a sequence of commands and the times you want them executed for through IOCTRL. You'll do everything that needs real time control in the driver which can run at just below interrupt priority and give you full access to the hardware.

So if you want to know how to do it go and grab a copy of the Windows DDK (device drive development kit) from Microsoft, learn a bit about the way drivers work and how they interact with windows and get coding!

Posted 12-Jan-15 6:58am

Aescleal

Comments

Sergey Alexandrovich Kryukov 12-Jan-15 14:40pm

Windows does not even provide "soft" real-time. Please see also my answer (Solution 4).
—SA

Aescleal 12-Jan-15 16:28pm

Out of the box it doesn't provide any real time facilities, but if you're willing to dive in at the device driver level you can handle the events you're interested with a maximum latency.

Sergey Alexandrovich Kryukov 12-Jan-15 16:39pm

True, but it does not make the system real-time. Good point about driver level though. Roughly speaking, you can guarantee primary handling of some events from some hardware in terms of latency, unless you do something else: store events in a common-use drive, show graph on screen, and so on. Then you can boost priority and, depending on some factors, still approach "rear real-time", but without the level of guarantee implied by the term "real-time". It can even be good in practice. For serious real-time, it would be better to use some back-end non-windows device, even the signal-processing board, or something...
—SA

GPIB1 12-Jan-15 16:55pm

As long as windows is in the loop to interactively generate and send the data to the external device there could still be issues though? In most applications that I am looking at there needs to be a certain amount of coordination between anything external and real time and the software running on Windows.

For example using AutoCAD and its API to handle 3D point clouds and then driving some actuators based on this data (for arguments sake lets say some arbitrary control of a hot wire foam cutter in some bizarre display of art) I don't think that it would be reasonable to engineer an entire real time system that has the capabilities of AutoCAD included in it.

I know you can process the data on the Windows computer and then export/load it into the external real time system to process all at once. There are still cases though like what if the data was coming in "live" over the IoT that everyone is raving about.

This would have to be done carefully though to ensure that enough resources are available to meet your desired timing (more or less since it is not real time by definition) but this is not much different than a micro that is using a super loop without any RTOS.

It sounds like using a device driver is a way to get closer to the desired operation since it can have much greater control over the lower level timing.

This has to be similar to how games are constructed? I don't ever remember playing a game and hitting a direction key and having a random varying half a second delay before hitting the key and seeing a response. That is unless I set the frame rate/resolution way to high for the capacity of the system (which is the same scenario that I looking at except instead of a loop running as fast as possible it would be one that can be triggered every .5ms like the GMFC stuff....)

Sergey Alexandrovich Kryukov 12-Jan-15 17:06pm

Exactly, and that's the problem. If you just move the actuator into a certain point, it's not a problem if it arrives a bit sooner or later. But imagine what happens if you do laser machining and draw a line on the processes material while moving. Say, the straight line between two points may come out curved, due to timing. Some servo system provide coordinated modes, but imagine what happens if you want have two independent degrees of freedom of your stage (a stage with two or more separate stage actuators controlled independently). If you try to synchronize the motion along X and Y in windows code in the loop, you can miss uneven timing on each intermediate points, or you can try to coordinate the motion on the fly. This is where you can fail due to lack of real time behavior. Windows is just not suitable for such things: you have to find more advanced motion system where some of the degrees of freedom are synchronized autonomously from main control computer (Windows)...
(Of course, moving by small steps to a full stop in each intermediate point can give required accuracy, but it would completely defeat the purpose. Set aside killed performance, there laser should emit its average per-pulse power. If you go slowly, it will burn the thing :-)
—SA

Aescleal 12-Jan-15 23:17pm

You use the device driver to replace the real time OS. Your main app makes the decisions, the device driver carries them out in a timely fashion. Generally you batch or script the decisions and pass them to the driver in one fell swoop so you don't have to flit in and out of user mode - you do far more in the driver's interrupt handler than would normally be tasteful, Presumably that's why your foam cutter software locks up the system when its doing its thing.

GPIB1 12-Jan-15 16:31pm

I think this is the closest way that I can achieve what I want. After reviewing the software/hardware that I used years ago (GMFC) it turns out that there is a 2kHz signal that is generated on external hardware and this is used to send interrupts through the parallel port. So I think based on what I know now that it was actually using a hardware driver mechanism.