LISY API v 0.10

[bontango]

Ich habe 'hinter den Kulissen' mit Lucky1 über eine Erweiterung der LISY API diskutiert.

Hintergrund ist dass wir einen Befehl brauchen der die angeschlossene HW konfiguriert.

( @Volleyich glaube es macht Sinn die Beiträge von Lucky zu seiner HW aus dem 'APC Monsterthread' in einen eigenen zu schieben?! )

Ich sage 'wir' weil ich das für LISY35 und Lucky für sein HW Projekt braucht da beide unterschiedlich HW Plattformen

bzw. HW Varianten unterstützen. So hat Bally z.B. unterschiedlich Ports für die Ansteuerung der Switchmatrix

genutzt, die man je nach Gerät umschalten muss; Lucky unterstützt gar verschiedene WPC Platinen

 

Ich möchte das hier zur Diskussion stellen

Wie wäre es denn mit einer Erweiterung der 'special rules', da haben wir schon 0x3C, wir fügen dann 0x3D dazu

//special rules

#define LISY_S_SET_HWRULE 0x3C //Configure Hardware Rule for Solenoid

#define LISY_S_SET_CFGHW 0x3D //Configure Hardware 'Variation'

im Befehl dann:

Byte 1: len

Byte 2:      ID: 0x01=LIYS35; 0x02='deine Hardware'; 0x03= ....

byte 3...<n>: special config parameter

Dann ist jeder Entwickler flexibel ( ab byte 3 ), aber jedes System hat eine eigene HW ID.

Was  meint Ihr?

btw:

@jabdoa ich habe immer noch das Thema 'Dokumentation LISY API' auf meiner Agenda stehen 🙄

Du hattest ja gesagt dass es am einfachsten wäre wenn ich die mission pinball docs auf github forke

und dort die Änderungen mache. Die Doku LISY API 0.09 muss ja noch korrigiert werden.

 Mache ich gern und macht ja auch Sinn die Doku an einer Stelle zu haben, aber

Könntest Du das kurz 'for dummys' erläutern was die einzelnen Schritte sind, ist für mich Neuland.

Den Fork habe ich gemacht, aber wie mache ich am einfachsten die Änderungen (Themy WYSIWYG Editor?)

und wie push ich die .. ?

 

 

 

[jabdoa]

Wie man die Dokumentation ändert ist hier beschrieben: http://docs.missionpinball.org/en/dev/about/contributing_to_mpf_docs.html. Hilft das? Im Grunde kannste es im Browser bearbeiten in github.

Zu dem Command: Ich bin persönlich ein Freund von Semantik. Wenn möglich ziehe ich Commands mit klarer Semantik vor. MPF supportet bereits Platformen aus allen Generationen von Maschinen und ich würde behaupten dass die Hardware Rules in LISY vollständig sind für alle Generationen. Wofür soll der Command hauptsächlich sein? Setzen von globalen Hardware Optionen? Wofür brauchen wir die ID? Jede Hardware würde ja nur die eigenen Optionen implementieren oder? Und die Hardware meldet sich ja Initial mit ihrem Namen also weiß ich auch welche es ist.

 

Jan

[bontango]

Ja, die Doku hilft schon mal, damit käme ich klar. Nur das edititieren der 'csv' Tabellen ist etwas umständlich, geht das nur 'von Hand' ( kein WYSIWYG  ?)

muss ich mich also mit dieser Syntax herumschlagen

.. csv-table:: Command 0x00 - Get Connected Hardware
   :header: "Byte", "Length", "Example", "Comment"
   :widths: 10, 10, 10, 30

oder übersehe ich was?

 

Zum command mal ein Beispiel wofür ich denke

Bally unterstützt normalerweise 40 Switches und nutzt dafür die Strobes 0 ..4. Für manche Geräte reichten die 40 Switches nicht aus

und Bally hat einen fünften Strobe 'dazugefrickelt' um dann 48 Switches unterstützen zu können. dafür nutzten sie einen Ausgang der normalerweise

den 'Continuous Solenoids' zugeordnet ist. Um die sache noch komplizierter zu machen nutzen unterschiedlich Geräte unterschiedliche Ausgänge

der Cont. Solenoids. So nutzt z.B. Medusa J4-PIN8 und Centaur J4-PIN5 für Strobe 5.

Für LISY habe ich eine interne Tabelle die die Ausgänge umschaltet je nachdem welches Game emuliert werden soll, bei MPF bzw. über die LISY-API

ist das aber nicht bekannt und man muss sich entscheiden welche 'HW config' man nehmen will.

Beides ist ja LISY35 aber mit verschiedener Ausprägung, angepasst an die angeschlosse Hardware

Ähnliches hat Bally veranstaltet um z.B. mehr Displays und/oder mehr Digits zu unterstützen, auch hier muss man Ausgänge je nach game Umschalten.

 

@Lucky1kannst du kurz erläutern was bei Dir 'umgeschaltet' werden muss?

 

Aber ich bin bei Dir, klare Semantik wäre besser, hast Du da nen Vorschlag, evtl. basierend auf Dingen Du Ihr schon ähnlich supported?

 

[Lucky1]

vor 3 Minuten schrieb bontango:

@Lucky1kannst du kurz erläutern was bei Dir 'umgeschaltet' werden muss?

Meine Platine kann für 3 Generationen (WPC89/WPC-S/WPC95) als Drop-In Replacement genutzt werden.
Allein beim WPC 89 ist J204 bei den ganz frühen Geräten zur Ansteuerung der Alphanumerischen Displays genutzt.
In ganz neuen Geräten wird dieser Anschluß aber dann zur Ansteuerung zusätzlicher Hardware mittels des AUX8 Boards
genutzt. Ahnliches zum Power Driver Board Anschluß J211. Dort wird bei WPC89 eine Gruppe zur Abfrage von Switches benutzt,
Bei WPC95 aber zur Ansteuerung der Flipperfinger. 

 

[Black Knight]

Warum halten wir es nicht ganz allgemein und basteln ein Lisy-Kommando, dass bestimmte Einstellungen der HW lesen und schreiben kann?

Ein Vorschlage wäre z.B.

- Read HW Setting (0x40) mit zwei Folgebytes: die Nummer der Settingsgruppe und einmal die Nummer des Settings selbst (innerhalb der Gruppe). Die Gruppe können wir auch weg lassen, aber 256 Settings könnten etwas knapp werden und es kostet ja nur ein zusätzliches Byte. Als Rückgabewert gibt's dann ein Byte als gelesenen Wert des Settings.

- Write HW Setting (0x41) mit drei Folgebytes: Nummer der Settingsgruppe, Nummer des Settings, neuer Wert des Settings

Ich würde Lisy dann Zugriff auf die APC-Systemsettings geben (Gruppe 0) und auf die Gamesettings für USBcontrol (Gruppe 1). Auf diese Weise könnten wir die DIP-Schalter von Lisy_Mini wegsparen und man könnte die APC Settings über Lisy dann auch verändern wenn man kein Display am APC verwendet.

Das wäre meiner Meinung nach flexibel genug, um es an alle Bedürfnisse anzupassen und man müsste keine bestehenden Befehle ändern.

Wie seht ihr das?

[bontango]

Das wra ja auch mein initialer Gedanke, aber dann hat mich Jan überzeugt das man besser 'sprechende Kommandos hat'

Also:  besser "Switch Strobe settings for LISY to variant 5",  als "LISY_HW Setting 0x08 0x15 0x05"

dem würde ich mich nach erneuter Überlegung anschliessen wollen.

Die Bedeutung von "0x08 0x15 0x05" weiss man vier Wochen später schon nicht mehr, bei dem anderen Kommando klingelts aber ...

[Black Knight]

Klar, in Log Files und so ist das schick, aber auch eine Menge USB-Traffic, ich habe Zweifel dass unser SerialBuffer das aushält. Ihr PI und PC Fuzzies könnt natürlich aus dem Vollen schöpfen, aber ich als Microcontroller-Kröser poliere noch jedes Byte 😉.

Außerdem haben wir bisher alle Lisy-Befehle als Zahlenfolgen aufgebaut, wenn wir das jetzt mittendrin ändern können wir von der neuen Methode noch nicht einmal richtig profitieren.

[bontango]

vor einer Stunde schrieb Black Knight:

aber ich als Microcontroller-Kröser poliere noch jedes Byte

ne schon klar, ich wollte das auch nicht über die Leitung schicken, nur die API Befehle splitten und in der Doku

entsprechend benennen, anstatt ein API Befehl mit unbekannten Parametern

[Black Knight]

OK, dann habe ich wohl nicht kapiert, was ihr vorhabt. Ich dachte, ihr wollt jetzt auf 'Human Readable Interface' umspringen.

vor 14 Minuten schrieb bontango:

nur die API Befehle splitten und in der Doku entsprechend benennen

Die Bedeutung der einzelnen Settings könnte man natürlich in die Doku schreiben, aber die wäre ja dann vermutlich für jede HW verschieden.

Im Fall Lisy <-> APC wären es dann laut APC.ino, also für Gruppe 0 (System Settings) bisher:

Nr.   // Bedeutung
0     // which display is used?
1     // Select the active game
2     // Balls per game
3     // Free game mode?
4     // Reduce lighting time of playfield lamps by 50%
5     // Volume of the speaker
6     // Setting for the APC_LED_EXP board
7     // debug mode enabled?

Und in Gruppe 1 könnte man die DIP Schalter von Mini_Lisy unterbringen:

Nr.   // Bedeutung
0     // PinMame Game number
1     // DIP value 1
2     // DIP value 2
3     // Debug Jumpers

Meinst du sowas in der Art? Aber das hätte ja erst mal nichts mit den allgemeinen Befehlen zum lesen und schreiben der Settings zu tun. Irgendwie ist mir das Problem wohl immer noch nicht ganz klar.

[bontango]

Am 21.4.2020 um 16:31 schrieb Black Knight:

Irgendwie ist mir das Problem wohl immer noch nicht ganz klar.

Hab da mit Lucky auch ein paar Mails ausgetauscht bis ich die Notwendigkeit eingesehen habe, ich versuchs mal mit anderen Worten zu erklären:

Es geht um eine Möglichkeit der Hardwaresteuerung (LISY35) mitzuteilen was denn an Peripherie an Ihr angeschlossen ist, damit die das entsprechend richtig ansteuert.

Im Beispiel LISY35 (Bally Steuerung) weiss die 'andere Seite' (meistens MPF) ja nur dass es sich um eine LISY35 handelt und irgendeine Bally Hardware dran hängt.

Das kann im Fall von z.B der switchmatrix aber verschieden Ansteuerungen nötig machen.

LISY muss noch mitgeteilt werden ob die angeschlossene Switchmatrix 40 oder 48 Switches unterstützt,  und im Fall von 48 Switches an welchem Pin denn Strobe 5 anliegen muss.

Das muesste dann MPF mit dem zu erstellenden API Befehl tun.

 

Gibt es da beim APC nicht die Notwendigkeit? Wird da z.B. die switchmatrix beim System3 .. System11 immer gleich angesprochen?

[Volley]

Wenn ich das richtig im Kopf habe hat Williams doch eine 8x8 Matrix für die Schalter (=64 Schalter)?

[Black Knight]

vor 50 Minuten schrieb bontango:

Es geht um eine Möglichkeit der Hardwaresteuerung (LISY35) mitzuteilen was denn an Peripherie an Ihr angeschlossen ist, damit die das entsprechend richtig ansteuert.

Ok, vielleicht habe ich mich blöd ausgedrückt, aber sowas habe ich gemeint als ich die beiden Kommandos vorgeschlagen habe:

Am 21.4.2020 um 13:37 schrieb Black Knight:

- Read HW Setting (0x40) mit zwei Folgebytes: die Nummer der Settingsgruppe und einmal die Nummer des Settings selbst (innerhalb der Gruppe). Die Gruppe können wir auch weg lassen, aber 256 Settings könnten etwas knapp werden und es kostet ja nur ein zusätzliches Byte. Als Rückgabewert gibt's dann ein Byte als gelesenen Wert des Settings.

- Write HW Setting (0x41) mit drei Folgebytes: Nummer der Settingsgruppe, Nummer des Settings, neuer Wert des Settings

Wir können es auch Daten statt Settings nennen, aber es geht nur darum ein allgemeines Kommando zum Datenaustausch zu haben. Was die einzelnen Settings/Daten bedeuten kann ja dann jede HW für sich bestimmen, da Lisy bzw. MPF ja weiß wer auf der anderen Seite dran ist.

Für den APC wäre mein Vorschlag dann wie oben, Lisy35 und Luckys Steuerung werden diese Bytes natürlich anders verwenden wollen.

Passt das so für euch?

[bontango]

Ja, hört sich gut an, kann ja jeder für sich mal überlegen und ein 'Set' definieren, OK?

[Black Knight]

OK, dann baue ich die beiden Befehle jetzt noch so in V0.13 ein.

[Black Knight]

So, ist drin.

Befehl 0x41 0 1 7

setzt jetzt Setting Nr. 1 in Gruppe 0 auf den Wert 7.

Befehl 0x40 0 1

liest den Inhalt von Setting Nr. 1 in Gruppe 0 würde also nach dem obigen Schreibbefehl eine 7 zurück geben.