Wartezeit auf digitalen Eingang begrenzen und Programm fortsetzen .. möglich ?

Moin,

für mein aktuelles BetaTest-Projekt mit einer Kameraprüfung brauch ich wohl früher oder später eine Möglichkeit auf ein Signal eben irgendwann nicht mehr zu warten.

Die Kamera liefert mir nur einen Zustand zurück, nämlich nur TRUE wenn NIO mit anschließender Ausschleusung auf das NIO-Band. Ich muss aber eine gewisse Zeit mit dem Robbi warten, Signalkette.

Angeblich braucht die Cam ca. 80 - 120 ms je nach Lichtverhältnis um ein scharfes Bild zu machen, zu verarbeiten und zu entscheiden ob NIO oder nicht. Wenn das Teil IO ist, kommt nix.

Leider kenn ich mich mit solchen Bilderfassungssystem nicht aus und kann auch aktuell auf keine informative Quelle zurück greifen.

Folgende Ansätze schwirren in meinem Hirn herum;

1. Die Cam muss mir eben auf ein zweites Signal liefern, was mir lieb wäre. Tut sie aber aktuell nicht. (Der Zuständige kennt seine Technik auch noch nicht so gut )

2. WHILE-Schleife mit Zähler und Aussprung; wenn sich der Zustand des Eingang's nicht nach X Durchläufen ändert, Annahme, dass das Teil IO ist. Unsafe .. aber relativ einfach.

3. euren Vorschlag, eure Idee

Mir geht es einfach nur darum, dass der Robbi nicht in irgendwelchen Warteschleifen oder WAIT FOR $IN's hängt. Denn es kommt eben nix

Ich kann auch ziemlich auf auf dem Schlauch stehen ohne das ich es merke.

Danke

Zitat von Hermann

Nur im NIO-Fall ein Signal schicken ist Krampf, wenn schon nur ein Signal, dann doch das IO-Signal, sonst kann man die Prüfung gleich sein lassen.

... tja, das erklär mal dem "Auftraggeber" ... ich verstehe schon, was er will, einfach weiter machen, so lange die Bilder IO sind. Vielleicht bekomme ich den Spieß ja noch gedreht. Aber aktuell im Testaufbau kommt nur NIO-Signal, wenn eben eines der 3 Bilder, die er schlußendlich pro Teil mal machen soll, schei*e ist, soll ausgeschleust werden.

Ich werde nach Möglichkeit alle Lösungsvorschläge mal durch spielen. Das WAIT_FOR mit TIMER_LIMIT von panic_mode liest sich gut, so lange es auf KSS 8.3 auch funktioniert. Das NIO-Signal soll, wenn, wohl innerhalb von 0.25 Sec kommen. Ich wäre dann bei 0.75 Sec plus Zeit für's Umorientieren um 120°.

Ich habe für die gesamte Prozedur geschätzte 5 Sekunden bei IO-Befund, alles darüber wird den Prozess ausbremsen. Bei NIO-Befund, bei dem der Robbi dann noch um 270° in A1 drehen muss, habe ich ja das erklärende Ergebnis für Taktzeiterhöhung auf dem NIO-Band liegen ... Es wird alles gut

Und ich find's gerade richtig interessant, was doch alles so geht

So, das mal aus den mir verfügbaren Fähigkeiten und euren Infos heraus zusammen gefummelte Modul im Ausschnitt ...

IF iGrpOption == 1 THEN
    
    PTP Xcam1 C_DIS
    PTP Xcam2 C_DIS
    LIN Xcam3
      WAIT FOR $IN[111] OR TIMER_LIMIT (0.25)
          IF $IN[111] THEN
          PTP Xcam4 C_DIS ; <-- 
          PTP Xcam5 C_DIS ; <-- Du kannst nicht direkt in's drop_scrap !! Crash !!          
          drop_scrap()
          ENDIF
        LIN $POS_ACT:{x0, y0, z0,a 120,b 0,c 0} 
      WAIT FOR $IN[111] OR TIMER_LIMIT (0.25)
          IF $IN[111] THEN
          PTP Xcam4 C_DIS
          PTP Xcam5 C_DIS          
          drop_scrap()
          ENDIF    
        LIN $POS_ACT:{x0, y0, z0,a 120,b 0,c 0}
      WAIT FOR $IN[111] OR TIMER_LIMIT (0.25)
          IF $IN[111] THEN
          PTP Xcam4 C_DIS
          PTP Xcam5 C_DIS          
          drop_scrap() ; <-- aus drop_scrap kein zurück nach camtest(), Rücksprung in SPS-Lauf mit neuer Homepos aus nachfolgendem Modul, Teil ist eh Schei*e
          ENDIF 
    PTP Xcam4 C_DIS
    PTP Xcam5 C_DIS
    BAS(#TOOL,1); akt 2 -- Post an mich selbst, falschen Greifer geteached, Du Vollhorst ! =.=
    
ELSE
;--- das selbe nochmal für den anderen Greifer und vorerst ohne weitere Auswertung zurück zum Ursprungsmodul ---

da ich ohne Wissen der SPS aus dem normalen Ablauf heraus, das camtest() durchlaufe und dann in ein Modul springe, was aktuell nicht in den Ablauf passt, kann ich aktuell nur hoffen, dass es funktioniert. Jedes Modul fragt den aktuellen Greifer ab und hat eine feste Homepos, die aus jeder anderen Homepos crashfrei erreichbar ist. Der letzte Punkt ist die originale Homepos, von der aus die Prüfung beginnt ... ich find's logisch

Zitat von Hermann

Das ist mir, und wahrscheinlich den meisten anderen auch zu öde.

Also hier keine weiteren Vorschläge von mir.

Bereinigt und ersetzt .. und sry, mir war in dem Moment nach ne'm Screenshot .. an das Code_Tag habe ich nicht gedacht. Bei mittlerweile 18 unterschiedlichen Roboter inkl. deren Programmierern, inkl. deren Denkweisen, einem firmeninternen "Programmierer" der mehr Fragen in seine Module kommentiert, als Hinweise zum Ablauf, kann man das Code-Tag im Forum schon mal vergessen. Asche auf mein Haubt ... Ich gelobe Besserung ...

wow .. das ging jetzt auch schnell ... Projekt eingestellt .. Happy Corona .. Ich pack die Koffer, wo war noch mal ErdeV2.0 ?