Timergenauigkeit
-
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/
-
ten schrieb:
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/
und schlechte Bioroboter benutzen auch CANbus http://www.sias.biz/products.htm
-
THX 1138 schrieb:
ten schrieb:
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/
und schlechte Bioroboter benutzen auch CANbus http://www.sias.biz/products.htm
der bus ist doch nicht schlecht, etwas empfindlich wenn die baudrate nicht genau stimmt, aber gut echtzeitfähig (um nicht ganz vom thema abzuweichen
)
...aber CAN ist nur ist nur der 'link layer' für CANOpen.
CANOpen ist für CAN in etwa das gleiche, was 'HTTP' für 'IP' ist
-
ten schrieb:
der bus ist doch nicht schlecht, etwas empfindlich wenn die baudrate nicht genau stimmt, aber gut echtzeitfähig (um nicht ganz vom thema abzuweichen
)
...aber CAN ist nur ist nur der 'link layer' für CANOpen.
CANOpen ist für CAN in etwa das gleiche, was 'HTTP' für 'IP' istSagte auch nicht das der Bus schlecht ist, sondern das Gerät und die Software
Stürtzt dauernd ab, und dann bleibt was auf dem Bus hängen und ich darf ihn dann erst mal mit PCAN abschiessen.
Unsere ersten Roboter waren Marke Eigenbau mit SPSen (oh man waren die grottig), die neueren, guten haben wohl μC und Windows-Anbindung per RS232, keine Ahnung ob mit C oder was anderem, sind eingekauft.
-
THX 1138 schrieb:
Stürtzt dauernd ab, und dann bleibt was auf dem Bus hängen und ich darf ihn dann erst mal mit PCAN abschiessen.
das hab' ich noch nie gehört, dass etwas den ganzen bus blockiert
vielleicht ist der transceiver-chip kaputt und zieht den bus auf 0 ?
aber ich weiss ja nicht, was ihr da merkwürdiges gebastelt habt
-
ten schrieb:
das hab' ich noch nie gehört, dass etwas den ganzen bus blockiert
vielleicht ist der transceiver-chip kaputt und zieht den bus auf 0 ?
aber ich weiss ja nicht, was ihr da merkwürdiges gebastelt habtIch hab gar nichts gebastelt
Das waren die von Sios. Die Software ist einfach Müll. Die Datenbanken gehn dauern korrupt, die GUI stürtzt ab, Methoden und Decklayouts verschwinden ins Nirvana. Ein Horror damit zu arbeiten.