Real-time programming: which OS
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
Standard desktop/server Linux distributions don't give any guarantees on scheduling latency, you would need one of the real-time enhanced versions for deterministic sub-millisecond scheduling. I suppose that proving and documenting your system's performance would be easier with the complete source code to the underlying OS available.
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). And much simpler to get working also. So stick with a dedicated real-time OS for the job. Have a look at UC/OS-II (http://www.ucos-ii.com)
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
Joseph M. Newcomer wrote an article bout that on this Site (maybe you didn't check it out till now): http://www.codeproject.com/system/simpletime.asp (it say that there are some real - time enhancements for windows nt) Hope this helps you a little bit Bernhard "Politicians and diapers have one thing in common. They should both be changed regularly and for the same reason."
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
Take a look at VenturCom. Their RTX product is a so-called real-time extension to Windows NT. They use a modified HAL which catches interrupts before NT gets a chance to process them. This way, deterministic interrupt response times can be guaranteed. A real time "RTX API" is provided to access a bunch of real-time primitives. I've used RTX in a large project at my previous employer and it worked quite well. A big plus was that you could compile, run and debug your program under NT entirely (except for the hard real-time aspects of course), and then simply recompile and run on RTX to get real-time deterministic behaviour. Sito Dekker
-
Take a look at VenturCom. Their RTX product is a so-called real-time extension to Windows NT. They use a modified HAL which catches interrupts before NT gets a chance to process them. This way, deterministic interrupt response times can be guaranteed. A real time "RTX API" is provided to access a bunch of real-time primitives. I've used RTX in a large project at my previous employer and it worked quite well. A big plus was that you could compile, run and debug your program under NT entirely (except for the hard real-time aspects of course), and then simply recompile and run on RTX to get real-time deterministic behaviour. Sito Dekker
I would agree with this suggestion. I have seen this successfully implemented in complex situations that require determinism. Given your time constraints (from the sound of the project, I don't think it will add a significant amount of $$ to the total cost), this will probably be the best route. Mike
-
I am working on an active vibration-suppression subsystem for a large X-ray system. I need to reliably read sensors, do signal-processing, and generate output waveforms for the actuators with a 40-Hz loop bandwidth (I am trying to compensate for 10-micron vibrations of a 2-ton steel vacuum tank when people walk on the floor). To do this with acceptable phase-lag, I need to know that my system will have no latency greater than 500 microseconds. Disk access will not be necessary, as I can fit all the code and data I need in main RAM. I am prototyping on WinNT 4.0, with networking and most other non-essential services turned off. The senior person on the project is pushing me to look at Linux, claiming that Linux can easily be configured to be better suited to real-time systems. There are also real commercial RTOSes, such as QNX. The number one consideration is that I need to get things working yesterday, so I will be trading off needing to learn the details of task scheduling and switching under NT versus learning almost all of Linux or whatever other OS I choose, with which I have little experience. If I can do this under NT, I would like to leverage my knowledge of Windows and my general aesthetic preference for this OS, but if it will turn out to be impossible to achieve 500 microsecond latency under Windows, I would rather learn this up front and bite the Linux bullet. Ultimately, this will become part of a medical device, so the real-time performance will need to be documented for the FDA (for those outside Osama's target zone, that's the U.S. Food and Drug Administration). Microsoft is excellent about documenting the Windows API, but I don't find enough documentation on the system internals, as relates to deterministic response. Will it be possible to find the information I need to ensure that this system will be reliable? Has anyone else here gone through FDA certification of a Win32-based system? Fortunately, the vibrations only hurt system performance. If the subsystem misbehaves, it will not kill anyone. It will only decrease the efficiency and reliability of the x-ray system and kill our bottom line. I am using National Instruments hardware to do the DAQ and control stuff. The target platform is a 120 MHz Pentium with 64 MB RAM, NT 4.0 SP6a, which will be dedicated solely to this control application (we believe that multiple cheap PCs, each running a single task is far more reliable than a single expensive PC multitasking). Based on this hardware, I invite you to guess how I responded to the "H
You can not use Windows NT in a 'real-time' environment because it is not possible to be completely deterministic. You would have a hard time getting it past the FDA anyway as how would you go about validating it? There is 'Embedded NT' which is a real time NT that allows you to completely build the kernal to only use those things you require. If you are determined to use the NT API this would probably be the best compromise. The best solution would be to embed it. Such a task does not really require an O.S. Not the view of my employer