Zum Inhalt springen

Flash Wiederbelebung


LeFreak76

Empfohlene Beiträge

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Antworten 61
  • Erstellt
  • Letzte Antwort

Top-Benutzer in diesem Thema

  • LeFreak76

    31

  • Black Knight

    21

  • bontango

    6

  • Volley

    4

Top-Benutzer in diesem Thema

Veröffentlichte Bilder

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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 

Link zu diesem Kommentar
Auf anderen Seiten teilen

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....

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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 

Link zu diesem Kommentar
Auf anderen Seiten teilen

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

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

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

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. 🙄

Link zu diesem Kommentar
Auf anderen Seiten teilen

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 erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden

×
×
  • Neu erstellen...

Wichtige Information

Datenschutzerklärung und Registrierungsbedingungen