FAQ

Yes, our real-time drivers - in general, all our installation and application files - are already signed. Especially, for 64 bit systems this is compulsory required to use the software correctly. However, a signed driver shows reliability.

That implies also that our software can simply used as a driver for your PCI/PCIe or USB device. For this reason, the included INF files have to be upgraded by an entry on the documented way. This is even needed to address hardware safely on every system.

Yes, the »RealTime Suite« included a C# class, which supported by the API. By this class it is possible to activate the entire range of functions with a C# application.

However, parts of the program, which contains real-time capable code, have to be embedded and swapped in a DLL with native machine code (x86 or x64) or Delphi.

In order to keep this stage of development as simple as possible we deliver a project template, which shows how does it work. This project file can used immediately for own developments.

Windows itself is not a real-time system. In order to achieve real-time features, it is necessary to execute time-critical code in a real-time context (at kernel level).

Due to the fact that in a .NET environment C# can not be executed in real-time, the behvior in time still depends on the Windows scheduler. Thus, it is possible to assign the time-critical C# threads the absolute highest thread priority. Previously this was not possible for programmers. For this reason, Kithara provides the respective mechanisms.  At least, the mechanisms can ensure that the application takes priority over all other Windows applications.

For true real-time behavior the essential code should be programmed in C++ and swapped in a DLL file, so that it can be loaded directly in the real-time context.

For communication between application and real-time context shared memory, data or messages pipes, events, or sockets are available. A number of examples projects are included to show how "hard" real-time can be embedded in C# applications.

As long as no other real-time software or similar system-critical software is installed,  (almost) nothing exists, which interrupts or delays the real-time task except:

- CLI = general interrupt blocked through Windows and drivers

(unfortunately, no software can do something against it; However, in Windows the blocking time is limited and almost the driver is responsible for this; in this case the respective driver has to be replaced; it is difficult to determine it, thus only possible by our support (in return of payment).

- WBINVD command to flush the entire internal cache

(according to experience, only by using Nvidia graphic drivers; only by replacement of the card with an ATI (AMD) the problem can be solved)

- C1E = Enhanced Power Save Mode of the CPU

(especially, the overdeveloped Intel CPUSs (i7, Xeon, ...) turns into the idle mode after short breaks, so that the wake up after a timer interrupt can take several milliseconds; that can be switched of in the BIOS (see CIE or similar) or the PC is not real-time capable.

Ordinary Windows activities cannot replace real-time task. Windows has the priority 1, whereas the RealTime tasks have the priorities from 1 to 255. DPC has no influence.

To achieve the goal to improve the real-time behavior, only the Dedicated Mode, which supports the exclusive use of single CPU cores in real-time. Without Windows influence the maximum jitter is less than < 1 us.

Yes. However, Windows 8 x64 has the so called 'Kernel Patch Protection' in order to restrain access to the OS. Thus, the code execution of real-time tasks on CPU cores, which are also used by Windows, is not possible.

Nevertheless, by using the Dedicated Module it is possible to keep single or multi CPU cores free by the Windows OS (further information). In this case, the Kithara real-time system is booted exclusively on the respective CPUs. That enables real-time on a Windows 8 x64 systems with the best real-time features.

If a shared real-time operation is desired, we recommend you to either us a Windows 7 x64 or a Windows x32 system. Thereby you have not any restrictions.

We distinguish 3 different versions:

1. 32 bit applications on a 32 bit Windows
2. (like  1 and additionally) 64 bit application on a 64 bit Windows
3. (like  2 and additionally) 32 bit applications on a 64 bit Windows

The software supports usually 32 bit application on a 32 bit Windows. Besides, to run 64 bit application on a 64 bit Windows, an extension to 64 bit functions is necessary. If 32 bit applications should run on a 64 bit Windows, the so called “KiK64” (Kithara32-in-Kithara64) is required. Thus, the KiK64 enables by only one 32 bit application all Windows systems ( 32 and 64 bit).

But at comprehensive and challenging projects it should be noted that often a conversion between 32 and 64 bit addresses (code and data) takes place. For a better runtime it is recommend running only native 64 bit applications on a 64 bit system.

If you have any questions concerning this topic, feel free to contact us.

Windwos XP was the last version, which supported the execution of DOS applications.  In so far there is no solution at all for further support of such old programs. As long as the source code is available the only opportunity is to port (rewrite) the program as a new 32 or 64 bit application. However, for this reason hardware-dependent access mechanisms are necessary, which Windows (in contrary to the former DOS) itself does not provide. Considering that, our »RealTime Suite« is very well suited. Windows (e.g. Win 7) in 32 or 64 bit and our »RealTime Suite« combined together result similar or essential further opportunities for hardware-dependent programming.

The »RealTime Suite« itself is composed modularly and at the moment consists of 20 differen function modules, e.g. for real-time programming, automation with CANopen^® or EtherCAT^®as well as real-time processing with GigE Vision^® and a complete soft SPS according to IEC 61131-3. The method of programming provides the ideal requirements for porting existing applications.

No, currently due the following reasons:

1. The limited and fixed USB cycle of 1 ms frustrate a higher data transfer frequency.
2. There are no real-time protocols for USB (the bulk mode ensures the complete data transfer, but without an assurance of a transfer rate; the isochron mode at least a specific minimum transfer rate, but parts of the data packages can be missing.
3. The implementation is currently based internally on Windows mechanisms, which do not support real-time, so that even 1 ms is not ensured.
4. Data transfer with other devices (keyboard, mouse etc.) frustrate real-time.

We are working on supporting USB 3 in the future by using a special USB plug-in card. Thereby, within the framework of the USB protocol real-time capabilities will be achieved.

"More specified than a specified event is not possible"

If a KS_setEvent selected again, eventually the already selected event still persists (1x). The reaction to that depends on, whether the event is a "auto reset" (default) or a "manual reset" ( by KSF_MANUAL_RESET at KS_createEvent) event.

At a "auto reset" event at most one waiting thread is released and in the case of the release, the event is subsequently reset automatically. A "manual reset" event remains as long as it is reset by KS_resetEvent. Thus, it is also possible to release several waiting threads. The "manual reset" event is like a gate, which after specification let pass any number of threads until the gate is closed again.