IO-Karte PCI oder USB, MC-Board oder Alternativen? (für Motorsteuerung)

Druckbare Version

30.04.2017, 16:32
otto23

IO-Karte PCI oder USB, MC-Board oder Alternativen? (für Motorsteuerung)

Aufgabe:
Es soll eine einfache Motorsteuerung gebaut werden, ca. 8 Out-, ca. 4 In-Kanäle, TTL, gerne galvanisch getrennt.
Es gibt zwei zu realisierende Teilbereiche:
- eine einfache Oberfläche zum Starten und Stoppen sowie zur Einstellung der Parameter (Einspritzdauer, Zündzeiten usw.) sowie
- ein Programm bzw. Programmteil, welches auf Sensorimpulse reagiert und die Einspritzung und Zündung ansteuert
Die Programmierung soll in C# und/oder C++ erfolgen (nach Möglichkeit Windows mit Visual Studio). Die geforderten Schalt- und Reaktionszeiten bewegen sich um die 100 Mikrosekunden.

Problem:
Welches ist der beste Weg, dies zu realisieren? Ich sehe folgende Alternativen:

A) Ein PC mit einer IO-Karte (PCI). Ein C++-Programm, welches die Oberfläche bereitstellt sowie in einem Hintergrund-Thread die Motorsteuerung durchführt.
Vorteile:
- gutes Zeitverhalten bei der Ansteuerung der IOs
- ein Programm für alles
Nachteile:
- muss die Oberfläche mit C++ programmieren (bin da etwas aus der Übung, die letzten Jahre nur C#)
- kann meinen Notebook nicht verwenden, man braucht immer einen konventionellen PC mit Steckplatz, dort müsste ich erst mühsam alles installieren, bei Änderungen müsste ich vor Ort sein bzw. den PC erst herholen...
Fragen:
- wo bekomme ich eine passende IO-Karte her? Habe im Netz gesucht, aber nichts Vernünftiges gefunden

B) Wie A), jedoch keine PCI-IO-Karte sondern ein externes Modul mit entsprechenden IO-Ports, welches man über USB ansteuern kann.
Vorteile:
- man braucht keinen PC mit Karte, sondern kann "jeden x-beliebigen" Notebook nehmen
- könnte meinen normalen Arbeitsnotebook nehmen (wo die Entwicklungsumgebung schon installiert ist)
- bei Erweiterungen/Fehlersuche usw. deutlich einfacher
Nachteile:
- Zeitverzögerung durch die USB-Schnittstelle
Fragen:
- ist dies überhaupt realistisch? IMHO wird doch hier USB benützt, was ja kein definiertes Zeitverhalten hat. Oder wird hier quasi die Hardware der USB direkt angesteuert, so dass nur Verzögerungen auftreten, die für meine Zwecke keine Rolle spielen (also geschätzt kleiner als 10 Mikrosekunden sind)?
- wo bekomme ich eine passende externe Hardware (IO-Modul)?

C) Notebook mit einem Mikrocontrollerboard (z.B. Arduino, Raspi), welches z.B. über USB (alternativ Bluetooth, Wireless, LAN) verbunden ist. Auf dem MC-Board liefe die Motorsteuerung (C++-Programm), auf dem Notebook ein C#-Programm mit schöner GUI. Beide kommunizieren, was nicht zeitkritisch ist.
Vorteile:
- könnte GUI mit C# machen :-)
- man bräuche keine besondere Hardware
Nachteile:
- zwei getrennte Projekte
- Programmierung der Kommunikation nötig
- Tests aufwändiger
- Einarbeitung in MC-Board, Installation der Entwicklungsumgebung hierfür
Fragen:
- hat jemand einen Tipp für das MC-Board?

Bitte schreibt mir eure Meinung. Vielleicht, so hoffe ich, gibt es bessere Alternativen, die ich übersehen habe oder nicht kenne. Selbst wenn nicht, würde ich mich über Einschätzungen über die o.a. Realisierungswege freuen.

Danke!
30.04.2017, 17:33
Mxt

Hallo,

Zitat:

Zitat von otto23

[...]
Die geforderten Schalt- und Reaktionszeiten bewegen sich um die 100 Mikrosekunden.
[...]

A) Ein PC mit einer IO-Karte (PCI). Ein C++-Programm, welches die Oberfläche bereitstellt sowie in einem Hintergrund-Thread die Motorsteuerung durchführt.
Vorteile:
- gutes Zeitverhalten bei der Ansteuerung der IOs

Meiner Erfahrung mit IO-Karten verschiedenener Hersteller nach würde ich das stark bezweifeln. Das ginge höchstens mit Windows Echtzeiterweiterungen wie der hier
http://kithara.com/de
oder teuren Karten mit eingebautem Prozessor.

Zitat:

Zitat von otto23

- muss die Oberfläche mit C++ programmieren (bin da etwas aus der Übung, die letzten Jahre nur C#)

Nein. Man kann in einer Visual Studio Projektmappe Projekte in mehreren Sprachen kombinieren. Also z.B. die IO-Logik in C++ als DLL-Projekt, die von der C# Oberfläche verwendet wird.

Zitat:

Zitat von otto23

Aufgabe:
B) Wie A), jedoch keine PCI-IO-Karte sondern ein externes Modul mit entsprechenden IO-Ports, welches man über USB ansteuern kann.
[...]
Nachteile:
- Zeitverzögerung durch die USB-Schnittstelle

Es gibt (teure) USB-Module mit eigenem Prozessor. Mir fällt spontan "Compact RIO" von National Instruments ein, das wird aber mit LabView programmiert.

Zitat:

Zitat von otto23

Notebook mit einem Mikrocontrollerboard

Das ist wohl von allem die günstigste und flexibelste Möglichkeit. Die Auswahl ist da riesengroß. Linux Boards wie der Raspi und Microcontroller ohne Betriebssystem sind aber zwei unterschiedliche Baustellen.

Arduino wurde schon genannt. Da gibt es auch kompatible Boards wie den Teensy, die wesentlich leistungsfähiger sind
https://www.pjrc.com/teensy/index.html

Ein bischen professioneller wäre z.B. ARM mbed
https://developer.mbed.org/platforms/
30.04.2017, 18:05
otto23

Super informative Antwort, vor allem der Hinweis, dass die Windows-Programme ja unterbrochen werden können. Hatte ich glatt vergessen!
Und das mit der Kithara Realtime Suite. Werde ich mir auf jeden Fall genauer anschauen!
Tendiere für diese Sache dann aber wohl doch zur MC-Lösung...
Tausend Dank, Mxt!
15.07.2017, 13:44
morob

bei rt ist eine mc lösung immer besser, ich mach das sogar unter linux so.
15.07.2017, 21:29
Peter(TOO)

Hallo,

A)
Wie schon geschrieben wurde ist Windows nicht wirklich Echtzeitfähig. Da kann es im Normalbetrieb schon mal vorkommen, dass es 1-2 Sekunden alle anderen Tasks sperrt. Von Updates mal ganz abgesehen.
Ein weiteres Problem ist, dass es diese Karten nach ein paar Jahren nicht mehr gibt und die PCs einen anderen Bus verwenden.
So vor 25 Jahren wollte ein Kunde unbedingt so eine Lösung, weil er dachte so Entwicklungskosten zu sparen. Nach ein paar Jahren ist dann bei einem Kunden der PC ausgefallen und die Neuen hatten keinen ISA-Bus mehr. Schon vorher gab es die I/O-Karte aber nicht mehr, bzw. das Nachfolgemodell benötigte umfangreiche Anpassungen der Software.

B) Auch hier hast du das Problem der Reaktionszeiten des Betriebssystems. Du darfst auch nicht vergessen, dass sich die Geräte bei USB die Bandbreite teilen müssen. Die 100µs kannst du mit USB überhaupt nicht garantieren.

C) Finde ich die beste Lösung und hat sich bei mir auch im Industrie-Bereich bewährt.
Mindestens die grundsätzlichen, und vor allem zeitkritischen Funktionen werden komplett auf den µC ausgelagert. Je nach Anwendung kann der µC sogar Stand Alone arbeiten und der PC wird im Betrieb nur für Start/Stopp und Statusanzeigen benötigt.
Ein weiterer Vorteil ist die Stabilität! Welche Updates auf dem µC gemacht werden, liegt total in deiner Hand. Bei einem Betriebssystem musst du, schon wegen der Sicherheit, immer Updates ausführen. Dabei kommt es öfters vor, dass Programme danach nicht mehr oder fehlerhaft funktionieren. Dieses Problem fällt dann auch eher weg.

Die Tests müssen nicht aufwändiger sein, im Prinzip können sie auch einfacher werden. Verwendest du einen Befehlssatz welcher nur aus sichtbaren ASCII-Zeichen besteht, kannst du in der ersten Phase mit einer Terminal-Emulation auf dem PC testen.
Wenn du einen µC mit LAN oder WLAN verwendest. Ist natürlich auch eine Webseite als Userinterface möglich. Dann musst di auf dem PC gar nicht programmieren und verwendest einfach einen Browser. Dann ist es sogar egal ob du einen PC, Notebook, Tablet oder Handy verwendest um das alles zusteuern.

Das sind jetzt natürlich grundsätzliche Überlegungen und nicht alle meine Ideen sind für jeden Anwendungsfall ideal. Du schreibst ja nicht, was die Steuerung genau machen soll.

Die war dann auch, ein paar Jahre später die Lösung für das oben genannte Projekt. Über eine serielle Schnittstelle wurde ein mehr oder weniger autonomes System an den PC angeschlossen. Die Software auf dem PC übernahm dann die Bedienung, die grafische Aufbereitung und Anzeige der Messdaten und die Speicherung der Messwerte.

Übrigens habe ich bei diesem Projekt die PC-Oberfläche in Visual BASIC geschrieben, weil dies eine grafische Oberfläche zum Zeichnen der GUI hatte. Einige Grafik-Elemente wurden als ActiveX umgesetzt und der Einfachheit halber auch in VB programmiert. Der Rest wurde in C geschrieben, wie auch die Firmware auf dem µC. Der Protokoll-Handler wurde portierbar geschrieben, somit gab es dafür nur einen Source-Code, welcher gepflegt werden musst.
Achja, die PC-Software hatte ich in 3 Module zerlegt.
Zuunterst war ein COM-Server welcher das Protokoll abgewickelt hat und ein API für die nächste Schicht bereit stellte.
Darauf setzte dann ein weiterer COM-Server auf, welcher die Ablaufsteuerung usw. enthielt und ein weiteres API zur Verfügung stellte. Zudem konnte man diese COM-Server über die Comandozeile so starten, dass er eine Art Debug-Interface anzeigte. Damit konnte man dann alle I/Os einzeln ansteuern und anzeigen. Zudem gab es noch Routinen um die ADC und DAC abzugleichen.
Hier setzte dann das eigentliche Userinterface auf, welches zudem für die meisten Kunden unterschiedlich war.
Das Ganze lief dann Anfangs unter WIN 95.

Wie schon angegeben war das Meiste in VB und C geschrieben. Kleinere Teile, wie das COM-Interface, war in C++ geschrieben, weil MS dazu einen Wizard mit der Entwicklungsumgebung mitgeliefert hat.
Technisch ist es nicht wirklich ein Problem unterschiedliche Sprachen zu mischen und diejenigen zu verwenden, welche die Teilprobleme am einfachsten lösen. Zumindest wenn man in mehr als einer Sprache fit ist.

MfG Peter(TOO)