LeFreak76 Geschrieben 27. September 2020 Autor Geschrieben 27. September 2020 vor 48 Minuten schrieb Volley: Das ist NICHT richtig! Boppelbonus gibt es wenn die Lanes 1,2 und 3 durchlaufen wurden. Aber die Reihenfolge ist egal! Danke für den Hinweis das hatte ich so auch nicht geschrieben. Die Reihenfolge ist natürlich egal. Ich habe ein Verdrahtungsproblem oder etwas anderes. Bei Reihe sprach ich von den Lamp Rows und nicht der Reihenfolge. Daher aktiviert ein TurnOnLamp(x) aktuell alle Lampen der Row. Allerdings war dein FolgePost Gold wert, da ich bisher davon ausging, dass 1-4 nach dem Ball generell gelöscht werden. Da es aber später eh eine eigene Funktion wird kann ich das nun gut mit einfließen lassen 😃. Danke Jan
Black Knight Geschrieben 28. September 2020 Geschrieben 28. September 2020 vor 12 Stunden schrieb LeFreak76: Ich habe ein Verdrahtungsproblem oder etwas anderes. Hast du bei der Verdrahtung denn irgendwas geändert? Im Prinzip heißt das ja, dass die Lampen alle am gleichen LampStrobe (Column) hängen.
LeFreak76 Geschrieben 28. September 2020 Autor Geschrieben 28. September 2020 Die Verdrahtung ist original. Es scheint eher das die Colums nicht „Takten“ sondern dauerhaft High bzw Low sind. Wenn ich mit meinem Code Rollover 1-4 auslöse leuchten hinterher die kompletten Rows 4-7 also 32 Lampen. Das kann eigentlich nur gehen wenn die Row ein festes Potential hat. Ich werde heute Abend mal mit dem Oscilloscope prüfen was da an den Pins passiert. Jan
Volley Geschrieben 28. September 2020 Geschrieben 28. September 2020 Man kann das speichern auch abschalten im Menue! Bei Williams heisst das immer Con/Lib, in diesem Fall dann spieichern bei Lib und löschen bei Con....
Black Knight Geschrieben 28. September 2020 Geschrieben 28. September 2020 vor 4 Stunden schrieb LeFreak76: Das kann eigentlich nur gehen wenn die Row ein festes Potential hat. Dann müssten die Lampen aber immer heller werden umso mehr du davon in einer Row einschaltest. Wenn du z.B. 'Rollover 1' und die '10,000 Bonus' Lampe gleichzeitig einschaltest, dann müsste die gesamt Row 4 deutlich heller werden. vor 4 Stunden schrieb LeFreak76: Ich werde heute Abend mal mit dem Oscilloscope prüfen was da an den Pins passiert. Man darf gespannt sein.
LeFreak76 Geschrieben 28. September 2020 Autor Geschrieben 28. September 2020 Bevor ich nun Oszilliere... prüfe ich erstmal die Hardware. Als die Verkabelung stimmt, 2J5 und 2J7 sind von den Keys und Signalen korrekt belegt. Lediglich die Column1 existiert beim Flash nicht. Bei genauerer Betrachtung des LampDriver Schematics kann es also entweder der 74HCT377 sein oder ich habe mir mit den IRF7341 einen gebacken. Das muss ich nun vorerst prüfen. Wenn ich das Datasheet richtig deute, könnte es sein , dass ich die 4 Stück falschherum eingebaut habe. Dann hat es zum einen vermutlich das 74HCT377 hinter sich, und die Lampenspannung würde dann nicht unter Q9A an Pin 7&8 ankommen sondern an 4&3 und dann über die eingebaute Diode gegen Pin5 an Masse liegen. (Ich befürchte SMD Basteleien...) Ich melde mich wenn ich genaueres weiß. Jan
Black Knight Geschrieben 28. September 2020 Geschrieben 28. September 2020 vor 49 Minuten schrieb LeFreak76: Bei genauerer Betrachtung des LampDriver Schematics kann es also entweder der 74HCT377 sein oder ich habe mir mit den IRF7341 einen gebacken. Moment, bei dir bleiben doch vermutlich die Columns stehen und das würde auf einen Fehler bei den IRF7316 hindeuten.
LeFreak76 Geschrieben 28. September 2020 Autor Geschrieben 28. September 2020 Du bist mein Held! Die SMD Treiber sind alle richtig, und auch U6 sieht gut aus. Der Tipp mit den Columns war aber Gold richtig... ich werde dann mal U3 um 180grad drehen 😖 ich hoffe er hat es überlebt. Jan
LeFreak76 Geschrieben 29. September 2020 Autor Geschrieben 29. September 2020 Alles hat es überlebt. Nun sieht der AttractMode zwar nicht mehr sehr eindrucksvoll aus aber die Lampen reagieren nun wie gewollt. Nun werde ich mal das Programm erweitern. (BallEnd) und dann Punkte Bonus und Logik. Dazu werde ich mal die PinBot und BlackKnight scripte anschauen und anpassen. @Black Knighteigentlich müsste es doch gehen wenn ich die BallEnd Funktion im GameMain an den Switch vom Outhole (48) hänge und dann dort prüfe was Sache ist. Du löst sie ja immer erst nach dem Ballzählen aus. Jan
Black Knight Geschrieben 29. September 2020 Geschrieben 29. September 2020 Ja der AttractMode ist nicht so spannend, aber macht hoffentlich deutlich wie's funktioniert. vor 4 Stunden schrieb LeFreak76: eigentlich müsste es doch gehen wenn ich die BallEnd Funktion im GameMain an den Switch vom Outhole (48) hänge und dann dort prüfe was Sache ist. Ich würde den BallEnd an deiner Stelle ganz raus nehmen; die Hälfte davon beschäftigt mit einen Ballverlust während des Multiballs - alles Ballast den du nicht brauchst. Wie oben schon erwähnt, würde ich bei einem Ball im Outhole zunächst mal sowas wie if (Ball < APC_settings[NofBalls]) { Ball++; ActivateSolenoid(40, 1);} else BC_AttractMode(); machen und das dann erweitern.
LeFreak76 Geschrieben 17. Oktober 2020 Autor Geschrieben 17. Oktober 2020 Hallo von mir mal wieder an dieser Stelle. Ich verfolge mit großem Interesse natürlich auch den APC3.0 Thread 😉. Leider ist da aber auch noch nicht das System 4 für LISY aufgetaucht... Ich habe die letzten Wochen damit verbracht Stück für Stück am Code zu basteln um dem ganzen ein wenig mehr Leben einzuhauchen Bonus Berechnungen funktionieren soweit ganz gut. Inzwischen konnte ich auch klären warum die Arduino IDE manchmal sehr merkwürdige Fehler auswirft das angeblich Variablen in der APC.ino nicht deklariert sind. Dies hing bei mir zu 100% daran, dass ich irgendwo ein Semikolon oder eine Klammer in meiner "Flash.ino" vergessen hatte. Seit ich den Code nun mit Notepad++ bearbeite springen einem diese Fehler dann aber glücklicherweise schnell ins Auge. Derzeit kämpfe ich aber (mal wieder) mit grundlegendem. @Black Knight Ich versuche es mal so zu Schreiben, dass es verständlich wird. Gibt es eine Möglichkeit "Funktionen" (z.B. void TT_GameMain(byte Event) ) anzuhalten? Ziel ist es die Schalter zu "entprellen". In meiner eigenen "NewBall" Funktion mache ich es so wie du bei deinen Codes. void WF_NewBall(byte Balls) { // release ball (Event = expected balls on ramp) if (QuerySwitch(48)) { ActivateSolenoid(40, 1); //Give Ball ActivateTimer(250, 1, WF_NewBall); // Be sure its gone } ShowAllPoints(0); ... Ich warte also 250ms bevor ich weitermache und bin der Meinung, so ein wiederholtes Triggern der NewBall zu umgehen, da die Funktion ja noch läuft. Aber das Prellen des Switch 48 sorgt dafür, dass der GameMain Code auch auf die 48 (Outhole) reagiert und demnach bei mir BallEnd auslöst. Da in dieser BallEnd Funktion das Zählen der Bälle und das Wechseln der Player passiert, startet das Spiel immer mit Ball 2... Im Endeffekt möchte ich gerne, dass zu der Zeit wo der die NewBall Funktion läuft, die GameMain gestoppt wird und damit inaktiv ist. Dies würde auch bei dem anderen Problem helfen, dass ich bei einem neuen Ball die Droptargets resette. Hierbei wird dann aber auch der Schalter der Drops in der GameMain ausgelöst was zu Punkten führt obwohl noch gar nichts passiert ist. Ebenso habe ich eine Funktion geschrieben, die die Pfeile vor den Droptargets durchschaltet. Diese rufe ich auf beim case 3: der AttractModeSW Funktion einmalig durch WF_DropMarker(0); auf. void WF_DropMarker(byte Event) { //This must changer the lit Arrow in a specified interval for (i=30; i<= 32; i++) { //3er Reset TurnOffLamp(i); } for (i=25; i<= 29; i++) { //5er Reset TurnOffLamp(i); } TurnOnLamp(30+Event%3); //3er TurnOnLamp(25+Event%5); //5er if (Event == 15){ Event=0; } else { Event++; } ActivateTimer(2000, Event, WF_DropMarker); } Die Funktion läuft also unendlich da sie sich immer wieder selbst aufruft. Auch diese möchte ich gerne beenden wenn ich wieder in den AttractMode nach dem letzten Ball wechsle oder spezielle Animationen der Lamps starte (z.B. bei einem Extra Ball - bisher nur eine Idee 😉 ). Ich hoffe das Problem oder der Wunsch sind verständlich ausgedrückt und noch viel mehr hoffe ich auf einen Lösungsansatz für mein Problem. Danke Jan
Black Knight Geschrieben 18. Oktober 2020 Geschrieben 18. Oktober 2020 vor 18 Stunden schrieb LeFreak76: Seit ich den Code nun mit Notepad++ bearbeite springen einem diese Fehler dann aber glücklicherweise schnell ins Auge. 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. vor 18 Stunden schrieb LeFreak76: Gibt es eine Möglichkeit "Funktionen" (z.B. void TT_GameMain(byte Event) ) anzuhalten? 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. vor 18 Stunden schrieb LeFreak76: bin der Meinung, so ein wiederholtes Triggern der NewBall zu umgehen, da die Funktion ja noch läuft. 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. vor 19 Stunden schrieb LeFreak76: Die Funktion läuft also unendlich da sie sich immer wieder selbst aufruft. Auch diese möchte ich gerne beenden 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. 🙄
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden