Beiträge von Eagle

    Ok verstehe...
    Um das Problem konkret lösen zu können müsste ich mich ja auch erstmal genau mit Schweißvorgängen beschäftigen.


    Meine Aufgabe bestand darin die "Ecke" schnellst möglich zum umfahren, so dass kein Loch gebrannt wird. Ohne Absetzen muss ich also dafür sorgen, dass sich das Teil möglichst schnell dreht und nicht lange an der Ecke verweilt...


    Auf 30% Override huscht der ja jetzt schon recht flott um die Ecken, allerdings geb ich ihm teilweise 50mm Platz für die Umorientierung was Schweißtechnisch ziemlicher Mumpitz ist, denk ich mal.
    Bei 10-20mm wirds dann schon langsam wieder mies mit der konstanten Geschwindigkeit.


    Ich habe mir das eben so vorgestellt, dass ich ihm für die Achsen 4-6 bzw. im kartesischen System eben die Koordinaten A-C fast ausschließlich für die Orientierung des Tools zuständig sind. Ich dachte ich könnte diese Orientierungsgeschwindigkeiten leichter ändern (ohne die Bahngeschwindigkeiten zu ändern). Anscheinend ist die einzige Möglichkeit aber in der config.dat die Vel und Acc Werte für Ori zu erhöhen und vielleicht für CP zu verlangsamen, das probiere ich jetzt nochmal genauer aus...


    Danke dir auf jeden Fall schonmal für jeden Beitrag, ich bin für jegliche Art von Kommentar und Ratschlag offen ;)

    Habe die Werte in der config.dat geändert auf:


    DEF_VEL_ORI1 =400.0 (MAX)
    DEF_VEL_ORI2 =400.0 (MAX)
    DEF_ACC_ORI1=800.0
    DEF_ACC_ORI2=800.0


    (Die ACC Werte haben nicht mehr soo viel verändert, aber das DEF_VEL hat mich schon ein ganzes Stück, nach vorne gebracht)


    :gutidee: :danke:


    Was mich wundert:
    (Muss dazu sagen: Ich habe einen Punkt gelöscht... fahre die Ecke nun direkt an und gebe in der zweiten Richtung nach 10mm einen Punkt an, um ihm damit zu signalisieren, dass er sich für die Drehung nicht bis zum Endpunkt der Bahn 2 Zeit lassen soll, sondern nach 10mm bereits fertig gedreht haben muss.) :jawohl:


    Wenn ich von LIN auf LIN überschleifen möchte (90°) mit C_DIS, dann beginnt die Umorientierung nicht mit Beginn des Überschleifens (10mm), sondern erst am exakten Eckpunkt... Somit ists kein richtiges Überschleifen, denn er hält an der Ecke an. :down:


    Mit C_VEl = 100 klappts schon ganz gut, der "huscht" zwar noch nicht so schnell um die Ecke, wie er gerade Linien entlangfährt, aber ich denke darauf lässt sich aufbauen.


    Kann ich im Programm nicht explizit sagen, er soll die Orientierungsbewegungen (Achsen 4-6) schnell durchführen aber rein translatorische Bewegungen mit veringerter Geschwindigkeit?
    Quasi VEL_ORI für Achsen 4-6 hoch und VEL_CP für Achsen 1-3 niedrig?
    Dann könnte ich die Orientierungsgeschweindigkeit auf die Bahngeschwindigkeit abstimmen und somit sowohl auf der Geraden, als auch in der Ecke (Kreisbogen mit r=1-10mm) konstant die Bahneschwindigkeit halten.


    @Detlef: Diese Unterbrechung des Schweißvorgangs wie in deinem Video... Ist das Schweißtechnisch wirklich in Ordnung so? Dann könnte man ja ebensogut auch den Schweißvorgang abschalten, 90° Drehen und dann wieder anschalten. Kommt mir ziemlich umständlich vor die Methode, hmmmm :denk:

    uiuiui, da hab ich ja mal ne heiße Diskussion in Gang gesetzt...


    Also werde dann mal vorsichtig mit den Def-Werten spielen und gucken, ob ich das erreiche, was ich möchte...
    Das Problem ist schließlich ein Standard-Problem, wenns ums Schweißen geht, aber der Robi ist schließlich unter anderem dafür gebaut.


    Hermann: Danke für die Tipps, ich werde es mal ausprobieren...


    @Detlef: Ich gebe dir Recht, eine 90° Ecke kann nicht flüssig laufen...
    ... aber wie du schon sagst ist Überschleifen hier das Stichwort und ich lasse ihn ja auch überschleifen.
    Ich möchte probieren, ob mit Überschleifen und/oder CIRC-Bewegungen (natürlich sehr kleine Wege) die nötige Mindestgeschwindigkeit fürs Schleifen erreicht werden kann. Ich glaube nicht, dass es unmöglich ist.

    Hm, wenn ich das richtig verstehe stellen die meisten Leute dann die DEF_ACC_ORI und DEF_VEL_ORI Werte hoch...


    Mein Problem ist aber glaub ich nicht, dass er nicht schneller drehen kann...
    Ich teste mein Programm auf 30% Override und da dreht der Robi sehr langsam um die Achse A6


    Wenn ich das Prog dann mal mit 100% druchlaufen lasse, dann passiert genau das gleiche... nur halt ALLES schneller.
    Er fährt schneller zum Eckpunkt hin, dreht auch schneller (klar) aber auch dann ist die Drehung wesentlich langsamer als die Translation.


    Ich müsste doch irgendwo sagen können, dass die tatsächliche Bahngeschwindigkeit gehalten werden soll und die dafür notwendigen Orientierungsgeschwindigkeiten gefahren werden müssen.
    --> Wenn er dann meckert, dass damit die Soll-Geschwindigkeit der Achse A6 überschritten wird, dann kann ich mir ja mal Gedanken über die Maximalen Werte machen, aber so glaube ich ist das Problem ein anderes...




    UND WENN DOCH:


    Sowohl in der $machine.dat, als auch in der $config.dat und in der bas.src scheinen ja Vel- bzw. Acc-Werte zu stehen.
    Ich verstehe das im Moment so, dass die Werte in der machine.dat die Maximalwerte sind, die bei geringer Last erlaubt sind. Heißt also schneller kann ich den Robi nicht einstellen als hier hinterlegt ist.
    Werden alle Bewegungen auf diese Max-Werte runtergeregelt oder gibts einen Fehler bei Überschreitung?


    In der config.dat kann ich dann die maximal Geschwindigkeiten einstellen, die mein Programm fahren darf ?!?
    Im Prog geb ich ja über BAS(#VEL_CP= xx) eine Geschwindigkeit an. Das ist dann die Geschwindigkeit, die ich "anfordere" und die die Geschw. aus der config.dat aber nicht überschreiten kann?


    Würde also heißen, ich darf (bei geringer Last --> Nur Schweißpistole) die Werte in der config.dat bis an die Werte aus der machine.dat anpassen und dann läuft der Robi generell schneller?
    Verletze ich damit irgendeine Garantie, wenn ich höhere Werte ausprobiere?



    Danke schonmal für die schnelle Hilfe hier! :grinser043:

    Sooo, hab endlich rausgekriegt, was nicht stimmte...
    Habe nun 2 Werte in der Backward.ini geändert und nun kann ich endlich initialisieren und damit dann auch überschleifen...



    Habe ein Programm geschrieben und die Ausrichtung des Robis ist nun wie bei Robotnik beschrieben.
    So läuft das alles schon viel übersichtlicher ab und die Orientierungsachsen werden entlastet.


    Mein Programm sieht nun vor, dass ein rechter Winkel geschweißt wird (nur die Bewegung, ohne Schweißen, es geht nur um die Theorie)...


    Läuft soweit schon wie ich es möchte...


    Über 4 Punkte habe ich ihm den Weg beschrieben (4x LIN Bewegung)


    LIN1: Robi fährt auf Eckpunkt zu
    LIN2: Robi fährt die letzten 10mm auf den Punkt zu und beginnt dabei das Schweißgerät um 45° zu drehen.
    LIN3: Robi fährt 10mm in die neue Richtung und dreht die restlichen 45°
    LIN4: Robi fährt konstant die zweite Kante entlang



    Kann das Programm grad nicht ausführlicher schreiben, da mein Laptop und der Robi an unterschiedlichen stellen stehen im Moment...


    Das Überschleifen macht mir nun ein wenig Probleme... Ich schleife mit C_DIS bzw. C_VEL


    Die Bewegungen des Robis sind gut und schnell, aber die Orienterungsänderung an der Ecke läuft sehr langsam...
    Beim Schweißen würde er mir also ein Loch in die Ecke brennen. Die Umorientierung läuft fast ausschließlich über die Achse A6 an der die Schweißpistole sitzt...


    Gibts auch so ein $APO.CORI=xxx oder BAS(#VEL_ORI= xxx) ?


    Er dreht die 45° Schritte in einem Male konstant durch aber eben zu langsam und wenn ich den Override höher stelle, sehe ich, dass die Achse A6 sehrwohl schneller kann...

    Noch ne Frage:


    Auf der KRC:\R1\System\$config.dat sieht ziemlich mager und leer aus:


    DEFDAT $CONFIG
    BASISTECH GLOBALS
    AUTOEXT GLOBALS
    ARCTECHDIGITAL GLOBALS
    USER GLOBALS
    ENDDAT


    Das ist alles was da drin steht... müssten da nicht noch jede Menge Werte stehen? Globale Variablen? Einstellungen der Geschwindigkeiten, Beschleunigungen, Überschleifen etc. ?


    Kann mir vielleicht jemand eine standard Config.dat hierfür schicken? Ist ja klar, dass der in meinen Programmen keine Variablem des Typs FRAME deklarieren kann, wenn nirgendwo steht, was das ist...
    :hilfe:

    Soo, nu komm ich auch endlich mal wieder dazu mich zu melden...



    Ja ihr habt da schon recht, ich werde an den Robi gesetzt mit nem Aktenordner in der Hand und dann heißt es "mach mal"...


    Haben sie damals mit dem alten Kuka IR 363/6 mit KRC32 Steuerung mit mir gemacht und nu machen sies mit dem schicken Kuka KR30 L16 und KRC 2 Steuerung... :)
    (Damals als Praktikant, nu als HiWi :D)


    Ich steh hier teilweise wirklich wie ein Ochs vorm Berg, aber et hilft ja nichts.


    Nun zu euch:


    - Jo, PTP ist nicht wirklich linear --> weiß ich. Aber um erstmal die HOME Position anzufahren ist es doch der schnellste Weg oder?
    Ich muss dazu sagen, dass ich im Moment nur den Robi bewege, das Schweißen kommt dann später, wenn oder falls ich mich mit dem Robi genug auskenne. Hier gehts erstmal um die Theorie der Bewegungen, Orientierungen und des Programmierens.


    - Das mit dem CONT habe ich bereits versucht, allerdings ohne weiter etwas zu definieren (C_DIS oder so)
    Allerdings stoppt der Robi zwischen den beiden Halbkreisen immernoch, einen schönen großen Kreis hab ich noch nicht in einem Rutsch hinbekommen. Er meldete mir "Überschleifen nicht möglich"


    - Die Stelle wo der Draht rauskäme scheint in etwa im Zentrum der Achse A6 zu liegen, allerdings (wie es denk ich mal normal ist) unter einem Winkel von etwa 30°.
    Mein Problem ist, dass wenn ich ihm für eine CIRC Bewegung im Inline Verfahren Punkte teache, er mal ohne Umorientierung genau den Kreisbogen nachfährt, wie ich es möchte und ein anderes mal (bei mir 2. Halbkreis) dreht sich plötzlich der Robi um das TCP... Beidemale habe ich die Halbkreise einfach so geteached, dass er erst in der Y-Achse um 100 nach rechts fährt und um 100 (Z-Achse) nach unten --> Hilspunkt
    dann wieder 100 nach unten und nun wieder 100 nach linkst --> Zielpunkt --> Halbkreis...
    Nur durch $CIRC_TYPE=#BASE hat er beide so geteachten Kreise auch wirklich so nachgefahren, wie ich es erwartet hätte. Wenn ich also einen Stift ans Tool kleben würde, könnte ich damit an eine Wand einen Kreis malen :gutidee:
    ==> Nu gehts aber um Schweißbewegung (ob stechend oder schleppend ist jetzt noch unklar)


    - BASE und TOOL nicht vorgegeben? öhm, also bei den geteachten CIRC bewegungen nimmt er doch TOOL[1]: Schweißpistole und BASE[0]
    ==> Versteh ich da was falsch? Muss ich ihm erstmal sagen, welche BASE er nehmen muss?
    Habe heute mal versucht ihm eine neue BASE zu geben (3P-Verfahren) --> Diesmal quasi ein virtueller Tisch in der X-Y Ebene. Habe diese BASE unter Nummer 2 gespeichert und im Programm dann folgendes geschrieben:
    $BASE=BASE_DATA[2] --> Ist das so schonmal richtig?? Muss ich ihm dann auf der rechten Bildschirmseite auch noch das BASE Koordinatensystem geben oder ist das nur fürs Hand-Verfahren?


    - C_PTP und C_DIS: Verstehe ich jetzt so, dass das die Befehle sind, wenn ich ihm manuell Punkte gebe und ihm den Überschleifmodus sagen möchte, richtig? C_DIS meint dann einen festen Abstand C_Vel eine bestimmte Geschwindigkeit?
    --> Irgendwie fehlt mir in der Doku mal eine richtige schöne Programmieranleitung... Von vielen Befehlen wird überhaupt keine Syntax gegeben... Schätze, die wollen, dass man eine Schulung besucht, oder?


    - Werte A, B und C nicht auf 0 setzen? Tja, wenn ich das mache, dann drehen die Achsen 4-6 total durch. Zum Beispiel bei der unteren Kante meines Quadrats, wo er "nur" entlang der Y-Achse konstant fahren soll drehte sich die Achse A4 auf einmal immer schneller rum, was entweder dazu führte, dass der Robi wegen eines Soll-Geschwindigkeitsfehlers an Achse 4 oder wegen eines zu hohen Getriebemoments an Achse 4 gestoppt wurde... Die Werkzeugspitze eierte bei der Bewegung außerdem wie betrunken die Linie entlang... Das Problem mit dem Stop (Soll-Geschwindigkeit) konnte ich nur beheben, indem ich die Linearbewegung an einer anderen Stelle ausgeführt habe, dadurch musste er bei der Bewegung die Achse A4 nicht so schnell drehen, aber erst als ich A-C fest auf 0 gesetzt hatte blieb die Orientierung so konstant wie ich es wollte.


    NEUE PROBLEME:


    Habe mal probiert eine Bewegung zu einem von mir (Im Hauptprogramm) initialisierten Punkt zu schreiben...


    FRAME ist wenn ich das richtig verstehe ein STRUCT, in dem ich einen Punkt in kartesischen Koordinaten speichern kann.
    ( STRUC FRAME REAL X, Y, Z, A, B, C)


    Es klappt vorne und hinten nicht:


    <DECL> FRAME posi
    FRAME posi
    --> Wie deklariere ich eine Positionsvariable?


    posi = {0,0,0,0,0,0}
    posi = {X 0, Y 0, Z 0, A 0, B 0, C 0)
    --> wie weise ich der Variablen dann Werte zu?


    PTP posi
    LIN posi
    --> Wie fahre ich dann diese Position an?


    ==> Ich habe C programmieren gelernt und bin im Moment dabei C++ zu lernen, aber das hilft mir hier nicht weiter...
    Ich bekomme ständig "Unzulässiger oder nicht bekannter Satz"
    Bei C würde ich jetzt meinen, ich hätte vergessen eine Library zu includen, aber ich schätze mal eher in der Config.dat oder sonst wo muss ich was ändern, kann das sein?





    Soooo, wer es tapfer durchgehalten hat meine inkompetenten Fragen bis hier durchzulesen hat sich wahrlich einen KEKS verdient!


    *einentellerkeksebereitstellt*

    Hallo zusammen!


    Ich habe folgende Aufgabe bekommen:


    Ich soll mir Methoden überlegen, wie man eine Schweißbewegung "um die Ecke" (im 90° Winkel) am besten programmiert, so dass die Bewegung nicht an der Ecke stehen bleibt, sondern der Schweißbrenner flott um die Ecke gedreht wird und flüssig weiterläuft.


    Bin erst seit 1,5 Wochen dabei mit dem Robi zu arbeiten (bin HiWi :liebe029:) und deshalb bräuchte ich Anfängerfreundliche Tipps ;)



    Habe schon irgendwo gelesen, dass man eventuell mit einem Überschleifen von 0% sowas machen kann?


    ============================================================================


    Bisher habe ich nur zwei Progs geschrieben:


    DEF quadrat()
    INI


    PTP HOME Vel=100% DEFAULT


    PTP {X 1600, Y 200, Z 2300, A 0, B 0, C0}
    PTP {X 1600, Y 200, Z 1900, A 0, B 0, C0}
    PTP {X 1600, Y -200, Z 1900, A 0, B 0, C0}
    PTP {X 1600, Y -200, Z 2300, A 0, B 0, C0}
    PTP {X 1600, Y 200, Z 2300, A 0, B 0, C0}


    PTP HOME Vel=100% DEFAULT


    END


    ==> Werte A-C musste ich auf 0 setzen, da der Robo sonst ständig die Orientierung geändert hätte.
    (Hat teilweise dazu geführt, dass zulässige Soll-Geschwindigkeiten überschritten wurden, was zum Abbruch führte)


    ============================================================================


    Zweites Prog:


    DEF kreis()
    INI


    PTP HOME Vel=100% DEFAULT


    $CIRC_TYPE=#BASE


    PTP P1 Vel=100% PDAT1 Tool[1]:Schweisspistole Base[0]


    ; Kreisbewegung durch 2 Halbkreise:


    CIRC P2 P3 Vel= 2 m/s CPDAT1 Tool[1]:Schweisspistole Base[0]
    CIRC P4 P5 Vel= 2 m/s CPDAT1 Tool[1]:Schweisspistole Base[0]


    PTP HOME Vel=100% DEFAULT


    END


    ============================================================================



    Beide Progs lassen den Robi quasi an einer virtuellen Wand einmal ein Quadrat zeichnen und einmal einen Kreis.


    Fragen:


    - Wie kann ich den Kreis flüssig ausführen lassen ohne einen Stop zwischen den Halbkreisen?
    CONTINUE oder Überschleifen haben nichts gebracht


    - Kann mir jemand kurz und knapp erklären welche Befehle benötigt werden, wenn man neben der Bahn auch die Orientierung des Tools steuern möchte?
    ($ORI_TYPE=#CONSTANT $ORI_TYPE=#VAR $CIRC_TYPE=#BASE $CIRC_TYPE=#PATH...)


    - Funktioniert das Überschleifen überhaupt im Betriebsmodus T1 oder T2?




    Schonmal im Voraus vielen Dank und schönes Wochenende! :blumen:

    Darf ich hier kurz eine Zwischenfrage reinschmeißen? Habs nirgends gefunden...


    Ich bin seit kurzem HiWi und soll nen Kuka KR30 L16 mit KRC2 Steuerung programmieren...


    In den Modi T1 und T2 gibt es kein Überschleifen?


    Habe ein Prog geschrieben, dass nur im Auto-Modus tatsächlich überschliffen hat und nicht im T1 Betrieb.

    Ich habe gerade etwas entdeckt, dass mich doch wieder etwas überrascht...


    An vielen Stellen in der Maschine.dat auf R1 Ebene stehen für die Achsen 10-12 Werte drin, wo bei den Achsen 7-9 keine stehen und in der Version von LindePaul stehen dort Nullen. (In meiner ausgedruckten Version fehlen diese Variablen komplett für Achsen 10-12.


    Kann es sein, dass der Spannungsfehler meldet, weil er die Achsen 10-12 ansprechen will, diese aber nicht vorhanden sind oder sowas in der Richtung?


    Wo kann ich prüfen, ob eine der Bremsen blockiert?



    Noch ne Frage: Wenn da steht: SW5.04.00 hab ich dann Software Version 5? Hat da vielleicht jemand Maschinendaten für? Nur zum Vergleich...

    Seit 10 Tagen keine Antwort mehr hier :(


    Tja, so wies aussieht ist irgendwo bei den DSE Karten oder bei den Endstufen irgendwas faul... Oder irgendeine Bremse blockert oder was weiß ich...


    Scheint so als wären die letzten 2 Wochen umsonst gewesen und der Robo muss eingemottet werden


    :wallbash::waffen100::down::bawling:

    Was los Leute? Habt ihr mich vergessen? :bawling:


    Oder wisst ihr auch nicht weiter? :huh:


    Kann ich irgendwie genauer testen, ob das DSE kaputt ist?
    Vielleicht die beiden DSE Karten tauschen?


    Edit: Hab die beiden DSE Karten mal getauscht... Fehler bleibt exakt gleich und auch an der gleichen Stelle.
    Die Karten scheinen in Ordnung!


    Endstufen ebenfalls teilweise mal untereinander getauscht... ausgebaut ... eingebaut ... nichts.
    Auf einer war ein Kondensator geplatzt und eine Stelle war leicht verkokelt, haben 2 Kondensatoren, 2 Dioden und einen Widerstand ausgetauscht...
    Fehler leider immernoch da.

    UND ER LEBT, aber er röchelt noch ;)



    Also, hab die X111 bzw. A3X936 Stecker gebrückt...
    Antriebe ließen sich nun einschalten! :biggrins:


    Folgender Status:


    System läuft, Antriebe lassen sich starten (Nur LED 24 und 31 sind aus), alles ok, ABER:


    - Wenn ich den Zustimmschalter nur ganz kurz antippe, dann blitzt kurz die Meldung Z124 ÜBERSPANNUNG auf und verschwindet aber sofort wieder...
    Auf der rechten PSE springt ebenfalls ganz kurz die rote LED bei Achse A1 (ist dann ja Achse A4) an
    --> Reihenfolge also vermutlich: Überspannung --> Unterspannung A4 --> Unterspannung A5 und A6


    - Wenn ich den Zustimmschalter drücke und gedrückt halte erscheinen die Fehler in folgender Reihenfolge (stehen ja dann von unten nach oben auf dem PHG)


    Z124 ÜBERSPANNUNG
    Z123 UNTERSPANNUNG A4
    Z123 UNTERSPANNUNG A5
    Z123 UNTERSPANNUNG A6
    *NEU: Z121 Überstrom A5 :wallbash:


    ==> Danach: K26 und K28 aus (DSE Fehler und Sammelfehler)


    Das komische ist aber: Es passiert nicht immer! Gelegentlich kommt kein Fehler und ich kann alle 6 Achsen verfahren, dann plötzlich kommen diese Fehler nach unbestimmter Zeit...



    (- Wenn ich das PHG in der Hand habe und am Kabel oben rüttel, dann springt die LED K11 auf K13 und umgekehrt (Not-Aus-Verzögerung)
    --> vermutlich Wackelkontakt)


    Jemand nen Tipp?
    Steuerkarte aus- und wieder eingebaut hab ich --> kein Unterschied


    Sicherungen sind ok.


    Auf der Logikgruppe A2 gibts die LED UB> die ist zwischendurch mal aus... Beim Testen schalte ich den Schrank mehrmals am Tag ein und aus... Irgendwo im Handbuch steht, dass jeder Einschaltvorgang die Ladezeit des Akkus um 2h verlängert??? Heißt das jetzt, wenn ich den Schrank zu oft ein und aus schalte ist irgendwann mein Akku leer?


    Auf gehts, wir stehen kurz davor :supi:

    Hm, ich muss jetzt sowieso erstmal gucken...


    Der Stecker im Bedienerpult... sagen wirs mal so, der endet einfach mal eben im Kabelkanal... ist überhaupt nicht angeschlossen :wallbash::kopfkratz:


    Scheint mir so, als hätten die irgendwo anders einen Anschluss hingelegt...


    Ich werd mal suchen, öhm also ums nochmal deutlich zu fragen: Ich muss den PC also NICHT an den SER1 anschließen? (wenn ich den Kanal nicht öffnen muss...)

    Ich habe APS Arch 1.40 und Windows 98...


    Albrechts Adapter:


    5 7 ---GND----- (Signalmasse)
    2 3 ---RxD----. (Recieve Data - Empfangsdaten
    | von Gegenstelle über DCE zum DTE)
    3 2 ---TxD----' (Transmit Data - Sendedaten vom DTE
    über DCE zur Gegenstelle)
    7 4 ---RTS----. (Reqest To Send - Empfangsbereitschaft
    | des DTE)
    8 5 ---CTS----o (Clear To Send - Sendebereitschaft
    | des DCE)
    9 22 ---RING---' (DCE hat Ruf erkannt)
    4 20 ---DTR----. (Data Terminal Ready - DTE ist prinzipiell
    | bereit, d.h. Port aktiviert)
    6 6 ---DSR----o (Data Set Ready - DCE ist prinzipiell
    | bereit, d.h. eingeschaltet)
    1 8 ---DCD----' (Data Carrier Detect, man ist verbunden)



    Deiner:


    25 pol KRC32 8 pol PC


    RTS 4 ------------- 8 CTS
    CTS 5 ------------- 7 RTS
    TX 2 ------------- 2 RX
    RX 3 ------------- 3 TX
    GND 7 ------------ 5 GND



    Hier im Forum steht auch, dass für die APS 2-2 und 3-3 richtig ist, bei Albrecht steht 2-3 und 3-2, also über Kreuz, das ist irgendwie was völlig anderes oder?



    Die APS Software bzw. Windows meldet mir immer 2207 Fehler bei Verbindungs-Aufbau...
    Habe Kanal Ser1 geöffnet und die Enstellungen in der KRC scheinen ja zu stimmen, die auf dem PC auch...
    Was stimmt denn nicht?
    Das Kabel, das ich hier habe ist so verdrahtet wie bei Albrechts Adapter, nur der 9er Pin ist frei...
    (Bei mir sind also auch 2-3 und 3-2 überkreuzt...)