Am 16-bit-A/D-Wandler „IOtech AD488“ mit GPIB-Schnittstelle liegen die Analogsignale für Leistung, Drehmoment und Drehzahl an. Für die „kompensierten“ Ausgangswerte liegt der Erfassungsbereich bei ±30000, nicht ±32767, für ±10 V Eingangsspannung.
| Kanal | Symbol | 1 V = | 10 V = | Auflösung | Kommastellen | Herkunft | Kommentar |
|---|---|---|---|---|---|---|---|
| C1 | P | 5/3 = 1,6 | 16, | 0,5 W | 3 | Messwelle | nicht ausgewertet |
| C2 | nm | 1000 U/min | 10000 U/min | 0,33 U/min | 0 | Messwelle | Nur positiv! |
| C3 | M | 0,25 Nm (unsicher) | 10 Nm | 0,01 Ncm | 3 | Messwelle | |
| C4 | n | 400 U/min | 4000 U/min | 0 | Umrichter | wacklig mit 1 Hz bei eingeschaltetem Motor | |
| C5 | M2 | ? | ? | 3 | Umrichter | ungenutzt um bei 4 Kanälen zu bleiben |
Dieses altertümliche Gerät verwendet kein
SCPI.
Aber das macht dessen Programmierung keineswegs schwieriger;
die Steuerkommandos sind sogar etwas kürzer.
Eine handliche Kurzübersicht ist als Faltblatt dabei.
Die Daten werden mittels permanenter binärer Messwertausgabe („T0G10“) ausgespuckt. „Kompensiert“ sind die „richtigen“ Messwerte. Die maximale Datenrate liegt dann bei 1 kSa/s. Das IOtech-Gerät kann anscheinend nicht schneller rechnen. „Unkompensiert“ („T0G11“) bedeutet, dass Offset- und Verstärkungskorrektur mit einem extra Kommando vom Gerät gelesen werden muss (dort vmtl. im EEPROM gespeichert). Nach der kanalweisen Verrechnung der „unkompensierten“ Daten kommt dasselbe heraus. Die maximale Datenrate erreicht dann (nur nur dann) den angegebenen Datenblattwert von 20 kSa/s für 4 Kanäle. LabVIEW hat Probleme mit dieser hohe Rate, wenn parallel Datenverarbeitung läuft, dies äußert sich in gelegentlichen Aussetzern bei der Erfassung. Mit 2 kSa/s läuft das Programm hinreichend stabil.
Von der Messwelle kommen leider nur positive Drehzahlen und damit Spannungen. Murks! Das Drehmomentsignal nutzt beide Richtungen.
Die Messdaten-Erfassung läuft in einer separaten While-Schleife ab.
Die Daten wandern als Signalschnipsel in eine Queue.
Sonst nichts.
Diese Schleife bekommt laut LabVIEW-Dokumentation einen eigenen Thread:
Ein typischer Worker-Thread.
Er blockiert beim GPIB-Lesen auf den jeweils nächsten Datenblock.
Die Leseroutine liest genau so viele Bytes ein wie für 100 ms Sampledaten erforderlich.
TODO: Er müsste jetzt bloß noch hochpriorisiert werden.
Alles weitere geschieht in einer weiteren While-Schleife: Sowohl die Weiterverarbeitung der Signalstückchen aus der Queue zur Darstellung in einer Art Oszilloskop als auch die gesamte Ereignisbehandlung. Ein typischer GUI-Thread. Er blockiert mit Timeout oder Benutzereingaben. Damit die Queue nicht überlaufen kann, wird diese im Timeout-Case der Ereignisbehandlung stets komplett geleert. Die herausfallenden Waveform-Schnipsel im 2D-Array werden — aneinandergereiht gedacht, nicht zwingend getan — weiterverarbeitet.
Hier ist die LabVIEW-Quelle für LabVIEW 2017 oder höher.
| SubD25♂ | Ader | SubD25♀ | Bedeutung |
|---|---|---|---|
| 3 | rt | 1 | Leistung+ |
| 4 | or | 15 | Drehzahl+ |
| 6 | ge | 4 | Drehmoment+ |
| 13+25 | gn | 5 | Drehmoment- |
| br | 16 | Drehzahl- | |
| sw | 2 | Leistung- | |
| Gehäuse | Schirm | - | Schirm |
Wie der Massebezug hergestellt wird ist unklar!! Vielleicht kommt deshalb so viel Rauschen raus.
(Feststellung: Nein, das ist nicht der Fall.)
Der 25-polige SubD-Stecker ist recht interessant belegt:
Die Farben dienen der Visualisierung des bevorzugten symmetrischen Kabelanschlusses.
Die Massen sind untereinander im Gerät verbunden, nicht jedoch mit Schutzerde.
Für die Verwendung eines Hosenträgerkabels via Schneidklemm-Adapter
ist diese Anschlussweise eher suboptimal zu nennen,
da die differenziellen Leitungen nicht nebeneinander liegen
und untereinander nicht mit Masse getrennt sind.
Das Pin 13 ist frei.
Tipp: Egal ob analoge oder digitale differenzielle Signale: Ethernetkabel sind dafür optimal — und preiswert zugleich. Bei analogen Kabeln eher CAT6 (paarweise geschirmt), bei digital genügt CAT5E (weniger Erdkapazität).
Für den Versuch machen sich neue Anschlüsse erforderlich. Lukrativ erscheint die Möglichkeit, Drehzahlistwerte digital abzufragen. Leider bekommt man diese nicht ohne Zeitversatz zum Drehmomentsignal. Auch kann man so vielleicht eine Solldrehzahl setzen und Reglerparameter beeinflussen.
| Schraubklemme | Bedeutung | Ader | SubD25♀ | AD488-Kanal |
|---|---|---|---|---|
| 9 | Drehzahl, ±5 V | ws | 18 | C4+ |
| 10 | Drehmoment, ±5 V | br | 7 | C5+ |
| 11 | Bezugspotenzial, 0V | gn,ge | 19,8 | C4–,C5– |
| — | Schirm | 17 | ┷ |
Da die Analogwerte schwanken, wird die Mittelwertbildung mit einem einstellbaren Zeitfenster realisiert. Um nicht jedesmal alle Abtastwerte durchrechnen zu müssen, wird jedes Signalschnipsel mit nützlichen Statistikwerten (Attribut „stat“) versehen:
Schade dass LabVIEW das nicht gleich selber tut. Was denen für die automatische Skalierung hilft. (Leere Signalschnipsel sollten keine Statistikwerte aufweisen.) Auch wenn mehrere Signalschnipsel verkettet werden, lässt sich daraus einfach berechnen:
Die Erkennung von ans Limit kommenden Messwerten und Ersatz durch ±INF wurde erst mal nicht eingebaut. Die Daten-Entschachtelung und Konvertierung zu Double erfolgt im Worker-Thread. (Möglicherweise keine gute Idee.)
Dieser Anschluss des Umrichters ist auf RJ-45 (8P8C) herausgeführt: Sieht aus wie eine Ethernet-Buchse. Zur Adaptierung mit einem NI USB-485 wurde folgender Adapter erstellt:
| Signal | NI USB-485 | CT-Umrichter | Aderfarbe | China-Konverter |
|---|---|---|---|---|
| SubD9♀ | RJ-45♂ | ISDN-Flachkabel | Schraubklemme | |
| GND | 1 | 3 | orange | - |
| CTS+ — RTS+ | 2,3 | - | ||
| RxD+ — TxD+ | 4,8 | 2 | rot | D+ oder A |
| RxD- — TxD- | 5,9 | 7 | braun | D– oder B |
| CTS- — RTS- | 6,7 | - |
Es werden tatsächlich nur diese 3 Adern benötigt. Damit das Anschlusskabel „unsichtbar“ hinter der Frontblende verschwinden kann, wurde dafür ein altes, flaches ISDN-Kabel zerschnitten. Ein Ethernetkabel wäre zu dick dafür.
Es muss nicht der 200 Euro teure NI-Adapter sein, dieser Konverter aus China für ein Hundertstel des Preises tut es auch.
Das Datenprotokoll ist Modbus-RTU. (Nix mit *IDN?! Das ist SCPI, üblich für GPIB.) Um den Drehzahlistwert an der Adresse 0.10 zu lesen ist folgendes zu senden:
|
|
Das VI Modbus-RW.vi kümmert sich um das Anhängen, Abschneiden
und Überprüfen der CRC.
Es bekommt einen String am Eingang, der am besten mit der Funktion
„Daten serialisieren“ erstellt wird.
Umgekehrt wird der Antwortstring am besten mit „Daten deserialisieren“
auseinandergenommen.
Um die Angaben für die immer konstante Slave-Adresse muss sich
die nächste Software-Schicht kümmern.
Zum Setzen von Werten gibt es verschiedene Modbus-Telegramme. Am naheliegendsten ist der zum Setzen mehrerer audeinanderfolgender Adressen (16). Dies passt logisch zum oben verwendeten Telegrammformat (3). Eine Solldrehzahl lässt sich anscheinend nicht setzen, daher hier im Beispiel das Setzen von Parametern des PID-Drehzahlreglers:
|
|
