Timergenauigkeit
-
ICh hab so ein ähnliches Problem, nur steh ich noch was weiter am Anfang.
Ich Brauche einen Timer, der genauer als der WM_TIMER ist, da ich einen Schrittmotor ansteuern will.
Ich will/wollte einen Multimediatimer nehmen, aber hänge etwas bei der initialisierung und dem allgemeinen Gebrauch fest (also wo ich was einbetten muss, damit er läuft). Kann mir da einer Weiterhelfen?
Ich brauch keine Echtzeit sondern einen eine aufösung <20ms.
-
Was ist bei "timeSetEvent" unklar?
-
unklar ist mir, WO ich das einstzen muss. Als extra Funktion oder als Event beim z.b. Buttenklick oder als teil der normalen Timerfunktion. Das ist mein Problem.
hab zu dem Thema leider keine Bsp. gefunden. Sons würde ich ja nicht fragen...
-
Kann man auf RTX windows stinknormale Anwendung welche in MFC programmiert wurden laufen lassen? oder sind da andere Biblotheken erforderlich? grüße
-
@BorisDieKlinge: RTX Windows sit ein "Aufsatz" (besser Untersatz) für Windows. Dein Windows bleibt ganz normal erhalten. Auch laufen da alle Anwenungen ganz normal. Nur unter dem Windows läuft das RTX und wenn Du die RTX-API verwendest, kannst Du da auch Echtzeit-Tasks laufen lassen. Aber natürlich nur unter verwendung der RTX-API; hat nix mit WinAPI zu tun!
@Uruk-h4j: Wenn Du den Timer bruachst, dann startest Du ihn mit der Funktion und wenn nicht mehr dann löscht Du ihn wieder mit timeKillEvent
-
schon mal mit der RTX api gecodet... d.h. normal anwendunge welche nicht unter der RTX API gecodet wurden können nich in echtzeit ausgeführt werden?
-
BorisDieKlinge schrieb:
schon mal mit der RTX api gecodet
Nicht produktiv....
BorisDieKlinge schrieb:
normale anwendungen welche nicht unter der RTX API gecodet wurden können nich in echtzeit ausgeführt werden?
Nein, natürlich nicht. WIe sollten sie denn auch? *Windows* wird ja durch den RTX-Kern *nicht* Echtzeitfähig! sondern nur RTX ist echtzeitfähig!
-
es ist ja sogar eher nachteilig für normale windows-programme, denn eine RTX task bekommt die rechenzeit auf jeden fall, windows zieht dabei immer den kürzeren...
-
hmm ok... ich denke mal das RTX nicht unbedingt groß verwendet wird bzw. verbreitet ist. wird die API nicht unbedingt umpfangreich sein oder (verglichen mit der MFC)
-
BorisDieKlinge schrieb:
hmm ok... ich denke mal das RTX nicht unbedingt groß verwendet wird bzw. verbreitet ist.
richtig. ist auch irgendwie doof, sowas mit 'nem pc zu machen, auf dem schon windows rumeiert. lieber eine externe schaltung mit einem microcontroller o.ä. dranstöpseln und schon haste echtzeit. das ist so ganz nebenbei auch noch viel kostengünstiger als eine RTX lizenz...
-
naja um komplexe echtzeitsteurugne zu coden.. ist C/c++ sicherlich angenehmer als SPS...
-
BorisDieKlinge schrieb:
naja um komplexe echtzeitsteurugne zu coden.. ist C/c++ sicherlich angenehmer als SPS...
wieso sps?
µCs werden für gewöhnlich in C programmiert. c++ ist auch möglich.
damit hat man echtzeit ohne den ballast eines betriebssystems.
und falls man doch ein OS braucht --> http://www.freertos.org/
kostet nix
dagegen, eine freie RTX für windows hab' ich noch nie gesehen
-
ja es geht darum... steuerung komplexer maschinen von SPS auf C/C++ abzusplitten..
das komplexere berechnungen via C++ gmeacht werden, und die eigentlich steurung noch in SPS und zwischen SPS und windows sollt dann eine schnittstelle verwendet werden.. und dafür ist nunmal nur RTX geeigent oder
-
BorisDieKlinge schrieb:
ja es geht darum... steuerung komplexer maschinen von SPS auf C/C++ abzusplitten..
das komplexere berechnungen via C++ gmeacht werden, und die eigentlich steurung noch in SPS und zwischen SPS und windows sollt dann eine schnittstelle verwendet werden.. und dafür ist nunmal nur RTX geeigent oder
willst du die SPS nur noch als I/O modul verwenden oder wie?
naja, du hast jedenfalls die möglichkeiten alles was echtzeitfähig sein muss, in einen µC oder in die SPS packen, oder eine RTX benutzen.
musste irgendwie abwägen zwischen kosten, betriebssicherheit usw...
PCs stürzen auch gerne mal ab, industrietaugliche PCs sind auch ziemlich teuer, eine RTX ist teuer...
-
ja das weis ich noch nich genau.. bin darin noch nich richtig wissend... anscheinend gibts es solche art SPS module welche schon in C programmiert werden können..
-
BorisDieKlinge schrieb:
anscheinend gibts es solche art SPS module welche schon in C programmiert werden können..
umgekehrt auch
--> http://www.mikrocontroller.net/topic/12192
-
BorisDieKlinge schrieb:
und zwischen SPS und windows sollt dann eine schnittstelle verwendet werden.. und dafür ist nunmal nur RTX geeigent oder
Nanana... das stimmt ja überhaupt nicht.
DIe Schnittstelle zwischen "Logischer Steuerung" und "Echtzeitsteuerung via SPS" ist und bleibt OPC.Und SPSen programmiert man i.d.R. nicht in C sondern in KOP oder ST.
-
Jochen Kalmbach schrieb:
DIe Schnittstelle zwischen "Logischer Steuerung" und "Echtzeitsteuerung via SPS" ist und bleibt OPC.
ich dachte immer die automatisierungsfritzen benutzen alle CANOpen...
-
ten schrieb:
Jochen Kalmbach schrieb:
DIe Schnittstelle zwischen "Logischer Steuerung" und "Echtzeitsteuerung via SPS" ist und bleibt OPC.
ich dachte immer die automatisierungsfritzen benutzen alle CANOpen...
Nein, nur die "Automobilfritzen"...
-
Jochen Kalmbach schrieb:
ich dachte immer die automatisierungsfritzen benutzen alle CANOpen...
Nein, nur die "Automobilfritzen"...
nicht nur. guckst du: http://www.can-cia.org/canopen/