Black Knight Geschrieben 7. Juli 2019 Autor Geschrieben 7. Juli 2019 18 hours ago, bontango said: Anzahl Stellen auf dem Display wonach sich die Anzahl der Bytes die pro Display gesendet werden berechnet. Wenn du das als Sicherheitsmaßnahme haben möchtest, dann lass uns doch lieber direkt die Anzahl der Bytes nehmen, die für dieses Display übertragen werden. Noch schlechter als wenn Müll auf dem Display dargestellt würde, wäre es ja wenn die Kommunikation zusammenbrechen würde, weil Master und Slave von unterschiedlichen Befehlslängen ausgehen. Deshalb könnte der Master mit diesem Befehl nochmal klarstellen, wieviele Bytes er senden wird, also 32 für ein 16er Alpha, dass über Segmente angesteuert werden soll und 16 für das gleiche Display mit ASCII. Der APC wird dann immer auf diese Anzahl Bytes warten, egal was er intern ausgerechnet hat. Auf diese Weise kann man Bugs vermutlich leichter finden, weil dann wirklich nur das Display und keine anderen Kommandos betroffen sind. 1 hour ago, Snux said: "All Lamps" - fehlen Lamps 01-08. Aber nicht ganz, die sind einfach nicht so hell. Das ist normal, da 'All Lamps' nur für die Spielfeldlampen gilt - muss ich noch in die Doku schreiben. 1 hour ago, Snux said: Ist es veilleicht ein Software (timing) problem, weil die Lampen LEDs sind? Du hast Recht, das klingt nach Software. Hat vermutlich bisher noch niemand bemerkt, da du es als erster mit LEDs benutzt. Stell doch mal bitte in den System Settings 'Dim Inserts' auf Yes, dann werden zwar alle Lampen deutlich dunkler, aber diese 'halb' leuchtenden Lampen sollten dann komplett aus sein.
bontango Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 vor 29 Minuten schrieb Black Knight: Wenn du das als Sicherheitsmaßnahme haben möchtest, dann lass uns doch lieber direkt die Anzahl der Bytes nehmen Oder besser wir spendieren den 'Display Set' Befehlen noch ein Längenbyte, das hatte Jan ja auch schon angeregt
Snux Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 vor 49 Minuten schrieb Black Knight: Das ist normal, da 'All Lamps' nur für die Spielfeldlampen gilt Bei Sys11 (F-14 z.B.) 01-08 sind auch Spielfeldlampen vor 49 Minuten schrieb Black Knight: Stell doch mal bitte in den System Settings 'Dim Inserts' auf Yes, dann werden zwar alle Lampen deutlich dunkler, aber diese 'halb' leuchtenden Lampen sollten dann komplett aus sein. Yup, stimmt so. Ich warte bis es in F-14 richtig montiert ist, um zu sehen ob das nervt oder nicht (dass die dunkler sind). Oder gibt es andere timings-moeglichkeiten?
Black Knight Geschrieben 7. Juli 2019 Autor Geschrieben 7. Juli 2019 1 hour ago, bontango said: Oder besser wir spendieren den 'Display Set' Befehlen noch ein Längenbyte, das hatte Jan ja auch schon angeregt Genau das meinte ich, nur brauchen wir dann nicht zusätzlich auch nochmal die Anzahl der Stellen zu übermitteln. Ich würde dem 0x25 drei Bytes mit schicken: Nummer des Displays, Code Type und das Längenbyte. 46 minutes ago, Snux said: Oder gibt es andere timings-moeglichkeiten? Ja, das kann ich per Software beheben, dann muss ich vor dem Wechseln der Spalte die Zeilen alle auf Null setzen. Das habe ich bei den Displays auch gemacht, aber ich dachte bei den Lampen braucht man das nicht. Dein Lampentester wird da auch extrem empfindlich sein, da die hohe Lampenspannung von 18V lange braucht, um sich über den hohen Vorwiderstand und die LEDs zu entladen. Je nach LED Sorte wird man das bei deiner F-14 also möglicherweise auch gar nicht sehen. Andererseits ist es auch kein großer Aufwand es in der SW zu ändern und dann ist man auf der sicheren Seite. Ich baue das beim nächsten Update mit ein.
Black Knight Geschrieben 7. Juli 2019 Autor Geschrieben 7. Juli 2019 57 minutes ago, Snux said: Bei Sys11 (F-14 z.B.) 01-08 sind auch Spielfeldlampen Oh, Mist. Bei Rollergames und Pinbot ist das nicht so. Dann muss ich das wohl auch noch ändern.
jabdoa Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 vor 10 Minuten schrieb Black Knight: vor einer Stunde schrieb bontango: Oder besser wir spendieren den 'Display Set' Befehlen noch ein Längenbyte, das hatte Jan ja auch schon angeregt Genau das meinte ich, nur brauchen wir dann nicht zusätzlich auch nochmal die Anzahl der Stellen zu übermitteln. Ich würde dem 0x25 drei Bytes mit schicken: Nummer des Displays, Code Type und das Längenbyte. Die meisten Protokolle haben zu einem variablen String immer eine Länge oder einen Terminator. Man kann das auch ohne machen um Bytes zu sparen wie in diesem Fall aber ist m.M. nach unüblich. In der Informatik würde man das zusätzliche Byte in 0x1E - 0x24 spendieren. Ist aber auch ok so wie es ist. 0x25 werde ich in MPF nicht verwenden. Stattdessen wird MPF immer genau das Format senden was die Hardware meldet. Sagt mir einfach wie ihr 0x25 haben wollt dann dokumentiere ich den so.
bontango Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 vor 2 Stunden schrieb jabdoa: Man kann das auch ohne machen um Bytes zu sparen wie in diesem Fall aber ist m.M. nach unüblich. Ich denke auch, lass uns das eine Längenbyte beim Display set Befehl spendieren, und beim 0x25er nur den Typ senden @Black Knight OK?
jabdoa Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 (bearbeitet) Ich habe die ganze Logik heute mal implementiert. Inklusive so Sachen dass er einen Dezimalpunkt in einem Text wie "1337.42" automatisch auf die 7 setzt (wenn das Display das kann). Text ist rechtsbündig aktuell und wird immer links abgeschnitten. Müssen wir vielleicht noch konfigurierbar machen. Mappings habe ich auch für alle Typen. PR ist hier: https://github.com/missionpinball/mpf/pull/1388 vor 8 Minuten schrieb bontango: Ich denke auch, lass uns das eine Längenbyte beim Display set Befehl spendieren, und beim 0x25er nur den Typ senden Das würde ich dann noch einbauen. Jan Bearbeitet 7. Juli 2019 von jabdoa
Black Knight Geschrieben 7. Juli 2019 Autor Geschrieben 7. Juli 2019 1 hour ago, bontango said: Ich denke auch, lass uns das eine Längenbyte beim Display set Befehl spendieren, und beim 0x25er nur den Typ senden Ist mir Recht.
Snux Geschrieben 7. Juli 2019 Geschrieben 7. Juli 2019 Step 5 - OK Houston we have lift-off Mit benchtesting sieht alles gut aus. Naechste Woche habe ich (hoffentlich) Zeit es in F-14 zu setzen. Dann kann ich evtl. mein MPF code testen. Und dann muss ich entscheiden - MPF weiter zu entwickeln oder "APC nativ" probieren. Oder beides
Black Knight Geschrieben 7. Juli 2019 Autor Geschrieben 7. Juli 2019 52 minutes ago, Snux said: Naechste Woche habe ich (hoffentlich) Zeit es in F-14 zu setzen Ich habe übrigens über dein Lampenproblem nachgedacht. Der Lampentreiber scheint nicht schnell genug für deine LEDs zu sein. Man kann das in SW fixen, aber man kann den Treiber auch durch ändern von ein paar Widerständen einfach schneller machen. Momentan tendiere ich dazu, auch die HW zu ändern. Hast du noch ein paar Widerstände da? Wenn dir gerade nach Experimenten ist, dann könntest du R1 ja mal von 15K auf 4.7K ändern und R2 von 3.3K auf 1K. Das macht den Treiber für Spalte 2 über 3x schneller, womit die LEDs dieser Spalte deutlich weniger nachleuchten sollten. Ich werde das aber nächste Woche auch mal probieren und mich wieder melden.
Snux Geschrieben 8. Juli 2019 Geschrieben 8. Juli 2019 vor 11 Stunden schrieb Black Knight: Hast du noch ein paar Widerstände da? Ja, von beiden genau 1 Stueck Bis jetzt habe ich nur mit 5v getestet - ich will sehen, wie es klappt (so wie es ist) in "real-life" in F-14. Dann wissen wir ob es merkbar ist oder nicht...... Hoffentlich heute abend oder morgen hab' ich Zeit dafuer.
Black Knight Geschrieben 8. Juli 2019 Autor Geschrieben 8. Juli 2019 10 hours ago, Snux said: Hoffentlich heute abend oder morgen hab' ich Zeit dafuer. Ich habe zwar keine LEDs, aber wenn man ganz genau hinschaut ist auch bei mir ein leichtes Glimmen zu sehen. Ich habe daher jetzt die Widerstände getauscht, wie ich dir oben beschrieben habe (allerdings für alle Spalten) und noch eine kleinere SW Änderung hinzu gefügt. Damit ist bei mir absolut nichts mehr zu sehen. Ich werde die BOM wohl entsprechend auf die neuen Widerstandswerte ändern, da es eigentlich keinen Nachteil gibt, außer das man 2mA mehr Strom verbraucht.
Snux Geschrieben 8. Juli 2019 Geschrieben 8. Juli 2019 vor 1 Stunde schrieb Black Knight: Damit ist bei mir absolut nichts mehr zu sehen. Super. Dann bestelle ich ein paar Widerstaende Danke fuer Update
Black Knight Geschrieben 14. Juli 2019 Autor Geschrieben 14. Juli 2019 Hallo Jungs, die neue SW Version v0.10 ist online. @Snux Diese Version enthält auch die Änderung im Timing der Lampen Ansonsten habe ich den Display-Teil des USB-Protokolls gemäß unseren Abmachungen geändert. Nochmal zur Zusammenfassung: 0x06 liefert die Anzahl der Displays 0x07 hat die Nummer eines dieser Displays als Argument und gibt den Typ dieses Displays gemäß Ralfs Tabelle zurück (die ersten 4 davon): Quote 1 -> BCD7 (BCD Code für 7 Segment Displays -> ohne Komma) 2 -> BCD8 (BCD Code für 8 Segment Displays -> mit Komma im highbit) 3 -> SEG7 (7 Segment Displays + Komma mit direkter Ansteuerung -> Segmentmuster) 4 -> SEG14 (14 Segment Displays + Punkt + Komma mit direkter Ansteuerung -> Segmentmuster) 5 -> ASCII ( ASCII Code -> ohne Komma) 6 -> ASCII2 (ASCII-> mit Komma im highbit) Mit 0x25 kann man das Protokoll neu setzen, also z.B. ein Segment-Display mit BCD oder ASCII ansteuern. Wenn man 0x25 nicht benutzt, wird das Default-Protokoll gemäß 0x07 erwartet. Der eigentliche Schreibzugriff erfolgt über 0x1e für Display 0 (Credit) und 0x1f für Player 1 bzw. die obere Zeile bei den 16-stelligen 2-zeiligen - das geht bei mir bis 0x22, mehr Displays gibt es bei Williams nicht. Dabei wird nach dem Befehl zuerst die folgende Anzahl der Bytes übetragen, also 7 für ein 7-stelliges Alpha im ASCII Modus und 14 für das gleiche Display im SEG14 Modus. @bontango Ich habe das noch nicht komplett mit dem 4 Alpha + Credit getestet, da ich keine Lust habe, die Platinen zu wechseln. Vielleicht haben wir ja Glück und es klappt bei dir auf Anhieb.
Snux Geschrieben 14. Juli 2019 Geschrieben 14. Juli 2019 So, ich habe die 16 Widerstaende getauscht. Jetzt geht's los in F-14 glaube ich. Ich will mein MPF code testen..... @jabdoa ist MPF-dev soweit? Platform wechseln und dann klappt alles, oder noch nicht? Platform = lisy, oder? Sollen wir hier diskutieren, oder bei MPF-forum?
jabdoa Geschrieben 14. Juli 2019 Geschrieben 14. Juli 2019 vor 59 Minuten schrieb Snux: So, ich habe die 16 Widerstaende getauscht. Jetzt geht's los in F-14 glaube ich. Ich will mein MPF code testen..... @jabdoa ist MPF-dev soweit? Platform wechseln und dann klappt alles, oder noch nicht? Platform = lisy, oder? Sollen wir hier diskutieren, oder bei MPF-forum? Sollte gehen. Switches, Lights und Coils. Segment displays vermutlich noch nicht. Kann ich aber fix noch anpassen (es fehlt noch das Längenbyte).
Black Knight Geschrieben 20. Juli 2019 Autor Geschrieben 20. Juli 2019 @bontango Hallo Ralf, im Pinside Forum möchte jemand einen Gottlieb Tag Team mit dem APC betreiben. Ich habe ihm stattdessen schon Lisy empfohlen, aber er hat wohl gar keine Boards und muss daher alles ersetzen. Ich habe kein Ahnung von Gottlieb und daher angeboten, dich mal nach deiner Meinung zu fragen, mit welchen Problemen er bei seinem Vorhaben voraussichtlich rechnen muss.
bontango Geschrieben 20. Juli 2019 Geschrieben 20. Juli 2019 Hallo Frank, bin seit gestern wieder im Lande, habs grad gelesen. ich schreib mal was dazu auf pinside
Volley Geschrieben 20. Juli 2019 Geschrieben 20. Juli 2019 Ulf hat doch ein Treiberboard und ein Netzteilneu entwickelt. Wäre das was für diesen Fall?
Black Knight Geschrieben 20. Juli 2019 Autor Geschrieben 20. Juli 2019 26 minutes ago, bontango said: ich schreib mal was dazu auf pinside Sehr gut, du bist da eindeutig der qualifiziertere Ansprechpartner. 27 minutes ago, bontango said: bin seit gestern wieder im Lande Das trifft sich ja gut, denn jetzt bin ich für zwei Wochen weg. 😋 Dann können wir nur hoffen, dass ich mir bei deinem Display kein allzu großes Kraut zusammen programmiert habe, denn ich werde keinen Laptop mitnehmen.
bontango Geschrieben 20. Juli 2019 Geschrieben 20. Juli 2019 vor 18 Minuten schrieb Volley: Ulf hat doch ein Treiberboard und ein Netzteilneu entwickelt. Wäre das was für diesen Fall? Denke eher was für LISY_Home, mit Display & Treioberboards von mir, LISY_home ist ja ein LISY80 clone vor 14 Minuten schrieb Black Knight: Dann können wir nur hoffen, dass ich mir bei deinem Display kein allzu großes Kraut zusammen programmiert habe, denn ich werde keinen Laptop mitnehmen. Die zwei Wochen wirds warten können, die Backbox vom Comet ist momentan eh beim 'Leimen' schönen Urlaub!
Snux Geschrieben 20. Juli 2019 Geschrieben 20. Juli 2019 @jabdoa- MPF klappt - fast. https://groups.google.com/forum/#!topic/mpf-users/4CZwsJCQ328
Black Knight Geschrieben 20. Juli 2019 Autor Geschrieben 20. Juli 2019 1 hour ago, Snux said: MPF klappt - fast. Was machen denn die Lampen? Ist das Glimmen weg?
Snux Geschrieben 20. Juli 2019 Geschrieben 20. Juli 2019 (bearbeitet) OK, habe gerade mein F-14 MPF-code nur in attract-modus getestet. Sieht OK aus vor 57 Minuten schrieb Black Knight: Ist das Glimmen weg? So gut wie. Mit "Dim Inserts=yes" total weg. Mit =no gibt's noch ein bisschen, aber kaum merkbar. Ich habe ein paar videos gemacht. Mein handy ist sehr empfindlich - in "real life" sieht man fast nichts. Ich wurde sagen "lass es so". So, mit normal inserts...... look at the red "arrow" inserts on the left. When they are lit, the same blue arrow on the right is very faint lit. Difficult to see. They are one column apart on the matrix. Und selber, mit "dim inserts" Bearbeitet 20. Juli 2019 von Snux
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