Mehrere Fragen bzgl. Datenübertragung

  • Hallo zusammen,


    nach längerer abwesenheit, stehe ich leider wieder vor ein paar kleinen Problemen.


    1. Wie kann ich sicherstellen, dass die Robotersteuerung meine Daten von der seriellen Schnittstelle korrekt empfangen hat?Schicke ich diese einfach per CWrite zurück?



    2. Wann endet der Loop befehl?


    LOOP


    CREAD(HANDLE, Lesestatus, Lesemodus,TIMEOUT,OFFSET,"%r",String[])


    Offset=0
    SREAD(String[],Auswertstatus,Offset,"%d%d%d%d",dx,dy,dphi,geo)


    SWITCH geo


    case 1


    PTP HOME


    case 2


    ptp ablage


    ENDIF
    ENDLOOP


    CCLOSE(HANDLE, Closestatus) ;Kanal schliessen


    PTP HOME


    END


    Nachdem er den Switch befehl durchlaufen hat oder garnicht?


    3. Versuche ich gerade eine Software Doku zuschreiben. Bis jetzt habe ich ein Ablaudiagramm in Visio und ein Lasten und Pflichtenheft erstellt. Wie handhabt ihr das so? Beschreibt ihr da noch einzelne Quellcode teile?


    Gruß
    Blender

  • Schritt für Schritt zum Roboterprofi!
  • zu3)
    ich beschreibe in der Regel nur Teile die relevant sind, dh. .src's mit Bewegung oder direkten Aktionen. Calculationen und Signale/Variablen beschreibe ich in der Regel nicht. Hängt aber auch vom Kunden ab, wie und was er möchte.


    zu 2)
    Da steht noch ein EndIf drin wo mir die If Bedingung fehlt


    zu3)
    ka


    ;)

    Den Roboter "in seinem Lauf hält weder Ochs noch Esel auf!"

  • zu 1. wenn Du das 3964r-Protokoll benutzt kannst du fast sichere Übertragung durch eingebauten BCC-Check.
    wenn Du XONOFF oder pure Datenübertragung nutzt wäre es sicherer einen eigenen Chech einzubauen oder zurüchzuschicken und wieder auf das ok warten bevor zu die Daten weiterverarbeitest.
    zu 2. beim ENDLOOP :P
    das ENDIF soll wahrscheinlich ENDSWITCH heissen
    zu 3. wie AtoK09 schon schrieb - hängt vom Kunden ab :fluch:

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • oh vergessen - vor dem CREAD muss auch noch ein OFFSET=0 stehen.


    eine Fehlerabfrage nach dem CREAD fehlt auch - kannst da schon in einen Timeout laufen

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Hallo,
    das ENDLOOP beendet zwar logisch die Schleife,
    denke aber die Frage war eher so gemeint:
    Wann wird die Zeile
    CCLOSE(HANDLE, Closestatus) ;Kanal schliessen
    ausgeführt?


    Die Antwort dazu: Niemals, ausser man macht im Handbetrieb eine Satzanwahl darauf.


    Hermann

  • die Loop kannst Du beenden,(wenn's sinnig ist) indem du nach dem ENDIF bzw. vermutlich wie Paul meint ENDSWITCH eine Exitbedingung einfügst.


    If bTransferEnd Then
    EXIT
    Endif


    bTransferEnd ist von dir noch zu definieren, dann kannst Du den Loop gezielt verlassen und bei Bedarf die nächste Datenübertragung anfordern.


  • Wann wird die Zeile
    CCLOSE(HANDLE, Closestatus) ;Kanal schliessen
    ausgeführt?


    Genau das habe ich gemeint. :merci:



    die Loop kannst Du beenden,(wenn's sinnig ist) indem du nach dem ENDIF bzw. vermutlich wie Paul meint ENDSWITCH eine Exitbedingung einfügst.


    Da ich ja eh am Anfag des Loop-Befehls in die Homeposition fahre müsste ich ihn ja nicht zwingen beenden. Müsste derCclose-Befehl dann nicht im Loop ausgeführt werden?



    oh vergessen - vor dem CREAD muss auch noch ein OFFSET=0 stehen.


    eine Fehlerabfrage nach dem CREAD fehlt auch - kannst da schon in einen Timeout laufen


    Offset ist gleich null. Habs vergessen mit anzugeben, musste heute schnell gehen. :???:
    Was meinst du denn mit fehlerabfrage?



    Ich benutze das XonXoff Protokoll. Also einen definierten String an den PC und wieder zurück zur KRC1?
    Und es sollte Endswitch lauten. :zwink:


    Einen richtigen Kunden habe ich leider nicht, es ist ein FH-Projekt. :denk:
    Ich hänge morgen das fertige Programm mal mit an.


    Danke für die Antworten.

    Einmal editiert, zuletzt von blender ()

  • Hi Blender,


    ein CCLOSE ist nicht notwendig. Wird nur benutzt wenn die Ausführung der seriellen Übertragung den Interpreter "wechselt". Das heisst Du kommunizierst mal im Submit und dann wieder im RobInterpreter.
    CCLOSE wird automatisch ausgeführt bei Programm cancel oder reset

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Hallo,


    ich bin gestern leider nicht mehr dazu gekommen. Im Anhang jetzt mein erstelltes Prog.


    Dann hab ich noch das Problem, dass ich über das Inlineformular keinen Greifer hinzufügen kann. Wie lässt sich das denn Programmiertechnisch lösen?


    LindePaul
    Was hast du denn mit derFehlerabfrage nach dem Cread gemeint?


    Und ich habe noch ein paar :huh: bezüglich des Software Handshakes per XonXoff.
    Du hast geschrieben, dass man einen eigenen Check einbauen sollte. Wie meinst du das? Einen zusätzlichen Datenaustausch zwischen PC und KRC1? Also einen zweiten String senden?
    Oder meinst du den Befehl WAIT FOR $DATA_SER2>0?


    Danke


    und allen ein schönes Wochenende.

  • Fehlerabfrage: ein Beispiel
    CREAD(HANDLE,STATUS,MODUS,TIMEOUT,OFFSET,"%d",ERG)
    IF (STATUS.RET1<>#CMD_OK) THEN
    HALT ; dann kann man den Status mit "Zeige Variable" genau auslesen.
    ; die möglichen Werte von status.ret1 sind in der CREAD/CWRITE-Doku beschrieben
    ENDIF


    Handshake:
    Daten wieder zurücksenden ist nicht das gelbe vom Ei.
    Das Beste wäre, Du schickst mit dem Telegramm ein eigenes Checkbyte mit.
    Das Checkbyte baust Du selbst auf (z.B alle Sendedaten - ausser Checkbyte- in das Checkbyte
    "XORen oder ANDen oder addieren,...). Auf der KRCseite machst Du das gleiche mit den Empgangsdaten und vergleichst das empfange Checkbyte mit dem eigenen.



    WAIT FOR $DATA_SER2>0:
    schreibt man normalerweise (wenn man nicht mit Interrupt arbeitet) vor dem CREAD damit man nicht in ein TIMEOUT läuft falls mal der Empfang länger ausbleibt.


    Das Problem mit dem Greifer kann ich noch nicht beantworten. Wo ist da genau das Problem ?
    a+ weekend

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein


  • Hab mich gerad mal durch die Entwicklungsumgebung gekämpft! (MS Studio)
    Ich hab ich beim XonXoff die möglichkeit das Paritybit zu setzten, dann setzte ich auf der Robotersteuerung in der ini-datei das Bit auch auf gerade oder ungerade und prüfe im Programmalgorithmus ob es gesendet wurde?Gibt es denn eine Funktion Parity=1 oder was ähnliches?



    Das Problem mit dem Greifer kann ich noch nicht beantworten. Wo ist da genau das Problem ?
    a+ weekend


    Ich Poste den Fehler sobald ich wieder an den Roboter komme.


    gruß
    blender

  • die Einstellung PARITY kannst in der serial.ini einstellen. Das Bit wird bei der Übertragung eines Bytes automatisch von den seriellen Hardwarechips überprüft.
    Bitfehler führt zu einer Meldung "Übertragungsfehler".

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Den Greifer habe ich jetzt am laufen :supi:, weiß leider nicht woran es lag.


    Wie sieht denn der Loop-Befehl im Flußdiagramm aus?Einfach eine Do-While ohne die Abbruchbedingung?



    die Einstellung PARITY kannst in der serial.ini einstellen. Das Bit wird bei der Übertragung eines Bytes automatisch von den seriellen Hardwarechips überprüft.
    Bitfehler führt zu einer Meldung "Übertragungsfehler".


    Reicht das denn zur Überprüfung ob alle Daten richtig gesendet wurden?


    Dank eurer Hilfe ist ein positives Ende diese Projekts in Sicht. :merci:


    Gruß
    Blender

  • Parity: na ja, 1-Bit-Fehler werden erkannt. Reicht meistens aus.
    Wenn Du aber Bewegungsdaten schickst solltest Du vorsichtiger sein - Crashgefahr!!!

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Ok, soweit habe ich jetzt alles fertig.


    Nur stehe ich noch vor einer Frage,


    und zwar muss ich noch beschreiben warum ich die serielle Schnittstelle benutzt habe und nicht das DeviceNet.
    Ich habs einfach versuche zu umgehen, weil ich nicht wusste wie ich das in C programmieren sollte. Oder gibt es da eigene Programmiersoftware?Klar erstmal der Kostenfaktor, nur ist das Bussystem auch vorhanden.


    Gruß
    blender

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden