Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

RTC - RealTimeClock in Industrie-PC's

ESX(i)-taugliche Hardware, HCL .....

Moderatoren: irix, Dayworker

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

RTC - RealTimeClock in Industrie-PC's

Beitragvon UrsDerBär » 14.01.2014, 12:17

Hallo Leute,

Was ist damit gemeint wenn bei Industrie-PC's von Real Time Clocks die Rede ist? Das hat doch jeder PC? Gibt es da spezielle Versionen oder haben die gar eigene Chips?

Also Beispiel: Industrie-Anzeigegeräte mit HMI-Oberfläche

Hintergrund:
- Diese Dinge steuern sauteure Maschinen
- Die CPU's sind so gut wie nie Xeons
- Die Teile haben so gut wie nie ein richtiges RAID, in seltenen Fällen Software
- Die verbauten bewegten Teile sind selten wie nie wirklich 24h tauglich von den Specs her
- Die Rechenleistung ist oftmals wirklich klein, eine Teamviewer-Sitzung frisst gerne 50% der Leistung, 5-20 eine moderne HMI-Oberfläche. Läuft noch andere Software, schmiert irgendwann die HMI-Oberfläche quasi ab, weil sie zuwenig Leistung bekommt

Irgendwie kringeln sich mir die Zehennägel auf, wenn ich im IT-Bereich alles auf Ausfallsicherheit lege, die Maschinen aber teilweise mit Konfigurationen laufen, die man im Privatsektor verwendet (Festplatten).

Auch bin ich mit der Nutzung der Hersteller-Plattformen an deren Geräte gebunden. Die Software läuft dann jeweils gar nicht auf anderen Plattformen. Ein schneller Ersatz ist also nur bei Vorhaltung eines identischen Displays möglich.

Argumente der Maschinen-Hersteller:
- Die Teile bieten eine Real Time Clock
- Direkte Programmierung von Controllern etc.
- Diese Panel-Anbieter bieten eine HMI-Programmierumgebung welche die Programmierung vereinfacht, meiner Meinung nach aber auch einschränkt


Wie seht ihr das? Was sind die Möglichkeiten wenn z.B. der Hardware-Hersteller das gewünschte gar nicht anbietet, die Software aber bereits programmiert ist?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 14.01.2014, 16:39

Mit "Real Time Clock" muß hier die Echtzeitfähigkeit gemeint sein. Die ist zum einen notwendig, damit der Kernel von Windows und Linux/Unix nicht mit der Abfrage und Bearbeitung von Interrupts rumtrödelt, wie es bei Linux/Unix und Windows zum Stromsparen der Fall ist und zum anderen lag zu Zeiten von WinNT die interne Timerauflösung noch bei 10ms. Beide Betriebssystemwelten können ohne weitere Vorkehrung auch nicht die Interrupt-Abarbeitung garantieren und zumindest bei Windows kommt noch hinzu, daß dort Prioritäten dynamisch zur Laufzeit geändert werden, um eine gleichmässigere Verteilung der verfügbaren Prozessorzeit zu erreichen.

Die Timerauflösung von Linux und Windows hat sich ja inzwischen deutlich verbessert. Ohne diese wären die tiefen Schlafmodi heutiger CPUs weder denk- noch realisierbar. Denn wenn die interne Timerauflösung bereits "lange" 10ms hat und die CPU nur zum Aufwachen dieselbe Zeit braucht, kann sich die CPU ja nie schlafenlegen. Der Timer würde ja nie wissen, ob die CPU schon bzw noch schläft oder auf dem Wege dahin ist.

Sieh dir in diesem Zusammenhang auch mal die Eignung handelsüblicher PCs für den Einsatz als DAW (Digital Audio Workstation) an. Selbst mit passenden ASIO-Treibern für die Sound-HW bekommst du die damit erzielbaren Latenzen, trotz einer höheren CPU-Belastung, manchmal nicht soweit gedrückt, das zwischen Tastendruck und Tonausgabe nachher keine Pause zu hören ist. Selbst die normale Videobearbeitung/-streaming/-wiedergabe wäre auch noch ein Beispiel. Sobald dort Bild und Ton mehr als +/-40ms auseinanderdriften, ist dieser Versatz auch für ungeübte Augen sichtbar.


Damit man diese Latenzen in Griff bekommt, müssen also entweder das OS selbst (Kernel) oder wie bei der Virtualisierung möglichst tief ansetzende Kerneleinsprungspunkte genutzt werden. Je nach maximal zulässiger Latenz, reicht das dann wie bei CNC-Maschinen trotzdem nicht aus und kann nur durch Eigenprogrammierung überwunden werden. Sobald die Frage nach möglicher Haftung oder sogar Regress auftaucht, kommen dann meist Eigenkreationen zum Einsatz. Die Pflege dieser Sourcen nebst Bugfixing und Anpassung an neue Maschinen bzw gesunkene Latenzen kostet halt Geld und das lassen sich alle Hersteller fürstlich bezahlen. Ich schätze mal mehr als 80 Prozent gehen allein nur an SW- und Entwicklungskosten drauf, den kläglichen Rest dürften dann Material und Aufbau bilden.

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 25.01.2014, 16:14

Ohhhhhhaaalätz, Antwort gar nie abeschickt. Sorry :D

Danke für den technischen Hintergrund.


Mittlerweile habe ich auch Infos aus erster Hand. Echtzeit-Clock ist tatsächlich nur BlaBla. Ist nix anderes als jeder PC hat. Aber: Es klinge gut in Ohren von SPS-Programmierer wenn die Echtzeit-CPU hören.

- Die Desktop-Plattformen sind billiger zu fertigen für eigene Produke.
- Sie werden selten bis nie nach Serverplattformen gefragt, weil die Leute die das entscheiden, selten Ahnung von Computer haben.
- Manche Hersteller bieten eine gesonderte Lizenz für den Betrieb auf einer "Markenfremden" Maschine.

Bis jetzt habe ich einen wirklich modernen Steuerungs-Hersteller gefunden. Da lassen sich die ganzen Echtzeit und Input/Output Berechnungen auf separate Kerne der CPU legen. Man kann mit dem Rest des PC's fast anstellen was man will. Die haben sogar moderne Screens und CPU's. Dazu lässt sich der volle Umfang von MS Visual Studio nutzen. Sogar ein Deutsches Produkt. ;)

Richtige Echtzeit-Schnittstellen müssen in C++ programmiert sein, der Rest ist wurscht.
Immerhin bietet dieser eine Lizenz an um das ganze auch auf eigenen Maschinen laufen zu lassen.

Member
Beiträge: 152
Registriert: 27.02.2008, 15:10

Beitragvon monster900 » 27.01.2014, 16:40

Moin,
ja da muss ich leider 100%ig zustimmen. Man gibt viel Geld für die Ausfallsicherheit der IT aus aber die Fertigungssysteme bleiben außen vor.
Hatte gerade wieder den Fall, dass einer unserer Gravurmaschinen nicht funktionierte weil es hier einen Ausfall gab.
Ließ sich zwar innerhalb des WE beheben trotzdem ein eigentlich vermeidbares Problem. Immerhin läuft da schon WinXP auf dem Rechner...

Mein Highlight hier ist ein Druckprüfstand der mit einem WfW 3.11 läuft. :roll: Wir haben der GF schon vor Jahren klar gesagt, dass wir einen Support ablehnen.
Leider interessiert das nicht, weil wenn es hakt müssen wir es wieder ans laufen bekommen.

Grundsätzlich habe ich auch mit Standard-PC Technik kein Problem. Viel schlimmer finde ich, dass die Programmierung/HW dieser Steuercomputer teileweise um Jahre der aktuellen Technik hinterherhinkt.
Da laufen dann Programme teilweise nur mit Admin-Rechten unter aktuellem Windows oder es wird heutzutage ein paralleler Druckerport für einen Dongle vorausgesetzt :shock:
Leider wird die IT immer als letztes gefragt, wenn es um die Anschaffung neuer Produktionssysteme geht.

Gruß
Dirk

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 27.01.2014, 18:21

Ja das ist leider so... :(

Ich sehe ja jeweils beide Seiten, da Kleinbetriebe. Die Problematik ist halt immer folgende:
- Die für den Anwendungszweck beste mechanische Maschine am Markt hat nicht zwingend die beste und fortschrittlichste Elektronik
- Alte, gute und untödliche Hardware fehlt die moderne Elektronik

Wozu soll man also ein sehr gutes Produkt durch ein schlechteres ersetzen?

Wenn ich mir nur die ganzen Fräs- und Drehcenter anschaue. Da wird an der Mechanik teilweise alles weggespart. Auch bei Prüfmittelgeräten ist heut nix mehr dran.
Ein Mini-Crash bedeutet manchmal schon x-10k Schaden wos die alten Maschinen teilweise kaum gejuckt hätte. Gerade wieder einen solchen Fall gehabt.

Die teure Reperatur ist dabei nur eines, aber die Ausfallzeiten sind dann gerade für eher kleinere Betriebe nicht interessant. Das die Ersatzteile dann häufig erst via Übersee kommen müssen weil natürlich genau das benötigte Teil nicht an Lager ist (die üblichen Ausreden halt), macht es auch nicht besser. Mit solider alter Technik hat man da Ruhe oder kann es eben mechanisch richten. In grösserren Betrieben fängt man es eben unter Umständen mit ner anderen baugleichen Maschine auf. Diesen Luxus haben kleine leider selten und das ganze wird schnell sehr mühsam.


Solche Umstände machen die Situation für die interne oder externe IT nicht gerade komfortabel, selbst wenn sie von Anfang an involviert ist. Auch heisst es nicht, dass wenn eine OS/Software heute top modern ist, diese in 10-15 Jahren oder bei Spezialanfertigungen 20-25 Jahren noch immer passt oder ein Update verfügbar ist.

Adminrechte unter modernen OS: Kenne ich leider auch nur zu gut. Meistens bräuchten sie es ned mal, lehnen aber jeden Support ab, wens nicht so ist. Diverse male festgestellt, dass es doch läuft und nur auf ein paar Verzeichnisse Lösch- oder Änderungsrechte benötigen. Sie können so halt Fehler aufgrund zugriffsbeschränkungen ausschliessen.

Ich musste grad wieder bei zwei Neuanschaffungen in den sauren Apfel beissen. Entweder habe ich Garantie und Support oder ich habe eigene Serverhardware und weder offiziell Support noch Garantie. Mangels Alternativen ist es halt so. Und da die Software bei einer Maschine eh speziell dafür geschrieben wird, kann ich es nicht riskieren, dass sie sagen können, es liege an der Hardware.


Die Hersteller der Steuerungen der Elektronik haben wiederum ein sehr überschaubares Programm an Hardware die unterstützt wird. Diese ist selten wirklich auf 24/7 ausgelegt. Bis auf den TouchScreen. Vielleicht sind sie sogar besser verarbeitet.


Bezüglich deinem Prüfstand:
WfW 3.11 kannst mit sehr grosser Wahrscheinlichkeit mit 98 SE ersetzen. Läuft ultrastabil und kriegst dann auch auf nem Pentium 4 als VM in VmWare Workstation unter XP/Server 2003 zum laufen. Parallel-Dongles auch kein Problem. Läuft sogar Hyperschnell wenn die VM auf nem normalen Windows-Netzwerklaufwerk liegt. Datensicherungen sollten dann kein Akt sein.


Zurück zu „Hardware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 20 Gäste