Jump to content
  1. FLIPPERSZENE

    1. NEUIGKEITEN & TRATSCH

      Neuigkeiten & Tratsch aus der Flipperszene

      7.8k
      posts
    2. Veranstaltungen

      Turniere, Partys und andere Events

      13
      posts
    3. MITGLIEDER STELLEN SICH VOR

      Ihr seid neu in diesem Forum oder gar neu in der Flipperszene ? Schreibt uns ein paar Zeilen darüber und stellt euch vor.
      Diese Rubrik bitte nicht für Diskussionen verwenden.

      2.5k
      posts
    4. WISSENSWERTES

      Links, Infos, Reparaturhilfen, Teilequellen, Vergleichstypen und -Schaltungen, Flipper FAQ. -Freischaltung erforderlich-

      72
      posts
    5. FLIPPERWELTEN

      Expeditionen ins Reich der Flipper

      2.9k
      posts
    6. SPIELBERICHTE, TIPS UND TRICKS

      Laßt andere an euren Erfahrungen teilhaben. Gute Tipps für mehr Punkte oder versteckte Feinheiten ? Her damit!

      357
      posts
  2. TECHNIK - FLIPPER

    1. REINIGUNG & PFLEGE, RESTAURATION

      Die Farben blass, der Risse viele - dem Zahn der Zeit professionell die Wirkung nehmen. Anleitungen und Anregungen findet man hier.

      4.9k
      posts
    2. TECHNIK - EARLY BALLY/STERN

      Von "Bow and Arrow" bis "Blackwater 100" - die frühen Bally's und Stern's sind hier gut aufgehoben!

      7.4k
      posts
    3. TECHNIK - EARLY WILLIAMS/DATA EAST

      Von Williams "Hot Tip" bis "Dr. Dude" - Von System 3 bis System 11 oder auch für "Laser War" bis "Maverick" - sollte hier der richtige Platz sein

      2.4k
      posts
    4. TECHNIK - WPC BALLY/WILLIAMS/STERN

      Von "Funhouse" bis "Lord of the Rings" - WPC, WPC95 oder Stern ab 1999, hier sollte es rein!

      1.5k
      posts
    5. TECHNIK - GOTTLIEB

      Elektronische Geräte von 1977 (Cleopatra) bis 1996 (Barb Wire) mit System 1, System 80 und System 3 Technik

      1.7k
      posts
    6. TECHNIK - SONSTIGE FLIPPER

      Ihr besitzt ein eher nicht so gebräuchliches Exemplar jenseits der Marktführer wie Zaccaria, Recel oder Bell - Hier sollte man Hilfe finden

      710
      posts
    7. TECHNIK - ELEKTROMECHANISCHE GERÄTE (EM)

      Geräte der ersten Generation - mit den klassischen Zählwerken und unzähligen Relais.

      3.6k
      posts
    8. TECHNIK - REPRO ECKE

      Erfahrungsaustausch und Anleitungen rund um die
      Reproduktion von Teilen wie Plastics, Aufklebern (Decals), etc.

      482
      posts
    9. TECHNIK - BINGOS

      Bingo`s - Enge Verwandte des Flippers. Egal ob mechanisch oder elektronisch, hier kommen alle Bingofreunde auf ihre Kosten.

      325
      posts
    10. Techical - Construct an EM-Pinball Machine

      Construct an EM-Pinball Machine

      22
      posts
    11. 385
      posts
    12. 13
      posts
    13. 1.2k
      posts
  3. MARKTPLATZ

    1. 1
      post
    2. SUCHE FLIPPERTEILE

      Gesuche von Mitgliedern

      4.3k
      posts
    3. VERKAUFE FLIPPERTEILE

      Angebote von Mitgliedern mit Preisangabe (Bitte REGELN beachten)

      658
      posts
    4. SUCHE FLIPPER

      Gesuche von Mitgliedern

      865
      posts
    5. VERKAUFE FLIPPER

      Angebote von Mitgliedern mit Preisangabe (Bitte REGELN beachten)

      1k
      posts
    6. TAUSCHE FLIPPER UND FLIPPERTEILE

      Mitglieder die tauschen möchten

      413
      posts
    7. SUCHE/VERKAUFE/TAUSCHE AUTOMATEN UND TEILE

      Automaten jeglicher Art denen Mitglieder in ihren Gemächern Unterkunft gewähren, aber auch Ersatzteile hierfür, können hier ihren Besitzer wechseln.

      334
      posts
    8. FLOHMARKT / ANGEBOTE UND GESUCHE

      Mitglieder suchen oder haben irgendwelche Dinge, die sie anderen Mitgliedern schenken oder verkaufen möchten. Hier bietet sich dafür die Möglichkeit.

      642
      posts
  4. AUTOMATEN UND SONSTIGES

    1. NEUIGKEITEN & TRATSCH - AUTOMATENBEREICH

      Neuigkeiten & Tratsch aus der Automatenszene

      113
      posts
    2. AUTOMATENWELTEN

      Expeditionen ins Reich der Automaten

      351
      posts
    3. 122
      posts
    4. 72
      posts
    5. TECHNIK - SONSTIGE AUTOMATEN

      Neben Flippern und GSG gebt ihr noch anderen Automaten ein Zuhause? Technische Fragen dazu hier hinein.

      164
      posts
    6. TECHNIK - DIVERSES

      Hilfe bei allgem. Problemen mit Werkzeugen, Elektr(on)ik oder Mechanik, welche nicht irgendeiner der anderen Rubriken zugeordnet werden können.

      840
      posts
  5. ALLGEMEINES

    1. ALLES AUSSER FLIPPERN

      Wichtige Dinge ausserhalb der Flipperwelt

      3.1k
      posts
    2. MITNEHMEN / UNTERSTELLEN

      Ob Backglass, ein ganzes Gerät, oder der freundliche Flipperfreak von nebenan - für alles gibt es hier meist eine Transport- oder Asylmöglichkeit .

      427
      posts
  6. DAS FORUM

    1. ANKÜNDIGUNGEN UND FAQ's FÜR DAS FORUM

      Ankündigungen sowie häufig gestellte Fragen (nur lesen)

      10
      posts
    2. ANREGUNGEN UND FRAGEN FÜR DAS FORUM

      Verbesserungsvorschläge, Fragen und Fehlermeldungen bzgl. des Forums

      609
      posts
  • Who's Online   0 Members, 0 Anonymous, 5 Guests (See full list)

    There are no registered users currently online

  • Beiträge

    • Ja denke auch, lass uns das mal auf beiden Seiten implementieren und schauen was passiert
    • Ja genau, das meinte ich. Ich wollte zwar, dass der APC die Anzahl der Bytes schickt die er im Sendepuffer hat, aber du hast Recht; es macht mehr Sinn den APC die Anzahl der empfangenen Bytes bestätigen zu lassen. Ja, lass uns mal mit 1ms starten. Ich rechne sowieso damit, dass dieser Mechanismus nur nach Soundkommandos zum Einsatz kommen wird. Ansonsten ist der APC vermutlich schnell genug. Dann sähe unsere initiale Kommunikation also wie folgt aus: Lisy: 0x00 APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten APC: 0x01 (Bestätigung des empfangenen Bytes), dann "APC\0" als Antwort Lisy: 0x40, 0x01, 0x02 (Lese Setting 2 aus Gruppe 1) APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten APC: 0x03 (Bestätigung der empfangenen Bytes), dann den Wert des Settings als Antwort   Falls irgendwas schief geht antwortet der APC mit 0xff Das müsste es doch sein, oder?
    • Ja, läuft 🙂 Es ist halt wie immer: kaum macht mans richtig funktioniert es. Zum Protokoll: wie wäre es wenn Du als Slave immer als erstes Byte einen Status zurück gibst? Mögliche Werte: 0 : nicht bereit/beschäftigt  -> Master wiederholt Befehl nach Wartezeit ( wie lange soll ich warten, 1ms ? ) Anzahl empfangener Bytes -> Befehl angenommen und ausgeführt ( Minimum 1 ) -1: Befehl angenommen aber Interpretationsprobleme :  Error
    • Ja, genau. Der Kommentar dazu ist Revert to 'Sel14 added for HW_ext'.
    • Ist das die aktuelle 14er Github Version? Dann würde ich die nochmal runterladen um meinen Startscript zu testen.
    • Ja, das ist auch meine Befürchtung. Das könnte bei Sound Kommandos Probleme geben, denn das Öffnen eines Files kann da wohl leicht 10ms und mehr dauern. Aber lass es uns probieren, vielleicht haben wir ja Glück. Übrigens ...  mit deiner geänderten getDIPfromAPC und meiner ursprünglichen Version 'Sel14 added for HW_ext' funktioniert es jetzt einwandfrei 🤪 Aber ich bin auch der Meinung, dass wir es durch eine Synchronisierung stabiler machen können. Ja, langsam nervt's. Ich hatte ja auch gehofft, dass wir uns bald mal in Volleys Halle treffen könnten aber das wird ja wohl erst mal nix. Bin gespannt, was du ausbrütest.
    • Ja, die Arduino IDE ist leider ziemlich rudimentär. Ich persönlich nutze ein Arduino Plug-In für Eclipse und bin damit sehr zufrieden. Wenn du Eclipse noch nicht kennst wird das etwas Eingewöhnungszeit brauchen, aber das ist eine professionelle IDE, die jede Menge nützliche Funktionen bietet. Allein der eingebaute Debugger ist den Einstiegsärger wert und hat mich schon so manch hartnäckigen Fehler finden lassen. Anhalten ist nicht möglich, da du dann dein ganzes Programm anhalten würdest und du willst ja, dass z.B. Lichteffekte u.ä. weiter laufen. Aber mit deinem Timer bist du auf dem richtigen Weg. Die Funktion selbst läuft nicht mehr, sie wird nur durch den Timer wieder aufgerufen. Da die Routine von sich aus nicht weiß, dass der Timer läuft wird sie sich genauso verhalten wie beim ersten Aufruf. Wenn du dir mein BlackKnight Beispiel ansiehst, dann wird in ClearOuthole ein BlockOuthole Flag gesetzt, welches einen erneuten Durchlauf der Routine verhindert und erst später zurückgesetzt wird, wenn der Ball in die Truhe geschossen wurde u.s.w. Da du ja keine Balltruhe o.ä. in deinem Flash hast braucht dein NewBall eigentlich keine Balls Variable und du könntest mit dieser deinen Status signalisieren. Was ich damit meine ist folgendes: Ich nehme an, du hast in deinem GameMain sowas wie case 48: // outhole WF_NewBall(0); break; dann wird dein NewBall mit dem Parameter Null aufgerufen, wenn er jetzt eine entsprechende Abfrage hat void WF_NewBall(byte Status) { // release ball (Event = expected balls on ramp) static bool Block; if (QuerySwitch(48)) { if (Status) { // wait time already passed? Block = false; // remove block ActivateSolenoid(40, 1); //Give Ball ShowAllPoints(0);} else { // called from GameMain if (!Block) { // block not set? Block = true; // set it ActivateTimer(250, 1, WF_NewBall);}}} // call timer else { // switch 48 not active any more Block = false;}} // remove block dann kannst du damit unterscheiden, ob er vom Timer oder GameMain aus aufgerufen wurde. In diesem Fall bedeutet Status = 0 einen Aufruf von GameMain, dabei wird die Block Variable gesetzt um weitere Aufrufe aus GameMain zu blockieren. Dieser Block wird nur aufgehoben, wenn der Timer abgelaufen ist und NewBall daher mit dem Parameter 1 aufgerufen wird oder wenn Switch 48 nicht mehr aktiv ist. ActivateTimer() gibt dir ja die Nummer des Timer zurück. Diese könntest du speichern und den Timer einfach bei Bedarf mit KillTimer beenden. Das ist allerdings eine recht unsanfte Methode, bei der man immer den Überblick über seine Timer behalten muss, damit man nicht den falschen Timer killt. Ich baue solche Routinen daher meisten so ähnlich wie PB_EyeBlink aus Pinbot.ino. Der für dich wichtige Teil ist dieser: void PB_EyeBlink(byte State) { static byte Timer = 0; if ((State > 1) || ((State == 1) && !Timer)) { // do your blinking here Timer = ActivateTimer(500, State, PB_EyeBlink);} else { if (!State) { if (Timer) { KillTimer(Timer); Timer = 0;}}}} Durch die statische Timer Variable weiß die Routine immer, ob sie schon gestartet wurde (Timer != 0) oder ob es der erste Aufruf ist (Timer == 0). Will man die Blinkerei starten dann ruft man PB_CycleDropLights(1) auf. Wenn der Timer schon läuft (Timer !=0) dann passiert gar nichts, d.h. die Routine ist geschützt gegen versehentliches mehrfaches starten. Läuft der Timer dagegen noch nicht, dann wird meine Blinkerei ausgeführt und danach ein neuer Timer aufgerufen, dessen Nummer in Timer gespeichert wird. Hat State beim Aufruf einen Wert größer 1, dann ist die Routine vom eigenen Timer aufgerufen worden und geht direkt zum Blinkteil. Dieser kann State-Werte größer 1 also für sich nutzen. Will man die Blinkerei beenden, dann ruft man PB_EyeBlink(0) auf. Die Routine prüft dann, ob ein Timer läuft und beendet diesen ggfs., sie ist also auch gegen versehentliches mehrfaches Beenden geschützt. Ich hoffe, das hilft dir weiter. Mit Lisy und System 4 müssen wir den Ralf mal ganz lieb fragen, vorausgesetzt er spricht noch mit mir nachdem ich ihn mit I2C Problemen gequält habe. 🙄
    • Ich denke das Umschreiben ist keine grosse Sache. Beim derzeitigen Protokoll gefällt mir eh nicht dass keine Bestätigung erwartet wird. Das führt immer dann zu Problemen wenn die Kommunikation 'aus dem sync' geht dann hat mein keine Möglichkeit mehr in den sync zu kommen und unvorhersehbare Dinge können passieren. Ich würde daher eher immer eine Antwort schicken lassen auf die der Master dann wartet. In der ersten Version als 'blocking' d.h. der Master wartet (recht lange) auf die richtige Antwort und macht nichts parallel. Das wäre wesentlich für mich wesentlich einfacher zu implementieren, muessen dann nur schauen ob es 'ruckelt' Ich überlege mir mal was, eventuell schon Heute Abend, Pokern fällt ja wegen Corona aus 😐
    • Da das Problem etwas umfangreicher und die Antwort daher auch etwas länglich geworden ist, habe ich sie jetzt in den APC 3.0 thread geschrieben, wo sie ja auch eigentlich hin gehört.
    • Habe mich mal ein bisschen mit unseren I2C Problemen beschäftigt und sehe die Sache wie folgt: Wenn der Master eine Antwort des Slave anfordert, dann muss dieser normalerweise sofort antworten. Daher ruft die Arduino I2C Library in diesem Fall eine Interruptroutine auf, innerhalb derer die Antwort geschrieben werden muss. Das ist ziemlich blöd für mich, da meine APC SW ja noch einigen anderen Kram zu tun hat und die Antwort daher möglicherweise ein paar µs länger braucht. Eigentlich hatte ich gehofft, dass die Library das sogenannte  'Clock Stretching' nutzen würde - dann blockiert der Slave einfach die Clockleitung, um dem Master zu signalisieren, dass er mehr Zeit für die Antwort braucht. Daher wollte ich den Interrupt nur nutzen um ein Flag zu setzen und damit zu signalisieren das eine Antwort erwartet wird, also sowas wie: #include <Wire.h> bool RequestReceived = false; void setup() { Wire1.begin(68); // join i2c bus with address #2 Wire1.onRequest(requestEvent); // register event } void loop() { if (RequestReceived) { // write data if flag is set const byte Text[5] = {65, 80 , 67, 0, 178}; static byte i; Wire1.write(Text[i]); i++; RequestReceived = false; }} // function that executes whenever data is requested by master // this function is registered as an event, see setup() void requestEvent() { RequestReceived = true; } Das funktioniert aber leider nicht, da die Library einfach irgendwas anderes sendet wenn innerhalb der onRequest-Routine kein Schreibbefehl erfolgt. Jetzt könnte ich versuchen, einfach alles innerhalb der Interrupt-Routine zu erledigen und zu hoffen, dass die Library so lange clock stretching macht, bis ich damit fertig bin. Allerdings hätte ich dann eine große Menge Code im Interrupt, der irgendwann asynchron ausgeführt wird und das könnte mein ganzes System durcheinander bringen. Das basiert nämlich darauf, dass ich einen Hardware-Interrupt habe, der die HW des Flippers steuert und der sicher jede 1ms läuft. Alles andere läuft außerhalb dieses Interrupts und teilt sich die übrige Prozessorzeit. Soweit zum Problem. Wie können wir das nun lösen? Mein Vorschlag wäre, dass der Master (Lisy), wenn er eine Antwort erwartet, zunächst immer nur ein Status-Byte abfragt. Durch dieses könnte der Slave (APC) ihm anzeigen, wie viele Bytes sich im Sendepuffer befinden. Ist die Antwort Null, dann ist der APC noch nicht soweit und Lisy müsste bei nächster Gelegenheit erneut fragen. Andernfalls weiß Lisy durch die Antwort gleich, wie viele Bytes es zu erwarten hat und kann direkt die entsprechende Anzahl anfordern. Ich wäre sogar dafür, auch bei Befehlen die keine Antwort des APC erfordern eine entsprechende Anfrage zu machen, bevor Lisy den nächsten Befehl sendet (da könnte man als Antwort 0xff oder sowas zurückschicken wenn das Kommando abgearbeitet wurde). Dadurch könnten wir sicherstellen, dass Lisy kein neues Kommando sendet bevor das alte abgearbeitet ist und dadurch das Problem des nur 32 Byte großen Empfangspuffers der Arduino Library umgehen. Das würde sicherlich für mehr Datenaufkommen auf dem I2C Bus sorgen, aber wir könnten die Clockfrequenz ja von 100KHz eine Stufe hoch setzen. Der Vorteil wäre aber, dass Lisy immer die volle Übersicht hätte, was gerade passiert und ein Puffer-Überlauf auf APC-Seite nicht mehr passieren kann. So, das war jetzt ein mittlerer Roman. Wie ist denn deine Meinung dazu? Ich bin mir bewusst, dass das auf Lisy-Seite etwas Arbeit verursacht, aber ich halte es für eine sichere Lösung. Denn wenn jemand z.B. eine SD-Karte mit sehr langen Dateiöffnungszeiten verwendet, dann kann bei unserer USB-Lösung theoretisch immer noch der Empfangspuffer des APC überlaufen und er hätte keine Möglichkeit Lisy davon zu informieren - das wäre mit meinem Vorschlag ausgeschlossen. Aber vielleicht hast du ja auch noch eine bessere Idee ...
    • Danke Frank, habe sie gefunden bei Karin.👍
    • Schau mal bei Karin (thepinwitch.com), die hat die richtigen im Programm!
  • Themen

  • Upcoming Events

    No upcoming events found
  • Recently Browsing

    No registered users viewing this page.

  • Today's Birthdays

    1. Mr.Tilt
      Mr.Tilt
      (44 years old)
  • Member Statistics

    • Total Members
      1,110
    • Most Online
      30

    Newest Member
    MarcKensa
    Joined
×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines