IAI-Geber

Eine preiswerte Linearachse mit Schrittmotor, Wegmesssystem und Controller. Soll an einer Siemens-Steuerung betrieben werden. Bezeichnung: IAI PCON-CB 35PWAI-PN-2-0. Der Controller soll ersetzt werden. Dazu muss die Schnittstelle für die Wegmessung bekannt sein. Ggf. muss eine Schaltung mit Mikrocontroller oder FPGA dazwischen.

Ausforschung

Verbindungskabel

Auf der Controllerseite ist ein 2-reihiger 24-poliger XAD-JST-Board-Zu-Wire-Steckverbinder im 2,5-mm-Raster mit Verriegelung. An diesem ist ein 22-poliges ungeschirmtes Kabel von ca. 2 m Länge angeschlossen, bei dem 6 Adern etwas dicker sind; sie gehen zum Schrittmotor. An der Achse sitzt ein (nicht im Internet auffindbarer) 5-reihiger 24-poliger JST-Wire-Zu-Wire-Steckverbinder im 2,5-mm-Raster mit Verriegelung. Dabei hat die untere, von der Verriegelung am weitesten entfernte Reihe, nur 4 Kontakte. Da die Zählweise aus dem Datenblatt nicht ersichtlich ist, habe ich diese wie im folgenden Bild ersichtlich festgelegt. Einige Adern haben einen schwarzen Längsstreifen.

Im Innern der Achse verteilt sich der Stecker auf 3 weitere Stecker, je einer zum Motor, zur Bremse und zum Geber. Auch hier ist die Zählweise „nach Gusto“ festgelegt. Um sich einen Überblick über das Stecker- und Farben-Wirrwarr zu machen, folgt eine sortierbare Tabelle.

Geber-Signale

Auf dem Geber ließen sich neben einem QR-Kode diverse Bezeichnungen finden:

• 23KMLK748UN04LA_201; 620123701 (auf dem Etikett)
• ED-060-9-002-0-000-3 (auf der Platine)

Was sich so mit dem Oszilloskop beobachten ließ: A und B liefern komplementäre digitale Sinus- und Kosinussignale für magere 200 Striche pro Umlauf. Die Spindelsteigung beträgt 24 mm pro Umlauf. Das Zahnriemengetriebe hat eine 1:1-Übersetzung, also keine. Die Auswertung des Quadrantensignals ergibt eine Linearauflösung von 24 mm / 4×200 = 0,03 mm = 30 µm. Es wird sicherlich während der Bewegung vom Controller ausgewertet, weil es ohne Verzögerung kommt.

Auf der Geberplatine befindet sich ein 64-beiniger Schaltkreis. Dieser macht sicherlich eine Interpolation, und gibt das Ergebnis digital gewandelt aus. Und genau hier liegt das Problem: Es ist undokumentiert! Heidenhain EnDat ist es jedenfalls nicht, kein Taktsignal. Alle Signale (auf allen 6 Leitungen) haben 3,3 V Amplitude, nicht 5 V. Die Stromaufnahme lag bei 80 mA.

Das beobachtete Digitalsignal hat folgende Eigenschaften:

• Bitzeit 0,4 µs entsprechend 2,5 MBit/s
• Blocklänge 100 µs entsprechend 250 Bit(zeiten)
• Asynchron-serielle Datenübertragung 8-n-1 (8 Datenbit ohne Parität)
• Leicht unterschiedliche Spannungspegel im Ruhezustand, führt zum Lesen von „1“
• Anfrage vom Controller alle 100 µs (10 kHz) 0x1A (Dauer: 4 µs)
• Etwa 4 µs Pause
• Antwort vom Geber aus 11 Byte Daten (Dauer: 44 µs), letztes Byte offenbar Prüfsumme
• Nur wenige Datenbits ändern sich, allerdings bei wahnwitzig kleinen Verdrehwinkeln
• Es sieht erst mal unverschlüsselt und nach Binärkode (kein Graykode) aus
  • 0x1A; 0x00
  • Low-Byte Position, untere 3 Bit = 0; High-Byte Position
  • Höchstes Bit der Position, obere 7 Bit = 0;
  • konstant; konstant; konstant; konstant; konstant
  • Prüfsumme: XOR über alle 11 Bytes der Antwort ergibt 0

Wer Sender und Empfänger ist wurde mit Serienwiderständen herausgefunden.

Was der Geber tut, wenn man etwas anderes als 0x1A hinschickt, muss noch herausgefunden werden. Auch ist es denkbar, wenn auch unwahrscheinlich, dass der Geber eine gesonderte Initialisierungssequenz benötigt. Für die Beobachtung derselben muss man größere Geschütze auffahren als das hier verwendete Analogoszilloskop. Ohne Anfragebyte kommt jedenfalls nichts.

Wer macht daraus einen Absolutwertgeber?

Das Versprechen des Herstellers ist ein (teurer) Absolutwertgeber, vebaut wurde lediglich ein preiswerter Inkrementalgeber. Da auf der Controllerplatine eine dicke Stützbatterie oder Superkondensator verbaut wurde, gehe ich davon aus, dass der Controller die Strichzählung irgendwie auch bei Stromausfall fortsetzt. Oder aber er ist doch etwas blöder und verlässt sich auf die Endschalter Motor-Blockierung beim Referenzieren.

Schlachtplan

Als nächster Schritt kommt ein Arduino mit MAX485 dran. Für die erforderliche Baudrate muss ein AVR mit 2,5 MHz × 8 = 20 MHz getaktet sein, dazu müsste man einen ATmega schon übertakten. Wenn es nur um's Auslesen für den PC geht, eignet sich der bereits für eine andere Anwendung entwickelte USB-zu-RS422-Umsetzer ganz ausgezeichnet als Vorlage. Der Quarz wird durch 20 MHz ersetzt, der ATtiny nicht mal übertaktet, und der 75179 durch einen 75176 ersetzt. Andererseits sollte das ein PIC16F1454 auch ohne FT245 und ohne Quarz schaffen? Nein, das wird zu ungenau: BRG16=1, BRGH=1, SPBRG=4 ergibt 48MHz/(4(4+1)) = 2,4 MBaud, ein Fehler von 4 %, zu viel.

Adapter-Schaltung

Jetzt kommt's raus: Die Siemens-Steuerung will Heidenhain EnDat. Also doch mal wieder so ein Adapter. Ich gehe mal davon aus, dass auch BiSS unterstützt wird.

An SV2 wird für die Inbetriebnahme (irgend)ein Arduino mit seinem Slave-SPI angeschlossen, um die Daten des IAI-Gebers zu überprüfen, also zum Debuggen. Das BiSS/EnDat-Interface wird erst danach bestückt. Die aktive Terminierung aus den vielen Widerständen, Kondensatoren und IC5 kann für Vorversuche entfallen, ich habe dennoch erst mal alles bestückt, auch die Angstwiderstände, weil sie die oszillografische Inbetriebnahme erleichtern.

Als Mikrocontroller kommt ein ATtiny2313 zum Einsatz, der IMHO als einziger Mikrocontroller die folgenden Eigenschaften vereinigt:

• Asynchron-serielle Schnittstelle
• … mit 2,5 MBaud maximaler Baudrate (= 20 MHz / 8 für DoubleSpeed-UART)
• 5V-I/O
• Durchsteck-Gehäuse

Als Schnittstellenwandler wurden die etwas teureren MAX485 an Stelle der Stromfresser 75176 eingesetzt. Kein (8-Bit-)Arduino kann das!

Eagle-4.11-Datei zum Download inklusive Mikrocontroller-Firmware. Der Nachweis der korrekten Funktion des seriellen UART-Empfangs bei 2,5 MBaud mit ATtiny2313 wurde 2021-01-06 erbracht.

Die Anschlussbelegung der beiden RJ45-Buchsen wurde mit Absicht so gewählt, dass:

• an J2 ein vierpoliges Telefonkabel in der Mitte angecrimpt werden kann, welches in der Anschlussbelegung exakt USB entspricht: 5P — D– — D+ — 00
• an J1 die beiden schnellen Leitungen an verdrillte Paare eines Ethernetkabels zu liegen kommen, dabei D- stets numerisch vor D+ (wie bei USB, nicht wie bei Ethernet)
• Künftig (durch die Reservierung der mittleren beiden Kontakte an J1 der Konverter auch mit einem Stecker (und entsprechendem Y-Kabel) angeschlossen werden kann

Auf Verwechslungssicherheit wurde zugunsten der Verwendbarkeit von vorkonfektionierten Ethernet-Kabeln verzichtet; für J2 könnte aber auch eine vierpolige RJ10-Buchse vorgesehen werden, als Bestückungsvariante auf einer professionell gefertigten Platine.

Untersuchung mit Logikanalysator

Beim Einschalten gibt es serielle Kommunikation mit 115200 Baud!! Mit unklarer Datenrichtung.

Vom Einschalten bis zum 1. Telegramm: 260 ms. Von Telegramm (in sich lückenlos) zum nächsten: 4,3 ms (Lücke dazwischen 3,6 ms). Vom letzten Telegrammende bis zur Kommunikation mit 2,5 MBaud: 6,6 ms Das letzte Byte ist jeweils die XOR-Prüfsumme.

Datenrichtungen sind unklar, vermutlich kommt die Antwort vom Inkrementalgeber. Die letzten Bytes sind jeweils XOR-Prüfsummen. Nachdem 1x die Position mit 0x1A (wie oben) abgefragt wird, eine Pause und nochmal Abfragen!

Der Startup ist hier aufgezeichnet: IAI Start.sr, IAI Start.pvs. Das legt folgende Funktionalität nahe:

• 0xEA <adr> <xor> = Byte an Adresse lesen; Antwort: 0xEA <adr> <val> <xor> = liefert Datenbyte
• 0x32 <adr> <val> <xor> = Byte an Adresse setzen; Antwort identisch

Schließlich wurde die Firmware so umgestaltet, dass sie auf dem Debugport die 15-Bit-Position als 16-Bit-Wert linksbündig ausspuckt. Um es später mit einem Arduino Leonardo auf dem PC durchzureichen. Vorerst genügt die Anzeige mit PulseView.

• D0 = serielle UART-Daten vom IAI-Geber
• D1 = gelbe LED, zeigt erkannten Datenrahmen an
• D2 = grüne LED
• D8 = Debug-CS (zeigt 16-Bit-Datenblock an)
• D9 = Debug-MISO (ungenutzt)
• D10 = Debug-MOSI (Positionsdaten, MSBfirst)
• D11 = Debug-SCK (16 Bittakt-Impulse)

Stecker

Den 14-poligen Centronics-ähnlichen Stecker für die Siemens-Steuerung (Buchse X9) gibt's bei Digikey unter der Nummer 3M158272-ND. Das Gehäuse mit der Bezeichnung 3M 10314 gibts unter der Nummer 3M1745-ND, sowie bei Ebay, allerdings als Rasthaken-, nicht als Schraubbefestigung. Wie sich bei Ankunft der Motorsteuerung herausstellte: Die Buchse X9 kommt sowohl mit Rasthaken als auch mit Schrauben zurecht.

Steuerung und Motor

Nun liegt alles neu auf dem Tisch, die alte Linearachse mit Schrittmotor wird obsolet:

• IAI-Achse RCS4-SA4C-WA-60-5-300-T2-N-CJR
• Siemens-Steuerung Sinamics V90 6SL3210-5FB10-4UF1, V10300
• Siemens-Motor Simotics S-1FL6034-2AF21-1AA1, gleich mal Gebergehäuse untersucht
  • TRD-35H2500V-30-7369 mit 8-poligem Stecker

Siehe auch

• BiSS von Beckhoff
• BiSS (Wikipedia)
• BiSS von Hengstler
• PulseView + Sigrok Logikanalysator